From bmanning at vacation.karoshi.com Thu Mar 1 00:12:35 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 1 Mar 2012 06:12:35 +0000 Subject: BBC reports Kenya fiber break In-Reply-To: References: <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx> <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com> <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com> <758C0573-EAEA-4FF8-8114-82DA31A3C709@akcin.net> Message-ID: <20120301061235.GA15100@vacation.karoshi.com.> we had an instance of "B" root there for a season. connectivity was a problem and we pulled the node in 2001. /bill On Wed, Feb 29, 2012 at 09:45:16PM -0800, Bill Woodcock wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > >> On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner > >> wrote: > >>> On Wed, 29 Feb 2012, Rodrick Brown wrote: > >>> > >>>> There's about 1/2 a dozen or so known private and government research > >>>> facilities on Antarctica and I'm surprised to see no fiber end points on > >>>> that continent? This can't be true. > >>> > >>> > >>> Constantly shifting ice shelves and glaciers make a terrestrial cable > >>> landing very difficult to implement on Antarctica. Satellite connectivity > >>> is likely the only feasible option. There are very few places in > >>> Antarctica that are reliably ice-free enough of the time to make a viable > >>> terrestrial landing station. Getting connectivity from the landing station > >>> to other places on the continent is another matter altogether. > > There were INOC-DBA phones at several of the Antarctic stations, for quite a few years. We could see connectivity to them go up and down as the satellites rose above the horizon and set again. > > -Bill > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJPTwztAAoJEG+kcEsoi3+HpgwP/2wjrnyjCoBrLgQYC/rsjVYe > uE8X9ZcnkAkBYI5Q3Aa3ZeVYNbUaX6OChgnsXlt+1v962Lja+V78QuthVDRCJ1Dp > Z5T+XtiIQB4u11lhN55mx8cPXbAKubGCduyCzjBBi+QqE5ayqqCocBHAItxYOMd7 > RRS5ijNUKVMtGIWWWHAdMFAdGuy3zOIt/9oWkq9jJo30RJkEVR6pi7b/sGmM7rjX > XLVc1RPtCmtDkALohRyQOPrMJ2k7284fJ49t2P2Z/8yBbvJtGRmRBkTiUNis0wtx > Ndxed96TaNwwF3snE/zAxu6xCZnjR5trzC586b3ULS2sGSSo2W63AjOqzpMtb8HG > /hlK2GuaAe1vy9Qa+6XDwVJZqbkzPKzrNv7A3RjNvFkTapPGwk1FI7SBO46CUqHh > y2xED78JrIcoKTbC927eWrrArFGRe4ujx+w2D5enlZJT/vGonDScsE/ISAxITbCx > QHbtoAWIjVbraN1UZx+g9hvYOb3AT04zkTImQCj0Kj42COx729WvR7anrkwNNAJV > uqQyLK2wyS9ItyG3U54tECeGVeK0nn9Gyuhp9wdIKI4Qs+JHxXb2eHFqzbn9OZHB > O7PhbBTW3h+viNUkK2NnoiFbQP3E3ZzzNAKjTN9hWa15uGOKum5xUxSZFCD47BuD > J2CjI8dx5PhmLTbcZS4C > =M/np > -----END PGP SIGNATURE----- > > From mysidia at gmail.com Thu Mar 1 00:15:54 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 1 Mar 2012 00:15:54 -0600 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <6252359949770844391@unknownmsgid> References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net> <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com> <6252359949770844391@unknownmsgid> Message-ID: On Mon, Feb 27, 2012 at 10:57 PM, Matt Addison wrote: > gai/gni do not return TTL values on any platforms I'm aware of, the > only way to get TTL currently is to use a non standard resolver (e.g. > lwres). The issue is application developers not calling gai every time GAI/GNI do not return TTL values, but this should not be a problem. If they were to return anything, it should not be a TTL, but a time() value, after which the result may no longer be used. One way to achieve that would be for GAI to return an opaque structure that contained the IP and such a value, in a manner consumable by the sockets API, and adjust connect() to return an error if passed a structure containing a ' returned time + TTL' in the past. TTL values are a DNS resolver function; the application consuming the sockets API should not be concerned about details of the DNS protocol. All the application developer should need to know is that you invoke GAI/GNI and wait for a response. Once you have that response, it is permissible to use the value immediately, but you may not store or re-use that value for more than a few seconds. If you require that value again later, then you invoke GAI/GNI again; any caching details are the concern of the resolver library developer who has implemented GAI/GNI. -- -JH From dburk at burkov.aha.ru Thu Mar 1 00:16:58 2012 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Thu, 1 Mar 2012 10:16:58 +0400 Subject: BBC reports Kenya fiber break In-Reply-To: <20120301061235.GA15100@vacation.karoshi.com.> References: <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx> <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com> <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com> <758C0573-EAEA-4FF8-8114-82DA31A3C709@akcin.net> <20120301061235.GA15100@vacation.karoshi.com.> Message-ID: On Mar 1, 2012, at 10:12 AM, bmanning at vacation.karoshi.com wrote: > > we had an instance of "B" root there for a season. connectivity was a problem and > we pulled the node in 2001. > > /bill You should install it on sattelite dima > > > On Wed, Feb 29, 2012 at 09:45:16PM -0800, Bill Woodcock wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >>>> On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner >>>> wrote: >>>>> On Wed, 29 Feb 2012, Rodrick Brown wrote: >>>>> >>>>>> There's about 1/2 a dozen or so known private and government research >>>>>> facilities on Antarctica and I'm surprised to see no fiber end points on >>>>>> that continent? This can't be true. >>>>> >>>>> >>>>> Constantly shifting ice shelves and glaciers make a terrestrial cable >>>>> landing very difficult to implement on Antarctica. Satellite connectivity >>>>> is likely the only feasible option. There are very few places in >>>>> Antarctica that are reliably ice-free enough of the time to make a viable >>>>> terrestrial landing station. Getting connectivity from the landing station >>>>> to other places on the continent is another matter altogether. >> >> There were INOC-DBA phones at several of the Antarctic stations, for quite a few years. We could see connectivity to them go up and down as the satellites rose above the horizon and set again. >> >> -Bill >> >> >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> >> iQIcBAEBCAAGBQJPTwztAAoJEG+kcEsoi3+HpgwP/2wjrnyjCoBrLgQYC/rsjVYe >> uE8X9ZcnkAkBYI5Q3Aa3ZeVYNbUaX6OChgnsXlt+1v962Lja+V78QuthVDRCJ1Dp >> Z5T+XtiIQB4u11lhN55mx8cPXbAKubGCduyCzjBBi+QqE5ayqqCocBHAItxYOMd7 >> RRS5ijNUKVMtGIWWWHAdMFAdGuy3zOIt/9oWkq9jJo30RJkEVR6pi7b/sGmM7rjX >> XLVc1RPtCmtDkALohRyQOPrMJ2k7284fJ49t2P2Z/8yBbvJtGRmRBkTiUNis0wtx >> Ndxed96TaNwwF3snE/zAxu6xCZnjR5trzC586b3ULS2sGSSo2W63AjOqzpMtb8HG >> /hlK2GuaAe1vy9Qa+6XDwVJZqbkzPKzrNv7A3RjNvFkTapPGwk1FI7SBO46CUqHh >> y2xED78JrIcoKTbC927eWrrArFGRe4ujx+w2D5enlZJT/vGonDScsE/ISAxITbCx >> QHbtoAWIjVbraN1UZx+g9hvYOb3AT04zkTImQCj0Kj42COx729WvR7anrkwNNAJV >> uqQyLK2wyS9ItyG3U54tECeGVeK0nn9Gyuhp9wdIKI4Qs+JHxXb2eHFqzbn9OZHB >> O7PhbBTW3h+viNUkK2NnoiFbQP3E3ZzzNAKjTN9hWa15uGOKum5xUxSZFCD47BuD >> J2CjI8dx5PhmLTbcZS4C >> =M/np >> -----END PGP SIGNATURE----- >> >> > From apishdadi at gmail.com Thu Mar 1 01:12:43 2012 From: apishdadi at gmail.com (A. Pishdadi) Date: Thu, 1 Mar 2012 01:12:43 -0600 Subject: Switch designed for mirroring tap ports Message-ID: Hello All, We are looking for a switch or a device that we can use for mirroring tap ports. For example , take a mirror port off of a core router say a 6509, connect it to a port on said device, say port 1. I would like then to be able to mirror port 1 on said device to multiple ports, like port 2 , 3, 4. We have the need to analyze traffic from one port on multiple devices. Seems most switches are limited to mirroring to a max of 1 or 2 ports. Any suggestions would be great. Thanks, Ameen From mysidia at gmail.com Thu Mar 1 01:23:24 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 1 Mar 2012 01:23:24 -0600 Subject: Reliable Cloud host ? In-Reply-To: References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> Message-ID: On Mon, Feb 27, 2012 at 7:03 PM, George Herbert wrote: > On Mon, Feb 27, 2012 at 3:45 PM, William Herrin wrote: >> universe does $30/mo per customer recover that cost during the useful >> life of the equipment? > As I stated, one can either do it with SANs or with alternate storage. Should not assume Rackspace et. all provide any level of fault tolerance for extraordinary situations such as hardware failure beyond what they have promised or advertised. IaaS provided redundancy is not always necessary, and may be unwanted in various situations due to its cost; single redundancy means a minimum of twice the cost of non-redundant (plus the overhead of failover coordination). With various computing applications it may make a great deal of sense to handle in software -- should a node fail, the software can detect a node failed, eject it, reassign its unfinished work units later. Typical Enterprise level fault tolerant SAN manufacturer prices seen are ~ $12 to $15/GB usable storage, for ~50 IOPS/TB, data mostly at rest, and SAN equipment has a useful lifetime of 5-6 years; a typical 200gb server then exceeds $30/month in intrinsic FT SAN hardware cost. There IS a place for IaaS providers to sell such product, probably at four or five times the $/month for a typical server. Just like there is a place for Network service providers to sell transport and network access products that have redundancy built into the product, such as protected circuits, multiple-port, dual WAN , that can sustain any single router failure, etc. Those network products still can't reliably guarantee 100% uptime for the service. There is a place for IaaS providers to sell products where they do NOT promise a level of reliability/fault tolerance or performance guarantee that requires them to utilize an Enterprise FC SAN or similar solution. Just like there is a place for NSPs to sell transport and network access products that will fail if a single router, card, port fails, or if there is a single fiber break or erroneously unplugged cable. This way the end user can save on their network connectivity costs; a tradeoff based on the impact of the difference between their network with 1% downtime and their network with 0.001% downtime; VERSUS the impact of the cost difference between those two options. End users may also prefer to implement their redundancy through dual-homing via multiple providers. It is very important that the end user and the provider's sales/marketing know exactly which kind of product each offering is. > ?Amazon hit those price points with a custom distributed filesystem > that's more akin to the research distributed filesystems than anything Amazon is quite unique; developing a custom distributed filesystem is a rather extraordinary measure, that provides them an advantage when selling certain services. But even EC2 instance storage is not guaranteed. The instance storage is scratch space If your instance becomes degraded, and you need to restart it, what you get is a "clean" instance, matching the original image. EBS and S3 are another matter. The same provider that offers some 'unprotected' services, may also offer some more expensive storage services that have greater protections. -- -JH From jay+NANOG at tp.org Thu Mar 1 02:11:39 2012 From: jay+NANOG at tp.org (Jay Moran) Date: Thu, 1 Mar 2012 16:11:39 +0800 Subject: Switch designed for mirroring tap ports In-Reply-To: References: Message-ID: Ameen, We've had very good success using Brocade MLX's for this very thing (actually, might be older XMRs, but should be same platform at this point). Check out the transparent-hw-flooding command under a VLAN. It basically turns off mac learning, and just floods it on the vlan's member ports. If you want to be creative and say split out port 80 traffic to one port and the rest to another, you can use policy based routing to change the destination VLAN for just tcp/80 traffic. If you want to have many different inputs going to many different outputs some with PBR, some without, then you may have to get very creative and use cables coming out of one port on the box and going back into another port. We're using this successfully with multiple 10GE ports. Jay -- Jay Moran http://tp.org/jay On Thu, Mar 1, 2012 at 3:12 PM, A. Pishdadi wrote: > Hello All, > > We are looking for a switch or a device that we can use for mirroring tap > ports. For example , take a mirror port off of a core router say a 6509, > connect it to a port on said device, say port 1. I would like then to be > able to mirror port 1 on said device to multiple ports, like port 2 , 3, > 4. We have the need to analyze traffic from one port on multiple devices. > Seems most switches are limited to mirroring to a max of 1 or 2 ports. > > > Any suggestions would be great. > > Thanks, > Ameen > From gwood83 at gmail.com Thu Mar 1 02:34:07 2012 From: gwood83 at gmail.com (=?utf-8?B?Z3dvb2Q4M0BnbWFpbC5jb20=?=) Date: Thu, 01 Mar 2012 00:34:07 -0800 Subject: =?utf-8?B?UmU6IFN3aXRjaCBkZXNpZ25lZCBmb3IgbWlycm9yaW5nIHRhcCBwb3J0cw==?= Message-ID: <4f4f347f.843f440a.631e.6cce@mx.google.com> Instead of monitoring the physical interface, monitor the vlan from a Cisco IOS perspective on a CAT6500. This will capture all physical interfaces associated with that vlan for mirroring/span. HTH Jonathan #22744 Sent from my HTC on the Now Network from Sprint! ----- Reply message ----- From: "A. Pishdadi" Date: Wed, Feb 29, 2012 11:12 pm Subject: Switch designed for mirroring tap ports To: "NANOG" Hello All, We are looking for a switch or a device that we can use for mirroring tap ports. For example , take a mirror port off of a core router say a 6509, connect it to a port on said device, say port 1. I would like then to be able to mirror port 1 on said device to multiple ports, like port 2 , 3, 4. We have the need to analyze traffic from one port on multiple devices. Seems most switches are limited to mirroring to a max of 1 or 2 ports. Any suggestions would be great. Thanks, Ameen From apishdadi at gmail.com Thu Mar 1 02:54:18 2012 From: apishdadi at gmail.com (A. Pishdadi) Date: Thu, 1 Mar 2012 02:54:18 -0600 Subject: Switch designed for mirroring tap ports In-Reply-To: <4f4f347f.843f440a.631e.6cce@mx.google.com> References: <4f4f347f.843f440a.631e.6cce@mx.google.com> Message-ID: No the issue isnt monitoring many ports at once, its having more then 1 set of monitoring or 2 sets in the 6500 case. So I am monitoring say port channel 1 to ports 1 2 3 4, and port channel 2 , ports 4 5 6 and 7. After that I cannot monitor anymore ports. On Thu, Mar 1, 2012 at 2:34 AM, gwood83 at gmail.com wrote: > Instead of monitoring the physical interface, monitor the vlan from a > Cisco IOS perspective on a CAT6500. This will capture all physical > interfaces associated with that vlan for mirroring/span. > > HTH > > Jonathan > #22744 > > Sent from my HTC on the Now Network from Sprint! > > > ----- Reply message ----- > From: "A. Pishdadi" > Date: Wed, Feb 29, 2012 11:12 pm > Subject: Switch designed for mirroring tap ports > To: "NANOG" > > Hello All, > > We are looking for a switch or a device that we can use for mirroring tap > ports. For example , take a mirror port off of a core router say a 6509, > connect it to a port on said device, say port 1. I would like then to be > able to mirror port 1 on said device to multiple ports, like port 2 , 3, > 4. We have the need to analyze traffic from one port on multiple devices. > Seems most switches are limited to mirroring to a max of 1 or 2 ports. > > > Any suggestions would be great. > > Thanks, > Ameen > > > From gtheo at iti.gr Thu Mar 1 03:11:23 2012 From: gtheo at iti.gr (Georgios Theodoridis) Date: Thu, 01 Mar 2012 11:11:23 +0200 Subject: BBC reports Kenya fiber break In-Reply-To: <20120229135328.GF24032@netmeister.org> References: <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx> <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com> <20120229135328.GF24032@netmeister.org> Message-ID: <4F4F3D3B.4090404@iti.gr> Has it been known the exact time of the incident? I have found an article reporting that the cut occurred in the mid-day of Saturday 25th but nothing more precise. We would like to use such information for a BGP anomaly detection analysis that we are carrying out in our research centre. Thanks in advance, George On 02/29/2012 03:53 PM, Jan Schaumann wrote: > Joly MacFie wrote: >> A comment on the WSJ >> storycontains >> a link to a great map. >> >> http://www.submarinecablemap.com/ > I always liked this one, too: > http://is.gd/DXcddb > > (Yes, flash. Still.) > > -Jan From terry.baranski.list at gmail.com Thu Mar 1 04:52:44 2012 From: terry.baranski.list at gmail.com (Terry Baranski) Date: Thu, 1 Mar 2012 05:52:44 -0500 Subject: Switch designed for mirroring tap ports In-Reply-To: References: Message-ID: <4f4f5503.a81e340a.358a.49d2@mx.google.com> On Mar 1, 2012, at 02:13 AM, apishdadi at gmail.com wrote: > Hello All, > > We are looking for a switch or a device that we can use for mirroring > tap ports. For example , take a mirror port off of a core router say > a 6509, connect it to a port on said device, say port 1. I would like > then to be able to mirror port 1 on said device to multiple ports, > like port 2 , 3, 4. We have the need to analyze traffic from one port > on multiple devices. Seems most switches are limited to mirroring to a > max of 1 or 2 ports. We like Gigamon for this purpose. -Terry From tim at pelican.org Thu Mar 1 04:54:49 2012 From: tim at pelican.org (Tim Franklin) Date: Thu, 01 Mar 2012 10:54:49 -0000 (GMT) Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: Message-ID: > GAI/GNI do not return TTL values, but this should not be a problem. > If they were to return anything, it should not be a TTL, but a time() > value, after which the result may no longer be used. > > One way to achieve that would be for GAI to return an opaque structure > that contained the IP and such a value, in a manner consumable by the > sockets API, and adjust connect() to return an error if passed a > structure containing a ' returned time + TTL' in the past. AF_INET_TTL and AFINET6_TTL, with correspondingly expanded struct sockaddr_* ? Code that explictly requests AF_INET or AF_INET6 would get what it was expecting, code that requests AF_UNSPEC on a system with modified getaddrinfo() would get the expanded structs with the different ai_family set, and could pass them straight into a modified connect(). I'm sure I'm grossly oversimplifying somewhere though... Regards, Tim. From david at davidswafford.com Thu Mar 1 05:03:43 2012 From: david at davidswafford.com (David Swafford) Date: Thu, 1 Mar 2012 06:03:43 -0500 Subject: Switch designed for mirroring tap ports In-Reply-To: <4f4f5503.a81e340a.358a.49d2@mx.google.com> References: <4f4f5503.a81e340a.358a.49d2@mx.google.com> Message-ID: Take a look at VACLs on the Cat side. It has a capture feature that is effectively the same as a local SPAN, but without the 2 session limit. If you do a lot of RSPAN though, this wouldn't be your complete answer (VACL captures are local only). VACLs are a bit more granular in defining what's captured, if say for example you only wanted traffic destined to TCP/80, you could configure it that way. David. On Thu, Mar 1, 2012 at 5:52 AM, Terry Baranski < terry.baranski.list at gmail.com> wrote: > On Mar 1, 2012, at 02:13 AM, apishdadi at gmail.com wrote: > > > Hello All, > > > > We are looking for a switch or a device that we can use for mirroring > > tap ports. For example , take a mirror port off of a core router say > > a 6509, connect it to a port on said device, say port 1. I would like > > then to be able to mirror port 1 on said device to multiple ports, > > like port 2 , 3, 4. We have the need to analyze traffic from one port > > on multiple devices. Seems most switches are limited to mirroring to a > > max of 1 or 2 ports. > > We like Gigamon for this purpose. > > -Terry > > > > From securinate at gmail.com Thu Mar 1 06:03:40 2012 From: securinate at gmail.com (Chris Mills) Date: Thu, 1 Mar 2012 07:03:40 -0500 Subject: Switch designed for mirroring tap ports In-Reply-To: <4f4f5503.a81e340a.358a.49d2@mx.google.com> References: <4f4f5503.a81e340a.358a.49d2@mx.google.com> Message-ID: Echoing what Terry said... we use gigamon devices for this too. -Chris On Mar 1, 2012 5:53 AM, "Terry Baranski" wrote: > On Mar 1, 2012, at 02:13 AM, apishdadi at gmail.com wrote: > > > Hello All, > > > > We are looking for a switch or a device that we can use for mirroring > > tap ports. For example , take a mirror port off of a core router say > > a 6509, connect it to a port on said device, say port 1. I would like > > then to be able to mirror port 1 on said device to multiple ports, > > like port 2 , 3, 4. We have the need to analyze traffic from one port > > on multiple devices. Seems most switches are limited to mirroring to a > > max of 1 or 2 ports. > > We like Gigamon for this purpose. > > -Terry > > > > From owen at delong.com Thu Mar 1 06:20:08 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Mar 2012 04:20:08 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net> <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com> <6252359949770844391@unknownmsgid> Message-ID: <34F84CED-8C8C-4EE3-A0FF-6001F4E3D7A2@delong.com> On Feb 29, 2012, at 10:15 PM, Jimmy Hess wrote: > On Mon, Feb 27, 2012 at 10:57 PM, Matt Addison > wrote: >> gai/gni do not return TTL values on any platforms I'm aware of, the >> only way to get TTL currently is to use a non standard resolver (e.g. >> lwres). The issue is application developers not calling gai every time > > GAI/GNI do not return TTL values, but this should not be a problem. > If they were to return anything, it should not be a TTL, but a time() > value, after which > the result may no longer be used. > > One way to achieve that would be for GAI to return an opaque structure > that contained the IP and such a value, in a manner consumable by the > sockets API, and adjust connect() to return an error if passed a > structure containing a ' returned time + TTL' in the past. > > > TTL values are a DNS resolver function; the application consuming the > sockets API > should not be concerned about details of the DNS protocol. > > All the application developer should need to know is that you invoke > GAI/GNI and wait for a response. > Once you have that response, it is permissible to use the value immediately, > but you may not store or re-use that value for more than a few seconds. > > If you require that value again later, then you invoke GAI/GNI again; > any caching details > are the concern of the resolver library developer who has implemented GAI/GNI. > > -- > -JH The simpler approach and perfectly viable without mucking up what is already implemented and working: Don't keep returns from GAI/GNI around longer than it takes to cycle through your connect() loop immediately after the GAI/GNI call. If you write your code to the standard of: getaddrinfo(); /* do something with the results */ freeaddrinfo(); with a very limited amount of time passing between getaddrinfo() and freeaddrinfo(), then, you don't need TTLs and it doesn't matter. The system resolver library should do the right thing with DNS TTLs for records retrieved from DNS and a subsequent call to getaddrinfo() within the DNS TTL for the previously retrieved record should be a relatively cheap, fast in-memory operation. Owen From hhoffman at ip-solutions.net Thu Mar 1 06:50:49 2012 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Thu, 01 Mar 2012 07:50:49 -0500 Subject: Switch designed for mirroring tap ports Message-ID: <8oka2hjagps48vqyi4g65lwl.1330606249261@email.android.com> From rs at seastrom.com Thu Mar 1 06:51:13 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 01 Mar 2012 07:51:13 -0500 Subject: Switch designed for mirroring tap ports In-Reply-To: (A. Pishdadi's message of "Thu, 1 Mar 2012 01:12:43 -0600") References: Message-ID: <861upch4ce.fsf@seastrom.com> "A. Pishdadi" writes: > We are looking for a switch or a device that we can use for mirroring tap > ports. For example , take a mirror port off of a core router say a 6509, > connect it to a port on said device, say port 1. I would like then to be > able to mirror port 1 on said device to multiple ports, like port 2 , 3, > 4. We have the need to analyze traffic from one port on multiple devices. > Seems most switches are limited to mirroring to a max of 1 or 2 ports. http://www.netoptics.com/products/regeneration-taps Been reasonably happy with these on 100m and gigabit links in the past, can't imagine that their 10g products don't work just as well. -r From thegameiam at yahoo.com Thu Mar 1 07:01:02 2012 From: thegameiam at yahoo.com (David Barak) Date: Thu, 1 Mar 2012 05:01:02 -0800 (PST) Subject: Switch designed for mirroring tap ports Message-ID: <1330606862.6060.YahooMailMobile@web31816.mail.mud.yahoo.com> Hi Ameen, Wouldn't it work to have a switch aggregating your monitor sessions just disable MAC learning? Traffic from a single input interface would be replicated to all other ports on the vlan where learning is disabled. I've used this with a 3750, and I haven't seen any trouble (other than that you don't want that switch in-line with anything else). David Barak From jgreco at ns.sol.net Thu Mar 1 07:25:14 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 1 Mar 2012 07:25:14 -0600 (CST) Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: Message-ID: <201203011325.q21DPEAS093544@aurora.sol.net> > > On Wed, Feb 29, 2012 at 4:02 PM, Joe Greco wrote: > > In the specific case of TTL, the problem is made much worse due to the > > way most client code has hidden this data from developers, so that many > > developers don't even have any idea that such a thing exists. > > > > I'm not sure how to see that a design failure of the TTL mechanism. > > Hi Joe, > > You shouldn't see that as a design failure of the TTL mechanism. It > isn't. It's a failure of the system of which DNS TTL is a component. > The TTL component itself was reasonably designed. Think that's pretty much what I said. > The failure is likened to installing a well designed sprinkler system > (the DNS with a TTL) and then shutting off the water valve > (gethostbyname/getaddrinfo). No, the water still works as intended. I think your analogy starts to fail here. It's more like expecting a water suppression system to put out a grease fire. The TTL mechanism is completely suitable for what it was originally meant for, and in an environment where everyone has followed the rules, it works fine. If you take a light office space with sprinklers and remodel it into a short order grill, the fire inspector will require you to rework the fire suppression system to an appropriate system. Problem is, TTL is a relatively light-duty system that people have felt free to ignore, overload for other purposes, etc., but there's no fire inspector to come around and tell people how and why what they've done is broken. In the case of TTL, the system is even largely hidden from users, so that it is rarely thought about except now and then on NANOG, dns-operations, etc. ;-) No wonder it is even poorly understood. > > I don't see developers ignoring DNS and hardcoding IP addresses into > > code as a failure of the DNS system. > > It isn't. It's a failure of the sockets API design which calls on > every application developer to (a) translate the name to a set of > addresses with a mechanism that discards the TTL knowledge and (b) > implement his own glue between name to address mapping and connect by > address. > > It would be like telling an app developer: here's the ARP function and > the SEND function. When you Send to an IP address, make sure you > attach the right destination MAC. Of course the app developer gets it > wrong most of the time. That's correct - and it doesn't imply that the system that was engineered is faulty. In all likelihood, the fault lies with what the app developer was told. You originally said: "If three people died and the building burned down then the sprinkler system didn't work. It may have sprayed water, but it didn't *work*." That's not true. If it sprayed water in the manner it was designed to, then it worked. If three people took sleeping pills and didn't wake up when the alarms blared, and an arsonist poured ten gallons of gas everywhere before lighting the fire, the system still worked. It failed to save those lives or protect the building from burning down, but I am aware of no fire suppression systems that realistically attempts to address that. It is an unreasonable expectation. I have a hard time seeing the many self-inflicted wounds of people who have attempted to abuse TTL for various purposes as a failure of the TTL design. The design is reasonable. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From bill at herrin.us Thu Mar 1 08:26:27 2012 From: bill at herrin.us (William Herrin) Date: Thu, 1 Mar 2012 09:26:27 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <34F84CED-8C8C-4EE3-A0FF-6001F4E3D7A2@delong.com> References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net> <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com> <6252359949770844391@unknownmsgid> <34F84CED-8C8C-4EE3-A0FF-6001F4E3D7A2@delong.com> Message-ID: On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLong wrote: > The simpler approach and perfectly viable without mucking > up what is already implemented and working: > > Don't keep returns from GAI/GNI around longer than it takes > to cycle through your connect() loop immediately after the GAI/GNI call. The even simpler approach: create an AF_NAME with a sockaddr struct that contains a hostname instead of an IPvX address. Then let connect() figure out the details of caching, TTLs, protocol and address selection, etc. Such a connect() could even support a revised TCP stack which is able to retry with the other addresses at the first subsecond timeout rather than camping on each address in sequence for the typical system default of two minutes. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Thu Mar 1 08:31:42 2012 From: bill at herrin.us (William Herrin) Date: Thu, 1 Mar 2012 09:31:42 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <201203011325.q21DPEAS093544@aurora.sol.net> References: <201203011325.q21DPEAS093544@aurora.sol.net> Message-ID: On Thu, Mar 1, 2012 at 8:25 AM, Joe Greco wrote: > "If three people died and the building burned down then the sprinkler > system didn't work. It may have sprayed water, but it didn't *work*." > > That's not true. ?If it sprayed water in the manner it was designed to, > then it worked. That's like the old crack about ICBM interceptors. Why yes, our system performed swimmingly in the latest test achieving nine out of the ten criteria for success. Which criteria didn't it achieve? It missed the target. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From IAN.SLADE at saic.com Thu Mar 1 08:50:15 2012 From: IAN.SLADE at saic.com (Slade, Ian) Date: Thu, 1 Mar 2012 09:50:15 -0500 Subject: Switch designed for mirroring tap ports In-Reply-To: References: <4f4f347f.843f440a.631e.6cce@mx.google.com> Message-ID: <05D35E9CAC2A2F459F83D0C0235074F803BB1C72@0015-its-exmb12.us.saic.com> Yes, the Cat 6500s are limited to a certain number of SPAN/port monitoring sessions. Another tool, we've switched to after using the Gigamon for many years are taps and the Anue 5236 (10Gb) port aggregator. From this we can split the SPAN feeds into different IDS/monitoring servers or load-share among several output servers. It is a great tool and very easy GUI to control the feeds and output ports. Ian Slade Sr. Network Engineer, SAIC ITS Systems Engineering ian.slade at saic.com 703-676-5234 http://www.saic.com -----Original Message----- From: nanog-bounces+ian.slade=saic.com at nanog.org [mailto:nanog-bounces+ian.slade=saic.com at nanog.org] On Behalf Of A. Pishdadi Sent: Thursday, March 01, 2012 3:54 AM To: gwood83 at gmail.com Cc: NANOG Subject: Re: Switch designed for mirroring tap ports No the issue isnt monitoring many ports at once, its having more then 1 set of monitoring or 2 sets in the 6500 case. So I am monitoring say port channel 1 to ports 1 2 3 4, and port channel 2 , ports 4 5 6 and 7. After that I cannot monitor anymore ports. On Thu, Mar 1, 2012 at 2:34 AM, gwood83 at gmail.com wrote: > Instead of monitoring the physical interface, monitor the vlan from a > Cisco IOS perspective on a CAT6500. This will capture all physical > interfaces associated with that vlan for mirroring/span. > > HTH > > Jonathan > #22744 > > Sent from my HTC on the Now Network from Sprint! > > > ----- Reply message ----- > From: "A. Pishdadi" > Date: Wed, Feb 29, 2012 11:12 pm > Subject: Switch designed for mirroring tap ports > To: "NANOG" > > Hello All, > > We are looking for a switch or a device that we can use for mirroring > tap ports. For example , take a mirror port off of a core router say a > 6509, connect it to a port on said device, say port 1. I would like > then to be able to mirror port 1 on said device to multiple ports, > like port 2 , 3, 4. We have the need to analyze traffic from one port on multiple devices. > Seems most switches are limited to mirroring to a max of 1 or 2 ports. > > > Any suggestions would be great. > > Thanks, > Ameen > > > From jgreco at ns.sol.net Thu Mar 1 08:53:02 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 1 Mar 2012 08:53:02 -0600 (CST) Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: Message-ID: <201203011453.q21Er2Ul094563@aurora.sol.net> > On Thu, Mar 1, 2012 at 8:25 AM, Joe Greco wrote: > > "If three people died and the building burned down then the sprinkler > > system didn't work. It may have sprayed water, but it didn't *work*." > > > > That's not true. =A0If it sprayed water in the manner it was designed to, > > then it worked. > > That's like the old crack about ICBM interceptors. Why yes, our system > performed swimmingly in the latest test achieving nine out of the ten > criteria for success. Which criteria didn't it achieve? It missed the > target. Difference: the fire suppression system worked as designed, the ICBM didn't. That's kind of the whole point here. If you have something like an automobile that's designed to protect you against certain kinds of accidents, it isn't a failure if it does not protect you against an accident that is not reasonably within the protection envelope. For example, cars these days are designed to protect against many different types of impacts and provide survivability. It is a failure if my car is designed to protect against a head-on crash at 30MPH by use of engineered crumple zones and deploying air bags, and I get into such an accident and am killed regardless. However, if I fly my car into a bridge abutment at 150MPH and am instantly pulverized, I am not prepared to consider that a failure of the car. Likewise, if a freeway overpass slab falls on my car and crushes me as I drive underneath it, I am not going to consider that a failure of the car. There's a definite distinction between a system that fails when it is deployed and used in the intended manner, and a system that doesn't work as you'd like it to when it is used in some incorrect manner, which is really not a failure as the word is normally used. ... 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 oliver at g.garraux.net Thu Mar 1 08:54:07 2012 From: oliver at g.garraux.net (Oliver Garraux) Date: Thu, 1 Mar 2012 09:54:07 -0500 Subject: BBC reports Kenya fiber break In-Reply-To: <4F4F3D3B.4090404@iti.gr> References: <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx> <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com> <20120229135328.GF24032@netmeister.org> <4F4F3D3B.4090404@iti.gr> Message-ID: On Thu, Mar 1, 2012 at 4:11 AM, Georgios Theodoridis wrote: > Has it been known the exact time of the incident? > I have found an article reporting that the cut occurred in the mid-day of > Saturday 25th but nothing more precise. > We would like to use such information for a BGP anomaly detection analysis > that we are carrying out in our research centre. > > Thanks in advance, > > George > > It sounds like there were multiple cables that were lost recently. For the EASSy cable issue in the Red Sea, an ISP in Malawi stated the issues started at "09:26 on Friday 17 February". I don't know first hand if that is accurate to the minute or not. I believe this is separate from the cable off the cost of Kenya that was cut on the 25th. Oliver From mike at mtcc.com Thu Mar 1 09:01:16 2012 From: mike at mtcc.com (Michael Thomas) Date: Thu, 01 Mar 2012 07:01:16 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net> <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com> <6252359949770844391@unknownmsgid> <34F84CED-8C8C-4EE3-A0FF-6001F4E3D7A2@delong.com> Message-ID: <4F4F8F3C.9090706@mtcc.com> On 03/01/2012 06:26 AM, William Herrin wrote: > On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLong wrote: >> The simpler approach and perfectly viable without mucking >> up what is already implemented and working: >> >> Don't keep returns from GAI/GNI around longer than it takes >> to cycle through your connect() loop immediately after the GAI/GNI call. > The even simpler approach: create an AF_NAME with a sockaddr struct > that contains a hostname instead of an IPvX address. Then let > connect() figure out the details of caching, TTLs, protocol and > address selection, etc. Such a connect() could even support a revised > TCP stack which is able to retry with the other addresses at the first > subsecond timeout rather than camping on each address in sequence for > the typical system default of two minutes. The effect of what you're recommending is to move all of this into the kernel, and in the process greatly expand its scope. Also: even if you did this, you'd be saddled with the same problem because nothing existing would use an AF_NAME. The real issue is that gethostbyxxx has been inadequate for a very long time. Moving it across the kernel boundary solves nothing and most likely causes even more trouble: what if I want, say, asynchronous name resolution? What if I want to use SRV records? What if a new DNS RR comes around -- do i have do recompile the kernel? It's for these reasons and probably a whole lot more that connect just confuses the actual issues. When I was writing the first version of DKIM I used a library that I scraped off the net called ARES. It worked adequately for me, but the most notable thing was the very fact that I had to scrape it off the net at all. As far as I could tell, standard distos don't have libraries with lower level access to DNS (in my case, it needed to not block). Before positing a super-deluxe gethostbyxx that does addresses picking, etc, etc, it would be better to lobby all of the distos to settle on a decomposed resolver library from which that and more could be built. Mike From shawn at smorris.com Thu Mar 1 09:02:26 2012 From: shawn at smorris.com (Shawn Morris) Date: Thu, 1 Mar 2012 09:02:26 -0600 Subject: Switch designed for mirroring tap ports In-Reply-To: References: Message-ID: I believe MRV's Media Cross Connects will do this. http://www.mrv.com/tap/physical-layer/ On Thu, Mar 1, 2012 at 1:12 AM, A. Pishdadi wrote: > Hello All, > > We are looking for a switch or a device that we can use for mirroring tap > ports. For example , take a mirror port off of a core router say a 6509, > connect it to a port on said device, say port 1. I would like then to be > able to mirror port 1 on said device to multiple ports, ?like port 2 , 3, > 4. We have the need to analyze traffic from one port on multiple devices. > Seems most switches are limited to mirroring to a max of 1 or 2 ports. > > > Any suggestions would be great. > > Thanks, > Ameen From ron at spawar.navy.mil Thu Mar 1 09:04:20 2012 From: ron at spawar.navy.mil (Ron Broersma) Date: Thu, 1 Mar 2012 10:04:20 -0500 Subject: Switch designed for mirroring tap ports In-Reply-To: <05D35E9CAC2A2F459F83D0C0235074F803BB1C72@0015-its-exmb12.us.saic.com> References: <4f4f347f.843f440a.631e.6cce@mx.google.com> <05D35E9CAC2A2F459F83D0C0235074F803BB1C72@0015-its-exmb12.us.saic.com> Message-ID: <849AEA24-EAEE-493C-8020-F2F465EFBC7A@spawar.navy.mil> Be careful when considering the Anue products. When we evaluated both Anue and Gigamon, we had to rule out Anue due to total lack of IPv6 support, and went with Gigamon instead. I have not heard whether the situation has changed in the last year. We liked both products for their functionality and ease of use, but for us IPv6 was the distinguishing capability. --Ron Ron Broersma DREN Chief Engineer On Mar 1, 2012, at 9:50 AM, Slade, Ian wrote: > Yes, the Cat 6500s are limited to a certain number of SPAN/port > monitoring sessions. > > Another tool, we've switched to after using the Gigamon for many years > are taps and the Anue 5236 (10Gb) port aggregator. From this we can > split the SPAN feeds into different IDS/monitoring servers or load-share > among several output servers. It is a great tool and very easy GUI to > control the feeds and output ports. > > > Ian Slade > Sr. Network Engineer, SAIC ITS Systems Engineering > ian.slade at saic.com 703-676-5234 http://www.saic.com > > > -----Original Message----- > From: nanog-bounces+ian.slade=saic.com at nanog.org > [mailto:nanog-bounces+ian.slade=saic.com at nanog.org] On Behalf Of A. > Pishdadi > Sent: Thursday, March 01, 2012 3:54 AM > To: gwood83 at gmail.com > Cc: NANOG > Subject: Re: Switch designed for mirroring tap ports > > No the issue isnt monitoring many ports at once, its having more then 1 > set of monitoring or 2 sets in the 6500 case. So I am monitoring say > port channel 1 to ports 1 2 3 4, and port channel 2 , ports 4 5 6 and 7. > After that I cannot monitor anymore ports. > > On Thu, Mar 1, 2012 at 2:34 AM, gwood83 at gmail.com > wrote: > >> Instead of monitoring the physical interface, monitor the vlan from a >> Cisco IOS perspective on a CAT6500. This will capture all physical >> interfaces associated with that vlan for mirroring/span. >> >> HTH >> >> Jonathan >> #22744 >> >> Sent from my HTC on the Now Network from Sprint! >> >> >> ----- Reply message ----- >> From: "A. Pishdadi" >> Date: Wed, Feb 29, 2012 11:12 pm >> Subject: Switch designed for mirroring tap ports >> To: "NANOG" >> >> Hello All, >> >> We are looking for a switch or a device that we can use for mirroring >> tap ports. For example , take a mirror port off of a core router say a > >> 6509, connect it to a port on said device, say port 1. I would like >> then to be able to mirror port 1 on said device to multiple ports, >> like port 2 , 3, 4. We have the need to analyze traffic from one port > on multiple devices. >> Seems most switches are limited to mirroring to a max of 1 or 2 ports. >> >> >> Any suggestions would be great. >> >> Thanks, >> Ameen >> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4936 bytes Desc: not available URL: From kris at kriskinc.com Thu Mar 1 09:09:27 2012 From: kris at kriskinc.com (Kristian Kielhofner) Date: Thu, 1 Mar 2012 10:09:27 -0500 Subject: Riverbed/Akamai/Rakamai Message-ID: As long as we're talking about cloud networks, Akamai and Riverbed have finally let out details on their partnership for "optimizing" Cloud applications: http://www.nojitter.com/post/232601716/rakamai-makes-the-cloud-work-better While I'm familiar with Akamai (what they do and how they do it) I don't have any experience with Riverbed. Does anyone know what they actually "do" and how they do it? As usual it's tough to cut through the marketing on the little detail they make available (never a good sign). -- Kristian Kielhofner From jgreco at ns.sol.net Thu Mar 1 09:22:07 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 1 Mar 2012 09:22:07 -0600 (CST) Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <4F4F8F3C.9090706@mtcc.com> Message-ID: <201203011522.q21FM74H095011@aurora.sol.net> > On 03/01/2012 06:26 AM, William Herrin wrote: > > On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLong wrote: > >> The simpler approach and perfectly viable without mucking > >> up what is already implemented and working: > >> > >> Don't keep returns from GAI/GNI around longer than it takes > >> to cycle through your connect() loop immediately after the GAI/GNI call. > > The even simpler approach: create an AF_NAME with a sockaddr struct > > that contains a hostname instead of an IPvX address. Then let > > connect() figure out the details of caching, TTLs, protocol and > > address selection, etc. Such a connect() could even support a revised > > TCP stack which is able to retry with the other addresses at the first > > subsecond timeout rather than camping on each address in sequence for > > the typical system default of two minutes. > > The effect of what you're recommending is to move all of this > into the kernel, and in the process greatly expand its scope. Also: > even if you did this, you'd be saddled with the same problem because > nothing existing would use an AF_NAME. > > The real issue is that gethostbyxxx has been inadequate for a very > long time. Moving it across the kernel boundary solves nothing and > most likely causes even more trouble: what if I want, say, asynchronous > name resolution? What if I want to use SRV records? What if a new DNS > RR comes around -- do i have do recompile the kernel? It's for these > reasons and probably a whole lot more that connect just confuses the > actual issues. > > When I was writing the first version of DKIM I used a library that I scraped > off the net called ARES. It worked adequately for me, but the most notable > thing was the very fact that I had to scrape it off the net at all. As far as > I could tell, standard distos don't have libraries with lower level access to > DNS (in my case, it needed to not block). Before positing a super-deluxe > gethostbyxx that does addresses picking, etc, etc, it would be better to > lobby all of the distos to settle on a decomposed resolver library from > which that and more could be built. It's deeper than just that, though. The whole paradigm is messy, from the point of view of someone who just wants to get stuff done. The examples are (almost?) all fatally flawed. The code that actually gets at least some of it right ends up being too complex and too hard for people to understand why things are done the way they are. Even in the "old days", before IPv6, geez, look at this: bcopy(host->h_addr_list[n], (char *)&addr->sin_addr.s_addr, sizeof(addr->sin_addr.s_addr)); That's real comprehensible - and it's essentially the data interface between the resolver library and the system's addressing structures for syscalls. On one hand, it's "great" that they wanted to abstract the dirty details of DNS away from users, but I'd say they failed pretty much even at that. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jeff-kell at utc.edu Thu Mar 1 09:22:29 2012 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 1 Mar 2012 10:22:29 -0500 Subject: Switch designed for mirroring tap ports In-Reply-To: References: Message-ID: <4F4F9435.9090805@utc.edu> How about splitting up a heavy stream (10G) into components (1G) to run through an inline device and reassemble the pieces back to an aggregate afterward? TippingPoint makes a "core controller" box for this but it's pretty hideously expensive. Could do it with two 6500s but that's pretty hideously expensive as well :) Jeff From hhoffman at ip-solutions.net Thu Mar 1 09:31:30 2012 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Thu, 01 Mar 2012 10:31:30 -0500 Subject: Switch designed for mirroring tap ports In-Reply-To: <4F4F9435.9090805@utc.edu> References: <4F4F9435.9090805@utc.edu> Message-ID: <4F4F9652.5030905@ip-solutions.net> Gigamon has a new product offering that claims to do this (their sales guys just met with me a few days ago and gave me a update on their latest offerings). It's the G-Secure-. We're using the 2404's so I don't have any experience with it. Cheers, Harry On 03/01/2012 10:22 AM, Jeff Kell wrote: > How about splitting up a heavy stream (10G) into components (1G) to run through an > inline device and reassemble the pieces back to an aggregate afterward? > > TippingPoint makes a "core controller" box for this but it's pretty hideously expensive. > > Could do it with two 6500s but that's pretty hideously expensive as well :) > > Jeff > > From geier at geier.ne.tz Thu Mar 1 09:45:30 2012 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 01 Mar 2012 18:45:30 +0300 Subject: BBC reports Kenya fiber break In-Reply-To: References: <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx> <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com> <20120229135328.GF24032@netmeister.org> <4F4F3D3B.4090404@iti.gr> Message-ID: <4F4F999A.20100@geier.ne.tz> On 3/1/2012 5:54 PM, Oliver Garraux wrote: > On Thu, Mar 1, 2012 at 4:11 AM, Georgios Theodoridis wrote: >> Has it been known the exact time of the incident? >> I have found an article reporting that the cut occurred in the mid-day of >> Saturday 25th but nothing more precise. >> We would like to use such information for a BGP anomaly detection analysis >> that we are carrying out in our research centre. >> >> Thanks in advance, >> >> George >> >> > > It sounds like there were multiple cables that were lost recently. > For the EASSy cable issue in the Red Sea, an ISP in Malawi stated the > issues started at "09:26 on Friday 17 February". I don't know first > hand if that is accurate to the minute or not. I believe this is > separate from the cable off the cost of Kenya that was cut on the > 25th. > > Oliver timestamp is GMT+0(or maybe UTC) : 6413: Feb 17 07:17:53.606: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0/1/0, changed state to down yes, on NTP. Frank From bicknell at ufp.org Thu Mar 1 09:54:12 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 1 Mar 2012 07:54:12 -0800 Subject: Riverbed/Akamai/Rakamai In-Reply-To: References: Message-ID: <20120301155412.GA5576@ussenterprise.ufp.org> In a message written on Thu, Mar 01, 2012 at 10:09:27AM -0500, Kristian Kielhofner wrote: > Does anyone know what they actually "do" and how they do it? As usual > it's tough to cut through the marketing on the little detail they make > available (never a good sign). It's been a while since I looked at Riverbed, and it was part of a test with other providers of the same technologies. So I'll give you a general overview of the sorts of things they do. "WAN Optimizers" implment an array of tricks to get more throughput out of the same bandwidth: - Compression, simply compress the data as it flows. - TCP optimization, work around known issues with window scaling and other TCP throughput problems by being a man in the the middle and faking out one or both sides. - Tricking LAN protocols into working over the WAN. This was one of the first big selling points. Various MS LAN protocls weren't designed for high latency links with packet loss, and so by being a man in the middle dealing with the WAN and presenting an optimized view they worked much better. - Data deduplication, cache blocks of data repeatedly sent (file sharing read-only documents is a prime example) at the far end and re-serve them without going across a WAN. - Caching various "soft failures" (PMTU failures, unreachables, etc) to deliver them faster. Depending on your workload they may be total magic, getting gigabits of throughput from a T1, or snake oil, not making a bit of difference. The key in all cases is they have to be paired though, one on each end of the WAN (read low bandwidth and/or high latency) link. To date that has limited them to deployments inside of enterprises for the most part, and often to places with a hub and spoke topology otherwise the deployment gets complex quickly. What I'm hearing here is one of these "boxes" is in the Akamai node. Now if the enterprise customer has one at their site you have two end points for downloading Akamaized content. This may be able to optimize throughput (say, via compression or TCP optimization) or reduce load/costs (say via data deduplication) or both for a customer who happens to have a Riverbed box on their network. I've got no idea how effective this would be on standard Akamized content, but if you already own a Riverbed it's probably some "free" optimization. Is it enough to make you buy a Riverbed if you don't already own one? Interesting question. -- 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 mike at mtcc.com Thu Mar 1 09:56:41 2012 From: mike at mtcc.com (Michael Thomas) Date: Thu, 01 Mar 2012 07:56:41 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <201203011522.q21FM74H095011@aurora.sol.net> References: <201203011522.q21FM74H095011@aurora.sol.net> Message-ID: <4F4F9C39.8010509@mtcc.com> On 03/01/2012 07:22 AM, Joe Greco wrote: > It's deeper than just that, though. The whole paradigm is messy, from > the point of view of someone who just wants to get stuff done. The > examples are (almost?) all fatally flawed. The code that actually gets > at least some of it right ends up being too complex and too hard for > people to understand why things are done the way they are. > > Even in the "old days", before IPv6, geez, look at this: > > bcopy(host->h_addr_list[n], (char *)&addr->sin_addr.s_addr, sizeof(addr->sin_addr.s_addr)); > > That's real comprehensible - and it's essentially the data interface > between the resolver library and the system's addressing structures > for syscalls. > > On one hand, it's "great" that they wanted to abstract the dirty details > of DNS away from users, but I'd say they failed pretty much even at that. Yes, as simple as the normal kernel interface is for net io, getting to the point that you can do a connect() is both maddeningly messy and maddeningly inflexible -- the worst of all possible worlds. We shouldn't kid ourselves that DNS is a simple protocol though. It has layers of complexity and the policy decisions about address picking are not easy. But things like dealing with caching correctly shouldn't be that painful if done correctly by, say, discouraging copying addresses with, say, a wrapper function that validates the TTL and hands you back a filled out sockaddr. But not wanting to block -- which is needed for an event loop or run to completion like interface -- adds a completely new dimension. Maybe it's the intersection of all of these complexities that's at the root of why we're stuck with either gethostbyxx or roll your own. Mike From jra at baylink.com Thu Mar 1 10:04:43 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 1 Mar 2012 11:04:43 -0500 (EST) Subject: WW: Colo Vending Machine In-Reply-To: Message-ID: <19783864.2027.1330617883793.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Dale Shaw" > What about something like this? > > http://www.comsol.com.au/SL-PCC-01 While they might not sell to the US, that's roughly equivalent in formfactor to the Lantronix spider to which I posted a link... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From andree+nanog at toonk.nl Thu Mar 1 10:17:07 2012 From: andree+nanog at toonk.nl (Andree Toonk) Date: Thu, 01 Mar 2012 08:17:07 -0800 Subject: BBC reports Kenya fiber break In-Reply-To: <4F4F3D3B.4090404@iti.gr> References: <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx> <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com> <20120229135328.GF24032@netmeister.org> <4F4F3D3B.4090404@iti.gr> Message-ID: <4F4FA103.6020800@toonk.nl> Hi Georgios, .-- My secret spy satellite informs me that at 12-03-01 1:11 AM Georgios Theodoridis wrote: > Has it been known the exact time of the incident? > I have found an article reporting that the cut occurred in the mid-day > of Saturday 25th but nothing more precise. > We would like to use such information for a BGP anomaly detection > analysis that we are carrying out in our research centre. Looking at BGP data we can see large outages for both Kenya and Uganda starting at around 9:12 UTC on February the 25th. Also see: http://www.bgpmon.net/africa-feb25.png Cheers, Andree From david_laporte at harvard.edu Thu Mar 1 10:25:50 2012 From: david_laporte at harvard.edu (David LaPorte) Date: Thu, 01 Mar 2012 11:25:50 -0500 Subject: [nanog] Re: Switch designed for mirroring tap ports In-Reply-To: References: <4f4f5503.a81e340a.358a.49d2@mx.google.com> Message-ID: <4F4FA30E.1060704@harvard.edu> We're doing something similar - VACLs (using the "redirect" action) with port-channel destinations on a span aggregation 650x. If you've got a spare 650x chassis lying around and your configuration requirements aren't terribly complex/dynamic, you can do monitoring with filtering and load-balancing at high-throughput on it. On 03/01/12 06:03, David Swafford wrote: > Take a look at VACLs on the Cat side. It has a capture feature that is > effectively the same as a local SPAN, but without the 2 session limit. If > you do a lot of RSPAN though, this wouldn't be your complete answer (VACL > captures are local only). VACLs are a bit more granular in defining what's > captured, if say for example you only wanted traffic destined to TCP/80, > you could configure it that way. > > David. > > > On Thu, Mar 1, 2012 at 5:52 AM, Terry Baranski < > terry.baranski.list at gmail.com> wrote: > >> On Mar 1, 2012, at 02:13 AM, apishdadi at gmail.com wrote: >> >>> Hello All, >>> >>> We are looking for a switch or a device that we can use for mirroring >>> tap ports. For example , take a mirror port off of a core router say >>> a 6509, connect it to a port on said device, say port 1. I would like >>> then to be able to mirror port 1 on said device to multiple ports, >>> like port 2 , 3, 4. We have the need to analyze traffic from one port >>> on multiple devices. Seems most switches are limited to mirroring to a >>> max of 1 or 2 ports. >> >> We like Gigamon for this purpose. >> >> -Terry From stillwaxin at gmail.com Thu Mar 1 10:34:18 2012 From: stillwaxin at gmail.com (Michael Still) Date: Thu, 1 Mar 2012 11:34:18 -0500 Subject: Riverbed/Akamai/Rakamai In-Reply-To: References: Message-ID: Found this in one of my RSS feeds this am: http://www.youtube.com/watch?v=GNOXSmMfcGs Sort of explains it. On Thu, Mar 1, 2012 at 10:09 AM, Kristian Kielhofner wrote: > As long as we're talking about cloud networks, Akamai and Riverbed > have finally let out details on their partnership for "optimizing" > Cloud applications: > > http://www.nojitter.com/post/232601716/rakamai-makes-the-cloud-work-better > > While I'm familiar with Akamai (what they do and how they do it) I > don't have any experience with Riverbed. > > Does anyone know what they actually "do" and how they do it? ?As usual > it's tough to cut through the marketing on the little detail they make > available (never a good sign). > > -- > Kristian Kielhofner > -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ From bill at herrin.us Thu Mar 1 10:58:57 2012 From: bill at herrin.us (William Herrin) Date: Thu, 1 Mar 2012 11:58:57 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <4F4F8F3C.9090706@mtcc.com> References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net> <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com> <6252359949770844391@unknownmsgid> <34F84CED-8C8C-4EE3-A0FF-6001F4E3D7A2@delong.com> <4F4F8F3C.9090706@mtcc.com> Message-ID: On Thu, Mar 1, 2012 at 10:01 AM, Michael Thomas wrote: > On 03/01/2012 06:26 AM, William Herrin wrote: >> The even simpler approach: create an AF_NAME with a sockaddr struct >> that contains a hostname instead of an IPvX address. Then let >> connect() figure out the details of caching, TTLs, protocol and >> address selection, etc. ?Such a connect() could even support a revised >> TCP stack which is able to retry with the other addresses at the first >> subsecond timeout rather than camping on each address in sequence for >> the typical system default of two minutes. > > > The effect of what you're recommending is to move all of this > into the kernel, and in the process greatly expand its scope. Hi Michael, libc != kernel. I want to move the action into the standard libraries where it can be done once and done well. A little kernel action on top to parallelize connection attempts where there are multiple candidate addresses would be gravy, but not required. > even if you did this, you'd be saddled with the same problem because > nothing existing would use an AF_NAME. It won't instantly fix everything so we shouldn't do it at all? > what if I want, say, asynchronous > name resolution? What if I want to use SRV records? What if a new DNS > RR comes around Then you do it the long way, same as you do now. But in the 99% of the time that you're initiating a connection the "normal" way, you don't have to (badly) reinvent the wheel. > As far as > I could tell, standard distos don't have libraries with lower level access to > DNS (in my case, it needed to not block). Before positing a super-deluxe > gethostbyxx that does addresses picking, etc, etc it would be better to > lobby all of the distos to settle on a decomposed resolver library from > which that and more could be built. (A) Revised standards are -how- multiple OSes from multiple vendors coordinate the deployment of an identical capability. (B) Application programmers generally DO want the abstraction from "DNS" to "Name resolution." If there's an /etc/hosts name or a NIS name or a Windows name available, you ordinarily want to use it. You don't want to build extra code to search each name service independently any more than you want to build extra code to cycle through candidate addresses. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dwcarder at wisc.edu Thu Mar 1 11:06:49 2012 From: dwcarder at wisc.edu (Dale W. Carder) Date: Thu, 01 Mar 2012 11:06:49 -0600 Subject: Switch designed for mirroring tap ports In-Reply-To: <4F4F9435.9090805@utc.edu> References: <4F4F9435.9090805@utc.edu> Message-ID: <20120301170649.GE39388@ricotta.doit.wisc.edu> Thus spake Jeff Kell (jeff-kell at utc.edu) on Thu, Mar 01, 2012 at 10:22:29AM -0500: > How about splitting up a heavy stream (10G) into components (1G) to run through an > inline device and reassemble the pieces back to an aggregate afterward? Sounds like a perfect job for a commodity switch that supports OpenFlow. Dale From drc at virtualized.org Thu Mar 1 10:57:53 2012 From: drc at virtualized.org (David Conrad) Date: Thu, 1 Mar 2012 08:57:53 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <201203011522.q21FM74H095011@aurora.sol.net> References: <201203011522.q21FM74H095011@aurora.sol.net> Message-ID: <03668ADA-C440-4D1E-AD9A-72FCFB5F5F8F@virtualized.org> Hi, On Mar 1, 2012, at 7:22 AM, Joe Greco wrote: > On Mar 1, 2012, at 7:01 AM, Michael Thomas wrote: >> The effect of what you're recommending is to move all of this >> into the kernel, and in the process greatly expand its scope. Also: >> even if you did this, you'd be saddled with the same problem because >> nothing existing would use an AF_NAME. I always thought the right way to deal with IPv6 would have been to use a 32-bit number from the class E space as a 'network handle' where the actual address (be it IPv4 or IPv6) was handled by the kernel. I suspect this would have allowed the majority of network-utilizing applications to magically just work, regardless of whether the name supplied by gethosbyname/getnameinfo/etc. was mapped to an address with A or AAAA. Probably would make stuff faster too since you'd only have to deal with an unsigned int instead of (worst case) 16 bytes that have to be copied back and forth. Instead, we have forced application developers to use a really odd mixture of old and new, e.g. 'struct sockaddr_in6' and GNI/GAI. Seems this is the worst of both worlds -- no backwards compatibility yet an adherence to a really broken model that requires applications to know useless details like the length of an address ("what do you mean a sizeof(struct sockaddr) isn't big enough to hold an IPv6 address?") and even its bit patterns. >> Moving it across the kernel boundary solves nothing Actually, it does. Right now, applications effectively cache the address in their data space, requiring the application developer to go to quite a bit of work to deal with the address changing (or, far more typically, just pretend addresses never change). This has a lot of unfortunate side effects. >> and >> most likely causes even more trouble: what if I want, say, asynchronous >> name resolution? Set non-blocking on the socket? >> What if I want to use SRV records? What if a new DNS >> RR comes around -- do i have do recompile the kernel? I believe with the exception of A/AAAA, RDATA is typically returned as either opaque (to the DNS) data blobs or names. This means the only stuff the kernel would need to deal with would be the A/AAAA lookups, everything else would be passed back as data, presumably via a new system call. >> As far as >> I could tell, standard distos don't have libraries with lower level access to >> DNS (in my case, it needed to not block). There have been lower-level resolver APIs since (at least) BSD 4.3 (man resolver(3)). > It's deeper than just that, though. The whole paradigm is messy, from > the point of view of someone who just wants to get stuff done. The > examples are (almost?) all fatally flawed. The code that actually gets > at least some of it right ends up being too complex and too hard for > people to understand why things are done the way they are. Exactly. Even before IPv6, it was icky. Now, it's just crazy. We had an opportunity to fix this with IPv6 since IPv6 required non-trivial kernel hackage. Unfortunately, we didn't take advantage of that opportunity. Regards, -drc From jeroen at unfix.org Thu Mar 1 11:25:00 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 01 Mar 2012 18:25:00 +0100 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <03668ADA-C440-4D1E-AD9A-72FCFB5F5F8F@virtualized.org> References: <201203011522.q21FM74H095011@aurora.sol.net> <03668ADA-C440-4D1E-AD9A-72FCFB5F5F8F@virtualized.org> Message-ID: <4F4FB0EC.9060807@unfix.org> On 2012-03-01 17:57 , David Conrad wrote: > Hi, > > On Mar 1, 2012, at 7:22 AM, Joe Greco wrote: >> On Mar 1, 2012, at 7:01 AM, Michael Thomas wrote: >>> The effect of what you're recommending is to move all of this >>> into the kernel, and in the process greatly expand its scope. >>> Also: even if you did this, you'd be saddled with the same >>> problem because nothing existing would use an AF_NAME. > > I always thought the right way to deal with IPv6 would have been to > use a 32-bit number from the class E space as a 'network handle' > where the actual address (be it IPv4 or IPv6) was handled by the > kernel. This is the case when you pass in a sockaddr. Note, not a sockaddr_in or a sockaddr_in6, but just a sockaddr. There is a nice 14 year old article about this: http://www.kame.net/newsletter/19980604/ > I suspect this would have allowed the majority of > network-utilizing applications to magically just work, regardless of > whether the name supplied by gethosbyname/getnameinfo/etc. was mapped > to an address with A or AAAA. Probably would make stuff faster too > since you'd only have to deal with an unsigned int instead of (worst > case) 16 bytes that have to be copied back and forth. There is quite a bit more state than that. And actually those addresses are only 'copied' once: during accept() or connect(), there is no "speed-loss" per send/recv as the only thing being moved from user space to kernel space is the file descriptor and the actual data. [..] > Instead, we have forced application developers to use a really odd > mixture of old and new, e.g. 'struct sockaddr_in6' and GNI/GAI. > Seems this is the worst of both worlds -- no backwards compatibility > yet an adherence to a really broken model that requires applications > to know useless details like the length of an address ("what do you > mean a sizeof(struct sockaddr) isn't big enough to hold an IPv6 > address?") and even its bit patterns. Ever heard of sockaddr_storage? It was made to solve that little issue. See also, that article above. [..] > Exactly. Even before IPv6, it was icky. Now, it's just crazy. We > had an opportunity to fix this with IPv6 since IPv6 required > non-trivial kernel hackage. Unfortunately, we didn't take advantage > of that opportunity. What you are talking about is an API wrapper. Depending on platform these have existed for years already. Quite a few do not expose addresses at all to the calling code. One of the many reasons why putting the IPv6 enabled winsock dll in place 14 years ago made various winsock applications understand IPv6. Greets, Jeroen From smb at cs.columbia.edu Thu Mar 1 11:59:45 2012 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 1 Mar 2012 12:59:45 -0500 Subject: BBC reports Kenya fiber break In-Reply-To: References: <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx> <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com> <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com> Message-ID: <645ACDFD-15AA-4B99-9526-2D5597463766@cs.columbia.edu> On Feb 29, 2012, at 11:17 17AM, Marshall Eubanks wrote: > On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner > wrote: >> On Wed, 29 Feb 2012, Rodrick Brown wrote: >> >>> There's about 1/2 a dozen or so known private and government research >>> facilities on Antarctica and I'm surprised to see no fiber end points on >>> that continent? This can't be true. >> >> >> Constantly shifting ice shelves and glaciers make a terrestrial cable >> landing very difficult to implement on Antarctica. Satellite connectivity >> is likely the only feasible option. There are very few places in >> Antarctica that are reliably ice-free enough of the time to make a viable >> terrestrial landing station. Getting connectivity from the landing station >> to other places on the continent is another matter altogether. > > Apparently at least one long fiber pull has been contemplated. > > http://news.bbc.co.uk/2/hi/sci/tech/2207259.stm > > (Note : the headline is incorrect - the Internet reached the South Pole in 1994, > via satellite, of course : > http://www.southpolestation.com/trivia/90s/ftp1.html ) > > As far as I can tell, this was never done, and the South Pole gets its > Internet mostly via > TDRSS. > > http://www.usap.gov/technology/contentHandler.cfm?id=1971 Yes. I had discussions with some of their network support folks circa 1994 -- with limited bandwidth (DS0, as I recall) and only a few hours of connectivity per day, when a satellite was over the horizon, they were very concerned about attackers clogging their link. --Steve Bellovin, https://www.cs.columbia.edu/~smb From mike at mtcc.com Thu Mar 1 12:00:17 2012 From: mike at mtcc.com (Michael Thomas) Date: Thu, 01 Mar 2012 10:00:17 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <03668ADA-C440-4D1E-AD9A-72FCFB5F5F8F@virtualized.org> References: <201203011522.q21FM74H095011@aurora.sol.net> <03668ADA-C440-4D1E-AD9A-72FCFB5F5F8F@virtualized.org> Message-ID: <4F4FB931.5000200@mtcc.com> On 03/01/2012 08:57 AM, David Conrad wrote: > >> Moving it across the kernel boundary solves nothing > Actually, it does. Right now, applications effectively cache the address in their data space, requiring the application developer to go to quite a bit of work to deal with the address changing (or, far more typically, just pretend addresses never change). This has a lot of unfortunate side effects. My rule of thumb is for this sort of thing "does it *require* kernel level access?" In this case, the answer is manifestly "no". As far as ttl's go in particular, most apps would work perfectly well always doing real DNS socket IO to a local resolver each time which has the side effect that it would honor ttl, as well as benefiting from cross process caching. It could be done in the kernel, but it would be introducing a *lot* of complexity and inflexibility. Even if you did want super high performance local DNS resolution, there are still a lot of other ways to achieve that besides jamming it into the kernel. A lot of the beauty of UNIX is that the kernel system interface is simple... dragging more into the kernel is aesthetically wrong. >>> What if I want to use SRV records? What if a new DNS >>> RR comes around -- do i have do recompile the kernel? > I believe with the exception of A/AAAA, RDATA is typically returned as either opaque (to the DNS) data blobs or names. This means the only stuff the kernel would need to deal with would be the A/AAAA lookups, everything else would be passed back as data, presumably via a new system call. SRV records? This is starting to get really messy inside the kernel and for no good reason that I can see. > >>> As far as >>> I could tell, standard distos don't have libraries with lower level access to >>> DNS (in my case, it needed to not block). > There have been lower-level resolver APIs since (at least) BSD 4.3 (man resolver(3)). This is all getting sort of hazy since it was 8 years ago, but yes res_XX existed, and hence the ares_ analog that I used. Maybe all that's really needed for low level access primitives is a merger of res_ and ares_... asynchronous resolution is a fairly important feature for modern event loop like things. But I don't claim to be a DNS wonk so it might be worse than that. Mike From mike at mtcc.com Thu Mar 1 12:32:44 2012 From: mike at mtcc.com (Michael Thomas) Date: Thu, 01 Mar 2012 10:32:44 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net> <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com> <6252359949770844391@unknownmsgid> <34F84CED-8C8C-4EE3-A0FF-6001F4E3D7A2@delong.com> <4F4F8F3C.9090706@mtcc.com> Message-ID: <4F4FC0CC.9090601@mtcc.com> On 03/01/2012 08:58 AM, William Herrin wrote: > On Thu, Mar 1, 2012 at 10:01 AM, Michael Thomas wrote: >> On 03/01/2012 06:26 AM, William Herrin wrote: >>> The even simpler approach: create an AF_NAME with a sockaddr struct >>> that contains a hostname instead of an IPvX address. Then let >>> connect() figure out the details of caching, TTLs, protocol and >>> address selection, etc. Such a connect() could even support a revised >>> TCP stack which is able to retry with the other addresses at the first >>> subsecond timeout rather than camping on each address in sequence for >>> the typical system default of two minutes. >> >> The effect of what you're recommending is to move all of this >> into the kernel, and in the process greatly expand its scope. > Hi Michael, > > libc != kernel. I want to move the action into the standard libraries > where it can be done once and done well. A little kernel action on top > to parallelize connection attempts where there are multiple candidate > addresses would be gravy, but not required. connect(2) is a kernel level call just like open(2), etc. It may have a thin wrapper, but that's OS dependent, IIRC. man connect 2: "The connect() system call connects the socket referred to by the file descriptor..." Mike From bill at herrin.us Thu Mar 1 12:49:18 2012 From: bill at herrin.us (William Herrin) Date: Thu, 1 Mar 2012 13:49:18 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <4F4FC0CC.9090601@mtcc.com> References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net> <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com> <6252359949770844391@unknownmsgid> <34F84CED-8C8C-4EE3-A0FF-6001F4E3D7A2@delong.com> <4F4F8F3C.9090706@mtcc.com> <4F4FC0CC.9090601@mtcc.com> Message-ID: On Thu, Mar 1, 2012 at 1:32 PM, Michael Thomas wrote: > On 03/01/2012 08:58 AM, William Herrin wrote: >> libc != kernel. I want to move the action into the standard libraries >> where [resolve and connect] can be done once and done well. >> A little kernel action on top >> to parallelize connection attempts where there are multiple candidate >> addresses would be gravy, but not required. > > connect(2) is a kernel level call just like open(2), etc. It may > have a thin wrapper, but that's OS dependent, IIRC. > > man connect 2: > > "The connect() system call connects the socket referred to by the file > descriptor..." Then name the new one something else and document it in man section 3. Next objection? -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From drc at virtualized.org Thu Mar 1 13:11:51 2012 From: drc at virtualized.org (David Conrad) Date: Thu, 1 Mar 2012 11:11:51 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <4F4FB931.5000200@mtcc.com> References: <201203011522.q21FM74H095011@aurora.sol.net> <03668ADA-C440-4D1E-AD9A-72FCFB5F5F8F@virtualized.org> <4F4FB931.5000200@mtcc.com> Message-ID: <9B163C2E-83C9-4692-B0E0-055045389A3A@virtualized.org> Michael, On Mar 1, 2012, at 10:00 AM, Michael Thomas wrote: > My rule of thumb is for this sort of thing "does it *require* kernel level access?" > In this case, the answer is manifestly "no". This is tilting at windmills since it's wildly unlikely anything will change, but... The idea is to add a level of indirection that does not currently exist, similar to the mapping of filename/file handle/inode in the filesystem. This layer of indirection allows the kernel to remap things as it sees fit without impacting the application. If such functionality existed, the kernel could manage the mapping between name and address to do things like honoring DNS TTL, transparently handling renumbering events, deal with protocol transitions even during a connection, etc. As things are now, it's like having to rewrite non-tivial sections of code for _all_ disk-aware applications because we've gone from a 32-bit file system to a 64-bit file system, even though the vast majority of those applications couldn't care less. > SRV records? Do not have addresses in their RDATA, they have names. Regards, -drc From drc at virtualized.org Thu Mar 1 13:27:51 2012 From: drc at virtualized.org (David Conrad) Date: Thu, 1 Mar 2012 11:27:51 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <4F4FB0EC.9060807@unfix.org> References: <201203011522.q21FM74H095011@aurora.sol.net> <03668ADA-C440-4D1E-AD9A-72FCFB5F5F8F@virtualized.org> <4F4FB0EC.9060807@unfix.org> Message-ID: <9CA1D9D3-5877-4AA4-B419-1E6C11338E34@virtualized.org> Jeroen, On Mar 1, 2012, at 9:25 AM, Jeroen Massar wrote: >> I always thought the right way to deal with IPv6 would have been to >> use a 32-bit number from the class E space as a 'network handle' >> where the actual address (be it IPv4 or IPv6) was handled by the >> kernel. > > This is the case when you pass in a sockaddr. Note, not a sockaddr_in or > a sockaddr_in6, but just a sockaddr. Sorry? On which system? As far as I'm aware, there are no libraries that make use of class E addresses to act as a layer of indirection similar to file handles. Would love to know such exists. > There is a nice 14 year old article about this: > http://www.kame.net/newsletter/19980604/ Quoting from that article: "This way the network address and address family is will not live together, and leads to bunch of if/switch statement and mistakes in programming. " which is exactly the point. It has been 14 years and people are _STILL_ discussing this. > And actually those addresses > are only 'copied' once: during accept() or connect(), Assuming the application doesn't need to copy the address, ever. > Ever heard of sockaddr_storage? Oddly, yes. It still astonishes me that sizeof(struct sockaddr) < sizeof(struct sockaddr_storage). > It was made to solve that little issue. See also, that article above. Thus requiring people to go in and muck with code thereby increasing the cost of migration with obvious effect. > What you are talking about is an API wrapper. Depending on platform > these have existed for years already. Quite a few do not expose > addresses at all to the calling code. And yet, look at the code Mark Andrews just referenced as his recommend way of dealing with initiating connections. How many applications actually do anything like that? More to the point, how many books/article/etc. exist that reference these APIs you're talking about vs. how many reference the traditional way one goes about dealing with networks? Rhetorical questions, no need to answer. Got tired of tilting at this windmill some time ago and I know nothing will change. I'm just amazed that people defend the abominable kludge that are the existing common sockets/resolver APIs. Regards, -drc From roberts at bluenile.com Thu Mar 1 14:13:47 2012 From: roberts at bluenile.com (Robert Suh) Date: Thu, 1 Mar 2012 12:13:47 -0800 Subject: Reliable Cloud host ? In-Reply-To: References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net> <42252.1330372433@turing-police.cc.vt.edu> <94C79C67-4111-44C0-9A0E-BC0552AA175D@delong.com> Message-ID: Check out Firehost. Just came back from RSA2012 and talked with them. VPS provider using VMWare ESX with Dell/Compellent (auto tiered with SSD) for storage. They offer DDoS mitigation (they use Arbor) out of the box along with managed firewall and web application firewall. More expensive than EC2, but their high touch features seems worthwhile. Live support is included. Rob -----Original Message----- From: Bobby Mac [mailto:bobbyjim at gmail.com] Sent: Wednesday, February 29, 2012 1:24 PM To: Tei Cc: Nanog Subject: Re: Reliable Cloud host ? HP has built an Openstack based cloud. I got a beta account and things are surprisingly stable. hpcloud dot com On Wed, Feb 29, 2012 at 1:12 PM, Tei wrote: > related to the topic: > > http://slashdot.org/story/12/02/29/153226/microsofts-azure-cloud-suffers-major-downtime > > -- > -- > ?in del ?ensaje. > > From owen at delong.com Thu Mar 1 14:46:40 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Mar 2012 12:46:40 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net> <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com> <6252359949770844391@unknownmsgid> <34F84CED-8C8C-4EE3-A0FF-6001F4E3D7A2@delong.com> Message-ID: <7F71CCA9-BE0E-49EE-BA87-DD541845AC86@delong.com> On Mar 1, 2012, at 6:26 AM, William Herrin wrote: > On Thu, Mar 1, 2012 at 7:20 AM, Owen DeLong wrote: >> The simpler approach and perfectly viable without mucking >> up what is already implemented and working: >> >> Don't keep returns from GAI/GNI around longer than it takes >> to cycle through your connect() loop immediately after the GAI/GNI call. > > The even simpler approach: create an AF_NAME with a sockaddr struct > that contains a hostname instead of an IPvX address. Then let > connect() figure out the details of caching, TTLs, protocol and > address selection, etc. Such a connect() could even support a revised > TCP stack which is able to retry with the other addresses at the first > subsecond timeout rather than camping on each address in sequence for > the typical system default of two minutes. > That's not simpler for the following reasons: 1. It takes away abilities to manage the connect() process that some applications want. 2. It requires a rewrite of a whole lot of software built on the current mechanisms. Most systems provide a mechanism for overriding the timeout for connect(). Further, there are lots of classes, libraries, etc. that you can already use if you want to abstract the gai/gni + connect functionality. What exists isn't broken at the API level. Please stop trying to fix what is not broken. Owen From owen at delong.com Thu Mar 1 15:07:31 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Mar 2012 13:07:31 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <201203011522.q21FM74H095011@aurora.sol.net> References: <201203011522.q21FM74H095011@aurora.sol.net> Message-ID: > > It's deeper than just that, though. The whole paradigm is messy, from > the point of view of someone who just wants to get stuff done. The > examples are (almost?) all fatally flawed. The code that actually gets > at least some of it right ends up being too complex and too hard for > people to understand why things are done the way they are. > > Even in the "old days", before IPv6, geez, look at this: > > bcopy(host->h_addr_list[n], (char *)&addr->sin_addr.s_addr, sizeof(addr->sin_addr.s_addr)); > > That's real comprehensible - and it's essentially the data interface > between the resolver library and the system's addressing structures > for syscalls. > > On one hand, it's "great" that they wanted to abstract the dirty details > of DNS away from users, but I'd say they failed pretty much even at that. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then I > won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) > With 24 million small businesses in the US alone, that's way too many apples. I think that the modern set of getaddrinfo and connect is actually not that complicated: /* Hints for getaddrinfo() (tell it what we want) */ memset(&addrinfo, 0, sizeof(addrinfo)); /* Zero out the buffer */ addrinfo.ai_family=PF_UNSPEC; /* Any and all address families */ addrinfo.ai_socktype=SOCK_STREAM; /* Stream Socket */ addrinfo.ai_protocol=IPPROTO_TCP; /* TCP */ /* Ask the resolver library for the information. Exit on failure. */ /* argv[1] is the hostname passed in by the user. "demo" is the service name */ if (rval = getaddrinfo(argv[1], "demo", &addrinfo, &res) != 0) { fprintf(stderr, "%s: Failed to resolve address information.\n", argv[0]); exit(2); } /* Iterate through the results */ for (r=res; r; r = r->ai_next) { /* Create a socket configured for the next candidate */ sockfd6 = socket(r->ai_family, r->ai_socktype, r->ai_protocol); /* Try to connect */ if (connect(sockfd6, r->ai_addr, r->ai_addrlen) < 0) { /* Failed to connect */ e_save = errno; /* Destroy socket */ (void) close(sockfd6); /* Recover the error information */ errno = e_save; /* Tell the user that this attempt failed */ fprintf(stderr, "%s: Failed attempt to %s.\n", argv[0], get_ip_str((struct sockaddr *)r->ai_addr, buf, BUFLEN)); /* Give error details */ perror("Socket error"); } else { /* Success! */ /* Inform the user */ snprintf(s, BUFLEN, "%s: Succeeded to %s.", argv[0], get_ip_str((struct sockaddr *)r->ai_addr, buf, BUFLEN)); debug(5, argv[0], s); /* Flag our success */ success++; /* Stop iterating */ break; } } /* Out of the loop. Either we succeeded or ran out of possibilities */ if (success == 0) /* If we ran out of possibilities... */ { /* Inform the user, free up the resources, and exit */ fprintf(stderr, "%s: Failed to connect to %s.\n", argv[0], argv[1]); freeaddrinfo(res); exit(5); } /* Succeeded. Inform the user and continue with the application */ printf("%s: Successfully connected to %s at %s on FD %d.\n", argv[0], argv[1], get_ip_str((struct sockaddr *)r->ai_addr, buf, BUFLEN), sockfd6); /* Free up the memory held by the resolver results */ freeaddrinfo(res); It's really hard to make a case that this is all that complex. I put a lot of extra comments in there to make it clear what's happening for people who may not be used to coding in C. It also contains a whole lot of extra user notification and debugging instrumentation because it is designed as an example people can use to learn with. Yes, this was a lot messier and a lot stranger and harder to get right with get*by{name,addr}, but, those days are long gone and anyone still coding with those needs to move forward. Owen From marka at isc.org Thu Mar 1 15:45:44 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 02 Mar 2012 08:45:44 +1100 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: Your message of "Thu, 01 Mar 2012 13:07:31 -0800." References: <201203011522.q21FM74H095011@aurora.sol.net> Message-ID: <20120301214544.672591DFCDE3@drugs.dv.isc.org> In message , Owen DeLong write s: > >=20 > > It's deeper than just that, though. The whole paradigm is messy, from > > the point of view of someone who just wants to get stuff done. The > > examples are (almost?) all fatally flawed. The code that actually = > gets > > at least some of it right ends up being too complex and too hard for > > people to understand why things are done the way they are. > >=20 > > Even in the "old days", before IPv6, geez, look at this: > >=20 > > bcopy(host->h_addr_list[n], (char *)&addr->sin_addr.s_addr, = > sizeof(addr->sin_addr.s_addr)); > >=20 > > That's real comprehensible - and it's essentially the data interface=20= > > > between the resolver library and the system's addressing structures > > for syscalls. > >=20 > > On one hand, it's "great" that they wanted to abstract the dirty = > details > > of DNS away from users, but I'd say they failed pretty much even at = > that. > >=20 > > ... JG > > --=20 > > 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. > > I think that the modern set of getaddrinfo and connect is actually not = > that complicated: > > /* Hints for getaddrinfo() (tell it what we want) */ > memset(&addrinfo, 0, sizeof(addrinfo)); /* Zero out the buffer = > */ > addrinfo.ai_family=3DPF_UNSPEC; /* Any and all = > address families */ > addrinfo.ai_socktype=3DSOCK_STREAM; /* Stream Socket */ > addrinfo.ai_protocol=3DIPPROTO_TCP; /* TCP */ > /* Ask the resolver library for the information. Exit on failure. */ > /* argv[1] is the hostname passed in by the user. "demo" is the = > service name */ > if (rval =3D getaddrinfo(argv[1], "demo", &addrinfo, &res) !=3D 0) { > fprintf(stderr, "%s: Failed to resolve address information.\n", = > argv[0]); > exit(2); > } > > /* Iterate through the results */ > for (r=3Dres; r; r =3D r->ai_next) { > /* Create a socket configured for the next candidate */ > sockfd6 =3D socket(r->ai_family, r->ai_socktype, r->ai_protocol); > /* Try to connect */ > if (connect(sockfd6, r->ai_addr, r->ai_addrlen) < 0) > { > /* Failed to connect */ > e_save =3D errno; > /* Destroy socket */ > (void) close(sockfd6); > /* Recover the error information */ > errno =3D e_save; > /* Tell the user that this attempt failed */ > fprintf(stderr, "%s: Failed attempt to %s.\n", argv[0],=20 > get_ip_str((struct sockaddr *)r->ai_addr, buf, BUFLEN)); > /* Give error details */ > perror("Socket error"); > } else { /* Success! */ > /* Inform the user */ > snprintf(s, BUFLEN, "%s: Succeeded to %s.", argv[0], > get_ip_str((struct sockaddr *)r->ai_addr, buf, BUFLEN)); > debug(5, argv[0], s); > /* Flag our success */ > success++; > /* Stop iterating */ > break; > } > } > /* Out of the loop. Either we succeeded or ran out of possibilities */ > if (success =3D=3D 0) /* If we ran out of possibilities... */ > { > /* Inform the user, free up the resources, and exit */ > fprintf(stderr, "%s: Failed to connect to %s.\n", argv[0], argv[1]); > freeaddrinfo(res); > exit(5); > } > /* Succeeded. Inform the user and continue with the application */ > printf("%s: Successfully connected to %s at %s on FD %d.\n", argv[0], = > argv[1], > get_ip_str((struct sockaddr *)r->ai_addr, buf, BUFLEN), > sockfd6); > /* Free up the memory held by the resolver results */ > freeaddrinfo(res); > > It's really hard to make a case that this is all that complex. > > I put a lot of extra comments in there to make it clear what's happening = > for people who may not be used to coding in C. It also contains a whole = > lot of extra user notification and debugging instrumentation because it = > is designed as an example people can use to learn with.=20 > > Yes, this was a lot messier and a lot stranger and harder to get right = > with get*by{name,addr}, but, those days are long gone and anyone still = > coding with those needs to move forward. > > Owen > These days you want something more complicated as everyone is or will be soon multi-homed. The basic loop above has very bad error characteristics if the first machines are not reachable. I've got working select, poll and thread based examples here: http://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp. >From http://www.isc.org/files/imce/select-connect_0.c: /* * Copyright (C) 2011 Internet Systems Consortium, Inc. ("ISC") * * Permission to use, copy, modify, and/or distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR * PERFORMANCE OF THIS SOFTWARE. */ #define TIMEOUT 500 /* ms */ int connect_to_host(struct addrinfo *res0) { struct addrinfo *res; int fd = -1, n, i, j, flags, count, max = -1, *fds; struct timeval *timeout, timeout0 = { 0, TIMEOUT * 1000}; fd_set fdset, wrset; /* * Work out how many possible descriptors we could use. */ for (res = res0, count = 0; res; res = res->ai_next) count++; fds = calloc(count, sizeof(*fds)); if (fds == NULL) { perror("calloc"); goto cleanup; } FD_ZERO(&fdset); for (res = res0, i = 0, count = 0; res; res = res->ai_next) { fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol); if (fd == -1) { /* * If AI_ADDRCONFIG is not supported we will get * EAFNOSUPPORT returned. Behave as if the address * was not there. */ if (errno != EAFNOSUPPORT) perror("socket"); else if (res->ai_next != NULL) continue; } else if (fd >= FD_SETSIZE) { close(fd); } else if ((flags = fcntl(fd, F_GETFL)) == -1) { perror("fcntl"); close(fd); } else if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) { perror("fcntl"); close(fd); } else if (connect(fd, res->ai_addr, res->ai_addrlen) == -1) { if (errno != EINPROGRESS) { perror("connect"); close(fd); } else { /* * Record the information for this descriptor. */ fds[i] = fd; FD_SET(fd, &fdset); if (max == -1 || fd > max) max = fd; count++; i++; } } else { /* * We connected without blocking. */ goto done; } if (count == 0) continue; assert(max != -1); do { if (res->ai_next != NULL) timeout = &timeout0; else timeout = NULL; /* The write bit is set on both success and failure. */ wrset = fdset; n = select(max + 1, NULL, &wrset, NULL, timeout); if (n == 0) { timeout0.tv_usec >>= 1; break; } if (n < 0) { if (errno == EAGAIN || errno == EINTR) continue; perror("select"); fd = -1; goto done; } for (fd = 0; fd <= max; fd++) { if (FD_ISSET(fd, &wrset)) { socklen_t len; int err; for (j = 0; j < i; j++) if (fds[j] == fd) break; assert(j < i); /* * Test to see if the connect * succeeded. */ len = sizeof(err); n = getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &len); if (n != 0 || err != 0) { close(fd); FD_CLR(fd, &fdset); fds[j] = -1; count--; continue; } /* Connect succeeded. */ goto done; } } } while (timeout == NULL && count != 0); } /* We failed to connect. */ fd = -1; done: /* Close all other descriptors we have created. */ for (j = 0; j < i; j++) if (fds[j] != fd && fds[j] != -1) { close(fds[j]); } if (fd != -1) { /* Restore default blocking behaviour. */ if ((flags = fcntl(fd, F_GETFL)) != -1) { flags &= ~O_NONBLOCK; if (fcntl(fd, F_SETFL, flags) == -1) perror("fcntl"); } else perror("fcntl"); } cleanup: /* Free everything. */ if (fds) free(fds); return (fd); } -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dennis at justipit.com Thu Mar 1 16:01:08 2012 From: dennis at justipit.com (dennis) Date: Thu, 1 Mar 2012 17:01:08 -0500 Subject: Switch designed for mirroring tap ports In-Reply-To: References: <4f4f5503.a81e340a.358a.49d2@mx.google.com> Message-ID: NetOptics has some very nice gear ; take a look at the Director series with aggregation, load balancing and filtering based on physical port, ip, protocol, etc. Dennis -------------------------------------------------- From: "Chris Mills" Sent: Thursday, March 01, 2012 7:03 AM To: "Terry Baranski" Cc: "NANOG" Subject: RE: Switch designed for mirroring tap ports > Echoing what Terry said... we use gigamon devices for this too. > > -Chris > On Mar 1, 2012 5:53 AM, "Terry Baranski" > wrote: > >> On Mar 1, 2012, at 02:13 AM, apishdadi at gmail.com wrote: >> >> > Hello All, >> > >> > We are looking for a switch or a device that we can use for mirroring >> > tap ports. For example , take a mirror port off of a core router say >> > a 6509, connect it to a port on said device, say port 1. I would like >> > then to be able to mirror port 1 on said device to multiple ports, >> > like port 2 , 3, 4. We have the need to analyze traffic from one port >> > on multiple devices. Seems most switches are limited to mirroring to a >> > max of 1 or 2 ports. >> >> We like Gigamon for this purpose. >> >> -Terry >> >> >> >> > From bill at herrin.us Thu Mar 1 16:09:45 2012 From: bill at herrin.us (William Herrin) Date: Thu, 1 Mar 2012 17:09:45 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <201203011522.q21FM74H095011@aurora.sol.net> Message-ID: On Thu, Mar 1, 2012 at 4:07 PM, Owen DeLong wrote: > I think that the modern set of getaddrinfo and connect is actually not that complicated: Owen, If took you 50 lines of code to do 'socket=connect("www.google.com",80,TCP);' and you still managed to produce a version which, due to the timeout on dead addresses, is worthless for any kind of interactive program like a web browser. And because that code isn't found in a system library, every single application programmer has to write it all over again. I'm a fan of Rube Goldberg machines but that was ridiculous. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marka at isc.org Thu Mar 1 16:29:54 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 02 Mar 2012 09:29:54 +1100 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: Your message of "Thu, 01 Mar 2012 17:09:45 CDT." References: <201203011522.q21FM74H095011@aurora.sol.net> Message-ID: <20120301222954.D47AA1DFD191@drugs.dv.isc.org> In message , William Herrin writes: > On Thu, Mar 1, 2012 at 4:07 PM, Owen DeLong wrote: > > I think that the modern set of getaddrinfo and connect is actually not th= > at complicated: > > Owen, > > If took you 50 lines of code to do > 'socket=connect("www.google.com",80,TCP);' and you still managed to > produce a version which, due to the timeout on dead addresses, is > worthless for any kind of interactive program like a web browser. And > because that code isn't found in a system library, every single > application programmer has to write it all over again. And your 'socket=connect("www.google.com",80,TCP);' won't work for a web browser either unless you are using threads and are willing to have the thread stall. The existing connect() semantics actually work well for browsers but they need to be properly integrated into the system as a whole. Nameservers have similar connect() issues as web browsers with one advantage, most of the time we are connecting to a machine we have just connected to via UDP. That doesn't mean we don't do non-blocking connect however. > I'm a fan of Rube Goldberg machines but that was ridiculous. > > Regards, > Bill Herrin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Thu Mar 1 16:37:07 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Mar 2012 14:37:07 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <201203011522.q21FM74H095011@aurora.sol.net> Message-ID: William, I could have done it in a lot less lines of code, but, it would have been much less readable. Not blocking on the connect() call is a little more complex, but, not terribly so. It does, however, again, make the code quite a bit less readable. There are libraries available that abstract everything I did there and you are welcome to use them. Since C does not support overloading, they export different functions for the behavior you seek. If you want, program in Python where the libraries do provide the abstraction you seek. Of course, that means you have to cope with Python's other disgusting habits like spaces are meaningful and variables are indistinguishable from code, but, there's always a tradeoff. You don't have to reinvent what I've done. Neither does every or any other application programmer. You are welcome to use any of the many connection abstraction libraries that are available in open source. I suggest you make a trip through google code. Owen On Mar 1, 2012, at 2:09 PM, William Herrin wrote: > On Thu, Mar 1, 2012 at 4:07 PM, Owen DeLong wrote: >> I think that the modern set of getaddrinfo and connect is actually not that complicated: > > Owen, > > If took you 50 lines of code to do > 'socket=connect("www.google.com",80,TCP);' and you still managed to > produce a version which, due to the timeout on dead addresses, is > worthless for any kind of interactive program like a web browser. And > because that code isn't found in a system library, every single > application programmer has to write it all over again. > > I'm a fan of Rube Goldberg machines but that was ridiculous. > > Regards, > Bill Herrin > > > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From bifrost at minions.com Thu Mar 1 16:55:18 2012 From: bifrost at minions.com (Tom) Date: Thu, 1 Mar 2012 14:55:18 -0800 (PST) Subject: Reliable Cloud host ? In-Reply-To: References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> Message-ID: On Mon, 27 Feb 2012, William Herrin wrote: > Why would you imagine that a $30/month virtual private server is built > on an enterprise-grade virtualization cluster? A lot of the time "the cloud" is billed as just that. The reality is that its more often a federated cluster of machines with some duct tape and glue. Sometimes that duct tape is name brand, sometimes its not. There are currently no viable OSS solutions that actually do HA in terms of storage nor VMs. Its all basically storage+machine provisioning, no healthchecking and no real auto-recovery. I've spent a fair amount of time digging into this for my business, and thats my state of the world. That said, if you want HA or even "failover" with any provider, you basically need to look at an expensive VMWare based solution. There are projects out there to build truly HA OSS "clouds" but they're not ready yet, and they're not terribly cheap either. -Tom From bill at herrin.us Thu Mar 1 16:57:11 2012 From: bill at herrin.us (William Herrin) Date: Thu, 1 Mar 2012 17:57:11 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <201203011522.q21FM74H095011@aurora.sol.net> Message-ID: On Thu, Mar 1, 2012 at 5:37 PM, Owen DeLong wrote: > You don't have to reinvent what I've done. Neither does every > or any other application programmer. > You are welcome to use any of the many connection > abstraction libraries that are available in open source. > I suggest you make a trip through google code. Which is what everybody basically does. And when it works during the decidedly non-rigorous testing, they move on to the next problem... with code that doesn't perform well in the corner cases. Such as when a host has just been renumbered or one of the host's addresses is unreachable. And because most everybody has made more or less the same errors, the DNS TTL fails to cause their applications to work as intended and loses its utility as a tool to facilitate renumbering. > If you want, program in Python where the libraries do > provide the abstraction you seek. Of course, that > means you have to cope with Python's other disgusting > habits like spaces are meaningful and variables are > indistinguishable from code, but, there's always a tradeoff. ::shudder:: I don't *want* to do anything in python. The occasional reality of a situation dictates that I do some work in python, but I most definitely don't *want* to. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cra at WPI.EDU Thu Mar 1 17:01:24 2012 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 1 Mar 2012 18:01:24 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <201203011522.q21FM74H095011@aurora.sol.net> Message-ID: <20120301230124.GR22535@angus.ind.WPI.EDU> On Thu, Mar 01, 2012 at 05:57:11PM -0500, William Herrin wrote: > Which is what everybody basically does. And when it works during the > decidedly non-rigorous testing, they move on to the next problem... > with code that doesn't perform well in the corner cases. Such as when > a host has just been renumbered or one of the host's addresses is > unreachable. > > And because most everybody has made more or less the same errors, the > DNS TTL fails to cause their applications to work as intended and > loses its utility as a tool to facilitate renumbering. Is there an RFC or BCP that describes how to correctly write such a library? Perhaps we need to work to get such a thing, and then push for RFC-compliance of the resolver libraries, or develop a set of libraries named after and fully compliant with the RFC and get software to use them. From cowie at renesys.com Thu Mar 1 17:22:35 2012 From: cowie at renesys.com (Jim Cowie) Date: Thu, 1 Mar 2012 18:22:35 -0500 Subject: BBC reports Kenya fiber break In-Reply-To: <4F4F3D3B.4090404@iti.gr> References: <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx> <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com> <20120229135328.GF24032@netmeister.org> <4F4F3D3B.4090404@iti.gr> Message-ID: On Thu, Mar 1, 2012 at 4:11 AM, Georgios Theodoridis wrote: > Has it been known the exact time of the incident? > I have found an article reporting that the cut occurred in the mid-day of > Saturday 25th but nothing more precise. > We would like to use such information for a BGP anomaly detection analysis > that we are carrying out in our research centre. > > Thanks in advance, > > George > > > Renesys published a brief writeup of the incident yesterday. We called it at 09:13 UTC on the 25th. Lots of interesting outage and transit-shift effects to see in the East African BGP data that day. We also report some shifts in latency based on active measurement, as everyone's traffic jumps onto the surviving connectivity through SEACOM. Kenya Data Networks (AS33770) did a particularly good job staying alive by virtue of their upstream provider diversity, kudos to them. http://www.renesys.com/blog/2012/02/east-african-cable-breaks.shtml best, --jim From jeroen at mompl.net Thu Mar 1 17:44:07 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 01 Mar 2012 15:44:07 -0800 Subject: Reliable Cloud host ? In-Reply-To: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net> References: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net> Message-ID: <4F5009C7.5070201@mompl.net> Randy Carpenter wrote: > Does anyone have any recommendation for a reliable cloud host? > Basic requirements: > > 1. Full redundancy with instant failover to other hypervisor hosts upon hardware failure (I thought this was a given!) Assuming a simple set up as you suggest. If what you want to do is a lot more complex it would be worth your while to use your own hardware at a coloc, and alternatively set up your own VPSes. I think your best bet is to design your systems with failover taken into account and not to depend on the VPS provider to provide you this. Say you want smtp in addition to DNS. You would set up a VPS in 2 different locations (or more) using 2 different VPS providers. You set up your favourite name server and email server on each server, configure your mx records to point to both and you tell your registrar to use both servers as the nameserver for your domain(s). When a server goes ofline dns queries and emails automagically go to the other server. No need to depend on one single VPS provider and their crappy infrastructure. > 3. reasonable pricing (No, $800/month is not reasonable when I need a tiny 256MB RAM Server with <1GB/mo of data transfers) Lots of reasonably priced VPS providers out there. And once you have set up redundancy in your own design it doesn't matter much how redundant they are. More important will be how spam/pollution free the network neighbourhood is. Amazon would not be the best choice in that regard. I have had good luck with small local VPS providers, often ISPs. Greetings, Jeroen -- Earthquake Magnitude: 3.2 Date: Thursday, March 1, 2012 16:31:08 UTC Location: Central California Latitude: 36.6378; Longitude: -121.2510 Depth: 5.50 km From owen at delong.com Thu Mar 1 19:02:30 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Mar 2012 17:02:30 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <201203011522.q21FM74H095011@aurora.sol.net> Message-ID: <5E50043A-BDB2-4AAB-A7B8-BE71854D7413@delong.com> On Mar 1, 2012, at 2:57 PM, William Herrin wrote: > On Thu, Mar 1, 2012 at 5:37 PM, Owen DeLong wrote: >> You don't have to reinvent what I've done. Neither does every >> or any other application programmer. >> You are welcome to use any of the many connection >> abstraction libraries that are available in open source. >> I suggest you make a trip through google code. > > Which is what everybody basically does. And when it works during the > decidedly non-rigorous testing, they move on to the next problem... > with code that doesn't perform well in the corner cases. Such as when > a host has just been renumbered or one of the host's addresses is > unreachable. > Then push for better written abstraction libraries. There's no need to break the current functionality of the underlying system calls and libc functions which would be needed by any such library anyway. > And because most everybody has made more or less the same errors, the > DNS TTL fails to cause their applications to work as intended and > loses its utility as a tool to facilitate renumbering. > Since I don't write applications for a living, I will admit I haven't rigorously tested any of the libraries out there, but, I'm willing to bet that someone, somewhere has probably written a good one by now. > >> If you want, program in Python where the libraries do >> provide the abstraction you seek. Of course, that >> means you have to cope with Python's other disgusting >> habits like spaces are meaningful and variables are >> indistinguishable from code, but, there's always a tradeoff. > > ::shudder:: I don't *want* to do anything in python. The occasional > reality of a situation dictates that I do some work in python, but I > most definitely don't *want* to. Believe me, I'm in the same boat on that one. However, it is the only language I know of that provides the kind of interface you are demanding. Perhaps this should tell you something about what you are asking for. ;-) Owen From bill at herrin.us Thu Mar 1 19:15:49 2012 From: bill at herrin.us (William Herrin) Date: Thu, 1 Mar 2012 20:15:49 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <5E50043A-BDB2-4AAB-A7B8-BE71854D7413@delong.com> References: <201203011522.q21FM74H095011@aurora.sol.net> <5E50043A-BDB2-4AAB-A7B8-BE71854D7413@delong.com> Message-ID: On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong wrote: > There's no need to > break the current functionality of the underlying system calls and > libc functions which would be needed by any such library anyway. Owen, Point to one sentence written by anybody in this entire thread in which breaking current functionality was proposed. >> And because most everybody has made more or less the same errors, the >> DNS TTL fails to cause their applications to work as intended and >> loses its utility as a tool to facilitate renumbering. > > Since I don't write applications for a ?living, I will admit I haven't rigorously > tested any of the libraries out there, but, I'm willing to bet that someone, > somewhere has probably written a good one by now. Yeah, and if you give me a few weeks I can probably find it amidst all the others which aren't so hot. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Thu Mar 1 19:47:52 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Mar 2012 17:47:52 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <201203011522.q21FM74H095011@aurora.sol.net> <5E50043A-BDB2-4AAB-A7B8-BE71854D7413@delong.com> Message-ID: On Mar 1, 2012, at 5:15 PM, William Herrin wrote: > On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong wrote: >> There's no need to >> break the current functionality of the underlying system calls and >> libc functions which would be needed by any such library anyway. > > Owen, > > Point to one sentence written by anybody in this entire thread in > which breaking current functionality was proposed. > When you said that: connect(char *name, uint16_t port) should work That can't work without breaking the existing functionality of the connect() system call. > >>> And because most everybody has made more or less the same errors, the >>> DNS TTL fails to cause their applications to work as intended and >>> loses its utility as a tool to facilitate renumbering. >> >> Since I don't write applications for a living, I will admit I haven't rigorously >> tested any of the libraries out there, but, I'm willing to bet that someone, >> somewhere has probably written a good one by now. > > Yeah, and if you give me a few weeks I can probably find it amidst all > the others which aren't so hot. > I doubt it would take weeks, but, in any case, it's probably faster than writing and debugging your own. Owen From matt.addison at lists.evilgeni.us Thu Mar 1 20:12:20 2012 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Thu, 1 Mar 2012 21:12:20 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <201203011522.q21FM74H095011@aurora.sol.net> Message-ID: <596196444196086313@unknownmsgid> On Mar 1, 2012, at 17:10, William Herrin wrote: > If took you 50 lines of code to do > 'socket=connect("www.google.com",80,TCP);' and you still managed to > produce a version which, due to the timeout on dead addresses, is > worthless for any kind of interactive program like a web browser. And > because that code isn't found in a system library, every single > application programmer has to write it all over again. > > I'm a fan of Rube Goldberg machines but that was ridiculous. I'm thinking for this to work it would have to be 2 separate calls: Call 1 being to the resolver (using lwres, system resolver, or whatever you want to use) and returning an array of struct addrinfo- same as gai does currently. If applications need TTL/SRV/$NEWRR awareness it would be implemented here. Call 2 would be a "happy eyeballs" connect syscall (mconnect? In the spirit of sendmmsg) which accepts an array of struct addrinfo and returns an fd. In the case of O_NONBLOCK it would return a dummy fd (as non-blocking connects do currently) then once one of the connections finishes handshake the kernel connects it to the FD and signals writable to trigger select/poll/epoll. This allows developers to keep using the same loops (and most of the APIs) they're already comfortable with, keeps DNS out of the kernel, but hopefully provides a better and easier to use connect() experience, for SOCK_STREAM at least. It's not as neat as a single connect() accepting a name, but seems to be a happy medium and provides a standardized/predictable connect() experience without breaking existing APIs. ~Matt From marka at isc.org Thu Mar 1 21:32:29 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 02 Mar 2012 14:32:29 +1100 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: Your message of "Thu, 01 Mar 2012 21:12:20 CDT." <596196444196086313@unknownmsgid> References: <201203011522.q21FM74H095011@aurora.sol.net> <596196444196086313@unknownmsgid> Message-ID: <20120302033230.A7E4E1E006E1@drugs.dv.isc.org> In message <596196444196086313 at unknownmsgid>, Matt Addison writes: > On Mar 1, 2012, at 17:10, William Herrin wrote: > > If took you 50 lines of code to do > > 'socket=connect("www.google.com",80,TCP);' and you still managed to > > produce a version which, due to the timeout on dead addresses, is > > worthless for any kind of interactive program like a web browser. And > > because that code isn't found in a system library, every single > > application programmer has to write it all over again. > > > > I'm a fan of Rube Goldberg machines but that was ridiculous. > > I'm thinking for this to work it would have to be 2 separate calls: > > Call 1 being to the resolver (using lwres, system resolver, or > whatever you want to use) and returning an array of struct addrinfo- > same as gai does currently. If applications need TTL/SRV/$NEWRR > awareness it would be implemented here. > > Call 2 would be a "happy eyeballs" connect syscall (mconnect? In the > spirit of sendmmsg) which accepts an array of struct addrinfo and > returns an fd. In the case of O_NONBLOCK it would return a dummy fd > (as non-blocking connects do currently) then once one of the > connections finishes handshake the kernel connects it to the FD and > signals writable to trigger select/poll/epoll. This allows developers > to keep using the same loops (and most of the APIs) they're already > comfortable with, keeps DNS out of the kernel, but hopefully provides > a better and easier to use connect() experience, for SOCK_STREAM at > least. > > It's not as neat as a single connect() accepting a name, but seems to > be a happy medium and provides a standardized/predictable connect() > experience without breaking existing APIs. > > ~Matt And you can do the same in userland with kqueue and similar. int connectxx(struct addrinfo *res0, int *fd, int *timeout, void**state); 0 *fd is a connected socket. EINPROGRESS Wait on '*fd' with a timeout of 'timeout' nanoseconds. ETIMEDOUT connect failed. If timeout or state is NULL you block. You re-call with res0 set to NULL. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bill at herrin.us Thu Mar 1 23:34:16 2012 From: bill at herrin.us (William Herrin) Date: Fri, 2 Mar 2012 00:34:16 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <201203011522.q21FM74H095011@aurora.sol.net> <5E50043A-BDB2-4AAB-A7B8-BE71854D7413@delong.com> Message-ID: On Thu, Mar 1, 2012 at 8:47 PM, Owen DeLong wrote: > On Mar 1, 2012, at 5:15 PM, William Herrin wrote: >> On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong wrote: >>> There's no need to >>> break the current functionality of the underlying system calls and >>> libc functions which would be needed by any such library anyway. >> >> Owen, >> >> Point to one sentence written by anybody in this entire thread in >> which breaking current functionality was proposed. >> > When you said that: > > connect(char *name, uint16_t port) should work > > That can't work without breaking the existing functionality of the connect() system call. You know, when I wrote 'socket=connect("www.google.com",80,TCP);' I stopped and thought to myself, "I wonder if I should change that to 'connectbyname' instead just to make it clear that I'm not replacing the existing connect() call?" But then I thought, "No, there's a thousand ways someone determined to misunderstand what I'm saying will find to misunderstand it. To someone who wants to understand my point, this is crystal clear." -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Fri Mar 2 00:03:19 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 1 Mar 2012 22:03:19 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <201203011522.q21FM74H095011@aurora.sol.net> <5E50043A-BDB2-4AAB-A7B8-BE71854D7413@delong.com> Message-ID: <601710D0-047D-431B-BFA7-2E34EB75F332@delong.com> On Mar 1, 2012, at 9:34 PM, William Herrin wrote: > On Thu, Mar 1, 2012 at 8:47 PM, Owen DeLong wrote: >> On Mar 1, 2012, at 5:15 PM, William Herrin wrote: >>> On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong wrote: >>>> There's no need to >>>> break the current functionality of the underlying system calls and >>>> libc functions which would be needed by any such library anyway. >>> >>> Owen, >>> >>> Point to one sentence written by anybody in this entire thread in >>> which breaking current functionality was proposed. >>> >> When you said that: >> >> connect(char *name, uint16_t port) should work >> >> That can't work without breaking the existing functionality of the connect() system call. > > You know, when I wrote 'socket=connect("www.google.com",80,TCP);' I > stopped and thought to myself, "I wonder if I should change that to > 'connectbyname' instead just to make it clear that I'm not replacing > the existing connect() call?" But then I thought, "No, there's a > thousand ways someone determined to misunderstand what I'm saying will > find to misunderstand it. To someone who wants to understand my point, > this is crystal clear." I'm all for additional library functionality built on top of what exists that does what you want. As I said, there are many such libraries out there to do that. If someone wants to add it to libc, more power to them. I'm not the libc maintainer. I just don't want conect() to stop working the way it does or for getaddrinfo() to stop working the way it does. Since you were hell bent on calling the existing mechanisms broken rather than conceding the point that the current process is not broken, but, could stand some improvements in the library (http://owend.corp.he.net/ipv6 I even say as much myself), it was not entirely clear that you did not intend to replace connect() rather than augment the current capabilities with additional more abstract functions with different names. Owen From gtheo at iti.gr Fri Mar 2 01:24:45 2012 From: gtheo at iti.gr (Georgios Theodoridis) Date: Fri, 02 Mar 2012 09:24:45 +0200 Subject: BBC reports Kenya fiber break In-Reply-To: References: <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx> <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com> <20120229135328.GF24032@netmeister.org> <4F4F3D3B.4090404@iti.gr> Message-ID: <4F5075BD.7040809@iti.gr> I would like to deeply thank you all for your prompt response as well as for your generous contribution and the most interesting information that you shared. Of course any further insight is still more than welcome. Best regards, George On 03/02/2012 01:22 AM, Jim Cowie wrote: > > > On Thu, Mar 1, 2012 at 4:11 AM, Georgios Theodoridis > wrote: > > Has it been known the exact time of the incident? > I have found an article reporting that the cut occurred in the > mid-day of Saturday 25th but nothing more precise. > We would like to use such information for a BGP anomaly detection > analysis that we are carrying out in our research centre. > > Thanks in advance, > > George > > > > Renesys published a brief writeup of the incident yesterday. We > called it at 09:13 UTC on the 25th. Lots of interesting outage and > transit-shift effects to see in the East African BGP data that day. > We also report some shifts in latency based on active measurement, as > everyone's traffic jumps onto the surviving connectivity through > SEACOM. Kenya Data Networks (AS33770) did a particularly good job > staying alive by virtue of their upstream provider diversity, kudos to > them. > > http://www.renesys.com/blog/2012/02/east-african-cable-breaks.shtml > > best, --jim From bicknell at ufp.org Fri Mar 2 08:51:57 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 2 Mar 2012 06:51:57 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <5E50043A-BDB2-4AAB-A7B8-BE71854D7413@delong.com> References: <201203011522.q21FM74H095011@aurora.sol.net> <5E50043A-BDB2-4AAB-A7B8-BE71854D7413@delong.com> Message-ID: <20120302145157.GA73095@ussenterprise.ufp.org> In a message written on Thu, Mar 01, 2012 at 05:02:30PM -0800, Owen DeLong wrote: > Then push for better written abstraction libraries. There's no need to > break the current functionality of the underlying system calls and > libc functions which would be needed by any such library anyway. Agree in part and disagree in part. I think where the Open Source community has fallen behind in the last decade is application level libraries. Open source pioneered cross platform libraries (libX11, libresolv, libm) in the early days and the benefit was they worked darn near exactly the same on all platforms. It made programming and porting easier and lead to growth in the ecosystem. Today that mantle has been taken up by Apple and Microsoft. In Objective-C for example I can in one line of code say "retrieve this URL", and the libraries know about DNS, IPv4 vrs IPv6, happy eyeballs algorythms, multi-threading parts so that the user doesn't wait, and so on. Typical application programs on these platforms never make any of the system calls that have been discussed in this thread. Unfortunately the open source world is without even basic enhancements. Library work in many areas has stagnated, and in the areas where it is progressing it's often done in a way to make the same library (by name) perform differently on different operating systems! Plenty of people have done research finding rampent file copying and duplication of code, and that's a bad sign: http://tagide.com/blog/2011/09/file-cloning-in-open-source-the-good-the-bad-and-the-ugly/ http://www.solidsourceit.com/blog/?p=4 http://pages.cs.wisc.edu/~shanlu/paper/TSE-CPMiner.pdf I can't find it now but there was a paper a few years back that looked for a hash or CRC algorythm because they were easy to identify in source by the fixed, unique constant they used. In the Linux kernel alone was like 10 implementations, widen to all software in the application repository and there were like 10,000 instances of (nearly) the same code! Now, where I disagree. Better libraries means not just better ones at a high level (fetch me this URL), but better ones at a lower level. For instance libresolv discussed here is old and creaky. It was designed for a different time. Many folks doing DNS work have moved on to libldns from Unbound because libresolv does not do what they need with respect to DNSSEC or IPv4/IPv6 issues. I think the entire community needs to come together with a strong bit of emphasis on libraries, standardizing them, making them ship with the base OS so programmers can count on them, and rolling in new stuff that needs to be in them on a timely basis. Apple and Microsoft do it with their (mostly closed) platforms, open source can do it better. -- 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 carlosm3011 at gmail.com Fri Mar 2 09:39:19 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Fri, 02 Mar 2012 13:39:19 -0200 Subject: Programmers with network engineering skills In-Reply-To: <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> Message-ID: <4F50E9A7.8050708@gmail.com> I'm definitely in that camp as well :-) In my experience the path of least resistance is to get a junior network engineer and mentor he/she into improving his/hers programming skills than go the other way around. s2 C. On 2/27/12 6:22 PM, Owen DeLong wrote: > I think you're more likely to find a network engineer with (possibly limited) > programming skills. > > That's certainly where I would categorize myself. > > Owen > > On Feb 27, 2012, at 12:02 PM, Brandt, Ralph wrote: > >> Generalists are hard to come by these days. They are people who learn >> less and less about more and more till they know nothing about >> everything. People today are specializing in the left and right halves >> of the bytes.... They learn more and more about less and less till they >> know everything about nothing. And BTW, they are worthless unless you >> have five of them working on a problem because none of them know enough >> to fix it. Worse, you can replace the word five with fifty and it may >> be still true. >> >> I know of three of these, all gainfully employed at this time and could >> each find at least a couple jobs if they wanted. I am one, my son is >> two and a guy we worked with is the third. >> >> At one time (40 years ago) the mantra in IS was train for expertise, now >> it is hire for it. Somewhere there has to be a happy medium. I suggest >> this, find a good coder, not a mediocre who writes shit code but a good >> one who can think and learn and when you talk about branching out with >> his skill set he or she lights up. His first thing on site is take the >> A+ networking course. >> >> No, I do not sell the courses. But I have seen this kind of approach >> work when nothing else was. >> >> >> >> >> Ralph Brandt >> Communications Engineer >> HP Enterprise Services >> Telephone +1 717.506.0802 >> FAX +1 717.506.4358 >> Email Ralph.Brandt at pateam.com >> 5095 Ritter Rd >> Mechanicsburg PA 17055 >> >> -----Original Message----- >> From: A. Pishdadi [mailto:apishdadi at gmail.com] >> Sent: Sunday, February 26, 2012 8:27 PM >> To: NANOG >> Subject: Programmers with network engineering skills >> >> Hello All, >> >> i have been looking for quite some time now a descent coder (c,php) who >> has >> a descent amount of system admin / netadmin experience. Doesn't >> necessarily >> need to be an expert at network engineering but being acclimated in >> understanding the basic fundamentals of networking. Understanding basic >> routing concepts, how to diagnose using tcpdump / pcap, understanding >> subnetting and how bgp works (not necessarily setting up bgp). I've >> posted >> job listings on the likes of dice and monster and have not found any >> good >> canidates, most of them ASP / Java guys. >> >> If anyone can point me to a site they might recommend for job postings >> or >> know of any consulting firms that might provide these services that >> would >> be greatly appreciated. > From brunner at nic-naa.net Fri Mar 2 11:13:25 2012 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 02 Mar 2012 12:13:25 -0500 Subject: Programmers with network engineering skills In-Reply-To: <4F50E9A7.8050708@gmail.com> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> Message-ID: <4F50FFB5.9030609@nic-naa.net> > In my experience the path of least resistance is to get a junior network > engineer and ... agree, where the end goal is to increment the facility's scripting capable administrators. been there, done that. disagree, where the end goal is to create a coherent distributed system with a non-trivial lifecycle, release schedule, documentation, i18n/l10n capabilities and deliverables, resembling an operating system product. been there, done that. where i'm looking at gray is platforms built atop of platforms. for mpi, pvm and similar (b) is the better choice. for grid computing, i suspect (a) may answer. -e From bill at herrin.us Fri Mar 2 12:12:56 2012 From: bill at herrin.us (William Herrin) Date: Fri, 2 Mar 2012 13:12:56 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <601710D0-047D-431B-BFA7-2E34EB75F332@delong.com> References: <201203011522.q21FM74H095011@aurora.sol.net> <5E50043A-BDB2-4AAB-A7B8-BE71854D7413@delong.com> <601710D0-047D-431B-BFA7-2E34EB75F332@delong.com> Message-ID: On Fri, Mar 2, 2012 at 1:03 AM, Owen DeLong wrote: > On Mar 1, 2012, at 9:34 PM, William Herrin wrote: >> You know, when I wrote 'socket=connect("www.google.com",80,TCP);' I >> stopped and thought to myself, "I wonder if I should change that to >> 'connectbyname' instead just to make it clear that I'm not replacing >> the existing connect() call?" But then I thought, "No, there's a >> thousand ways someone determined to misunderstand what I'm saying will >> find to misunderstand it. To someone who wants to understand my point, >> this is crystal clear." "Hyperbole." If I had remembered the word, I could have skipped the long description. > I'm all for additional library functionality > I just don't want conect() to stop working the way it does or for getaddrinfo() to stop > working the way it does. Good. Let's move on. First question: who actually maintains the standard for the C sockets API these days? Is it a POSIX standard? Next, we have a set of APIs which, with sufficient caution and skill (which is rarely the case) it's possible to string together a reasonable process which starts with a some kind of name in a text string and ends with established communication with a remote server for any sort of name and any sort of protocol. These APIs are complete but we repeatedly see certain kinds of error committed while using them. Is there a common set of activities an application programmer intends to perform 9 times out of 10 when using getaddrinfo+connect? I think there is, and it has the following functionality: Create a [stream].to one of the hosts satisfying [name] + [service] within [timeout] and return a [socket]. Does anybody disagree? Here's my reasoning: Better than 9 times out of 10 a steam and usually a TCP stream at that. Connect also designates a receiver for a connectionless protocol like UDP, but its use for that has always been a little peculiar since the protocol doesn't actually connect. And indeed, sendto() can designate a different receiver for each packet sent through the socket. Name + Service. If TCP, a hostname and a port. Sometimes you want to start multiple connection attempts in parallel or have some not-quire-threaded process implement its own scheduler for dealing with multiple connections at once, but that's the exception. Usually the only reason for dealing with the connect() in non-blocking mode is that you want to implement sensible error recover with timeouts. And the timeout - the direction that control should be returned to the caller no later than X. If it would take more than X to complete, then fail instead. Next item: how would this work under the hood? Well, you have two tasks: find a list of candidate endpoints from the name, and establish a connection to one of them. Find the candidates: ask all available name services in parallel (hosts, NIS, DNS, etc). Finished when: 1. All services have responded negative (failure) 2. You have a positive answer and all services which have not yet answered are at a lower priority (e.g. hosts answers, so you don't need to wait for NIS and DNS). 3. You have a positive answer from at least one name service and 1/2 of the requested time out has expired. 4. The full time out has expired (failure). Cache the knowledge somewhere along with TTLs (locally defined if the name service doesn't explicitly provide a TTL). This may well be the first of a series of connection requests for the same host. If cached and TTL valid knowledge was known for this name for a particular service, don't ask that service again. Also need to let the app tell us to deprioritize a particular result later on. Why? Let's say I get an HTTP connection to a host but then that connection times out. If the app is managing the address list, it can try again to another address for the same name. We're now hiding that detail from the app, so we need a callback for the app to tell us, "when I try again, avoid giving me this answer because it didn't turn out to work." So, now we have a list of addresses with valid TTLs as of the start of our connection attempt. Next step: start the connection attempt. Pick the "first" address (chosen by whatever the ordering rules are) and send the connection request packet and let the OS do its normal retry schedule. Wait one second (system or sysctl configurable) or until the previous connection request was either accepted or rejected, whichever is shorter. If not connected yet, background it, pick the next address and send a connection request. Repeat until a one connection request has been issued to all possible destination addresses for the name. Finished when: 1. Any of the pending connection requests completes (others are aborted). 2. The time out is reached (all pending request aborted). Once a connection is established, this should be cached alongside the address and its TTL so that next time around that address can be tried first. Thoughts? The idea here, of course, is that any application which uses this function to make its connections should, at an operations level, do a good job handling both multiple addresses with one of them unreachable as well as host renumbering that relies on the DNS TTL. > Since you were hell bent on calling the existing mechanisms broken rather than > conceding the point that the current process is not broken, but, could stand some > improvements in the library I hold that if an architecture encourages a certain implementation mistake largely to the exclusion of correct implementations then that architecture is in some way broken. That error may be in a particular component, but it could be that the components themselves are correct. There could be in a missing component or the components could strung together in a way that doesn't work right. Regardless of the exact cause, there is an architecture level mistake which is the root cause of the consistently broken implementations. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cscora at apnic.net Fri Mar 2 12:56:35 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Mar 2012 04:56:35 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201203021856.q22IuZBH013466@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 03 Mar, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 398919 Prefixes after maximum aggregation: 170354 Deaggregation factor: 2.34 Unique aggregates announced to Internet: 193894 Total ASes present in the Internet Routing Table: 40219 Prefixes per ASN: 9.92 Origin-only ASes present in the Internet Routing Table: 32806 Origin ASes announcing only one prefix: 15513 Transit ASes present in the Internet Routing Table: 5413 Transit-only ASes present in the Internet Routing Table: 143 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 339 Unregistered ASNs in the Routing Table: 146 Number of 32-bit ASNs allocated by the RIRs: 2307 Number of 32-bit ASNs visible in the Routing Table: 2000 Prefixes from 32-bit ASNs in the Routing Table: 4712 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 424 Number of addresses announced to Internet: 2523361040 Equivalent to 150 /8s, 103 /16s and 111 /24s Percentage of available address space announced: 68.1 Percentage of allocated address space announced: 68.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 92.0 Total number of prefixes smaller than registry allocations: 169546 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 98087 Total APNIC prefixes after maximum aggregation: 31882 APNIC Deaggregation factor: 3.08 Prefixes being announced from the APNIC address blocks: 94440 Unique aggregates announced from the APNIC address blocks: 39376 APNIC Region origin ASes present in the Internet Routing Table: 4666 APNIC Prefixes per ASN: 20.24 APNIC Region origin ASes announcing only one prefix: 1237 APNIC Region transit ASes present in the Internet Routing Table: 742 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 157 Number of APNIC addresses announced to Internet: 641101792 Equivalent to 38 /8s, 54 /16s and 111 /24s Percentage of available APNIC address space announced: 81.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 148580 Total ARIN prefixes after maximum aggregation: 75492 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 120266 Unique aggregates announced from the ARIN address blocks: 49674 ARIN Region origin ASes present in the Internet Routing Table: 14926 ARIN Prefixes per ASN: 8.06 ARIN Region origin ASes announcing only one prefix: 5685 ARIN Region transit ASes present in the Internet Routing Table: 1571 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 15 Number of ARIN addresses announced to Internet: 805413120 Equivalent to 48 /8s, 1 /16s and 161 /24s Percentage of available ARIN address space announced: 64.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 99868 Total RIPE prefixes after maximum aggregation: 52724 RIPE Deaggregation factor: 1.89 Prefixes being announced from the RIPE address blocks: 91478 Unique aggregates announced from the RIPE address blocks: 56727 RIPE Region origin ASes present in the Internet Routing Table: 16343 RIPE Prefixes per ASN: 5.60 RIPE Region origin ASes announcing only one prefix: 7994 RIPE Region transit ASes present in the Internet Routing Table: 2621 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1391 Number of RIPE addresses announced to Internet: 501247240 Equivalent to 29 /8s, 224 /16s and 109 /24s Percentage of available RIPE address space announced: 80.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 38718 Total LACNIC prefixes after maximum aggregation: 8058 LACNIC Deaggregation factor: 4.80 Prefixes being announced from the LACNIC address blocks: 38269 Unique aggregates announced from the LACNIC address blocks: 19523 LACNIC Region origin ASes present in the Internet Routing Table: 1553 LACNIC Prefixes per ASN: 24.64 LACNIC Region origin ASes announcing only one prefix: 428 LACNIC Region transit ASes present in the Internet Routing Table: 276 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 434 Number of LACNIC addresses announced to Internet: 97556872 Equivalent to 5 /8s, 208 /16s and 153 /24s Percentage of available LACNIC address space announced: 64.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8763 Total AfriNIC prefixes after maximum aggregation: 2091 AfriNIC Deaggregation factor: 4.19 Prefixes being announced from the AfriNIC address blocks: 6769 Unique aggregates announced from the AfriNIC address blocks: 2141 AfriNIC Region origin ASes present in the Internet Routing Table: 518 AfriNIC Prefixes per ASN: 13.07 AfriNIC Region origin ASes announcing only one prefix: 169 AfriNIC Region transit ASes present in the Internet Routing Table: 121 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 3 Number of AfriNIC addresses announced to Internet: 31557120 Equivalent to 1 /8s, 225 /16s and 134 /24s Percentage of available AfriNIC address space announced: 47.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2486 11107 988 Korea Telecom (KIX) 17974 1732 503 37 PT TELEKOMUNIKASI INDONESIA 7545 1645 303 85 TPG Internet Pty Ltd 4755 1559 385 157 TATA Communications formerly 9829 1182 997 29 BSNL National Internet Backbo 7552 1154 1062 11 Vietel Corporation 4808 1146 2101 316 CNCGROUP IP network: China169 9583 1131 83 481 Sify Limited 24560 1012 385 167 Bharti Airtel Ltd., Telemedia 18101 949 130 155 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3432 3807 199 bellsouth.net, inc. 7029 3418 1014 159 Windstream Communications Inc 18566 2090 382 177 Covad Communications 1785 1874 680 127 PaeTec Communications, Inc. 20115 1631 1550 632 Charter Communications 4323 1611 1059 384 Time Warner Telecom 22773 1538 2910 110 Cox Communications, Inc. 30036 1408 254 742 Mediacom Communications Corp 19262 1389 4703 398 Verizon Global Networks 7018 1284 6962 842 AT&T WorldNet Services Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1860 544 16 Corbina telecom 2118 1421 97 13 EUnet/RELCOM Autonomous Syste 15557 1088 2184 60 LDCOM NETWORKS 34984 657 188 171 BILISIM TELEKOM 6830 642 1927 413 UPC Distribution Services 20940 633 203 482 Akamai Technologies European 12479 610 644 55 Uni2 Autonomous System 8551 599 360 81 Bezeq International 31148 540 37 9 FreeNet ISP 3320 532 8442 398 Deutsche Telekom AG Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1758 325 169 TVCABLE BOGOTA 28573 1672 1089 60 NET Servicos de Comunicao S.A 8151 1486 3013 346 UniNet S.A. de C.V. 7303 1328 822 186 Telecom Argentina Stet-France 26615 881 664 33 Tim Brasil S.A. 27947 667 68 107 Telconet S.A 11172 634 91 72 Servicios Alestra S.A de C.V 22047 581 322 17 VTR PUNTO NET S.A. 6503 573 418 66 AVANTEL, S.A. 3816 561 240 89 Empresa Nacional de Telecomun Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1249 958 13 TEDATA 24863 834 274 37 LINKdotNET AS number 6713 490 649 18 Itissalat Al-MAGHRIB 3741 277 923 228 The Internet Solution 15706 227 32 6 Sudatel Internet Exchange Aut 29571 211 16 10 Ci Telecom Autonomous system 12258 197 28 62 Vodacom Internet Company 24835 194 80 8 RAYA Telecom - Egypt 33776 169 12 16 Starcomms Nigeria Limited 36923 157 20 4 Swift Networks Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3432 3807 199 bellsouth.net, inc. 7029 3418 1014 159 Windstream Communications Inc 4766 2486 11107 988 Korea Telecom (KIX) 18566 2090 382 177 Covad Communications 1785 1874 680 127 PaeTec Communications, Inc. 8402 1860 544 16 Corbina telecom 10620 1758 325 169 TVCABLE BOGOTA 17974 1732 503 37 PT TELEKOMUNIKASI INDONESIA 28573 1672 1089 60 NET Servicos de Comunicao S.A 7545 1645 303 85 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3418 3259 Windstream Communications Inc 18566 2090 1913 Covad Communications 8402 1860 1844 Corbina telecom 1785 1874 1747 PaeTec Communications, Inc. 17974 1732 1695 PT TELEKOMUNIKASI INDONESIA 28573 1672 1612 NET Servicos de Comunicao S.A 10620 1758 1589 TVCABLE BOGOTA 7545 1645 1560 TPG Internet Pty Ltd 4766 2486 1498 Korea Telecom (KIX) 22773 1538 1428 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 23.27.0.0/20 18779 Guru.com 23.27.0.0/16 18779 Guru.com Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:28 /11:81 /12:233 /13:458 /14:817 /15:1474 /16:12170 /17:6223 /18:10408 /19:20448 /20:28449 /21:29230 /22:39750 /23:37074 /24:208355 /25:1204 /26:1441 /27:784 /28:170 /29:58 /30:14 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 3073 3418 Windstream Communications Inc 6389 2106 3432 bellsouth.net, inc. 18566 2039 2090 Covad Communications 8402 1838 1860 Corbina telecom 10620 1655 1758 TVCABLE BOGOTA 30036 1358 1408 Mediacom Communications Corp 11492 1124 1161 Cable One 1785 1064 1874 PaeTec Communications, Inc. 8452 1059 1249 TEDATA 7011 1040 1156 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:522 2:783 4:14 6:3 8:390 12:1964 13:1 14:605 15:11 16:3 17:7 20:8 23:135 24:1738 27:1204 31:986 32:65 33:2 34:2 36:9 37:217 38:779 40:116 41:2938 42:120 44:3 46:1382 47:3 49:334 50:510 52:13 54:5 55:9 56:3 57:38 58:967 59:497 60:287 61:1197 62:976 63:2009 64:4116 65:2283 66:4468 67:2035 68:1165 69:3154 70:909 71:409 72:1789 74:2646 75:470 76:319 77:975 78:968 79:492 80:1211 81:885 82:625 83:540 84:586 85:1160 86:723 87:913 88:334 89:1563 90:284 91:4531 92:515 93:1401 94:1374 95:1120 96:421 97:315 98:819 99:38 100:5 101:153 103:856 106:64 107:166 108:179 109:1529 110:723 111:867 112:435 113:528 114:606 115:792 116:869 117:710 118:905 119:1261 120:362 121:727 122:1620 123:1079 124:1340 125:1323 128:536 129:190 130:262 131:591 132:165 133:21 134:234 135:62 136:212 137:184 138:268 139:145 140:493 141:265 142:392 143:406 144:513 145:69 146:484 147:251 148:724 149:300 150:158 151:198 152:448 153:171 154:7 155:382 156:212 157:370 158:162 159:518 160:322 161:245 162:343 163:187 164:530 165:395 166:560 167:458 168:810 169:148 170:839 171:119 172:4 173:1706 174:597 175:420 176:529 177:483 178:1281 180:1193 181:68 182:746 183:284 184:437 185:1 186:2015 187:830 188:1058 189:1173 190:5469 192:5988 193:5572 194:4354 195:3404 196:1295 197:167 198:3631 199:4425 200:5722 201:1757 202:8385 203:8662 204:4359 205:2446 206:2745 207:2796 208:4059 209:3560 210:2758 211:1476 212:1986 213:1867 214:836 215:102 216:5022 217:1509 218:549 219:334 220:1231 221:564 222:322 223:319 End of report From jared at puck.nether.net Fri Mar 2 13:32:03 2012 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 2 Mar 2012 14:32:03 -0500 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: <4F4F8F3C.9090706@mtcc.com> References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com> <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net> <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net> <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com> <6252359949770844391@unknownmsgid> <34F84CED-8C8C-4EE3-A0FF-6001F4E3D7A2@delong.com> <4F4F8F3C.9090706@mtcc.com> Message-ID: <6CB9954E-1D50-4EF0-A8B3-92FD5ABA8F75@puck.nether.net> On Mar 1, 2012, at 10:01 AM, Michael Thomas wrote: > The real issue is that gethostbyxxx has been inadequate for a very > long time. Moving it across the kernel boundary solves nothing and > most likely causes even more trouble: what if I want, say, asynchronous > name resolution? What if I want to use SRV records? What if a new DNS > RR comes around -- do i have do recompile the kernel? It's for these > reasons and probably a whole lot more that connect just confuses the > actual issues. My experience is that these calls are expensive and require a lot of work to get a true result. Some systems also have interim caching that happens as well (e.g. NSCD). When building software that did a lot of dns lookups at once, I had to build my own internal cache to maintain performance. Startup costs were expensive, but maintaining it started to space out a bit more and be less of an issue. I ended up caching these entries for 1 hour by default. - jared From nallgood at telesphere.com Fri Mar 2 13:48:03 2012 From: nallgood at telesphere.com (Nick Allgood) Date: Fri, 2 Mar 2012 11:48:03 -0800 Subject: AT&T DSL contact off-list Message-ID: Hi there, Can someone from AT&T who has any ties to their DSL support contact me off-list? I've been trying to call them all morning but I'm either hung up on or I get forwarded to a voice mailbox that's full. Thanks! From blake at ispn.net Fri Mar 2 13:49:46 2012 From: blake at ispn.net (Blake Hudson) Date: Fri, 02 Mar 2012 13:49:46 -0600 Subject: Riverbed/Akamai/Rakamai [OT?] In-Reply-To: References: Message-ID: <4F51245A.5090203@ispn.net> /I think all the good stuff is in here - http://www.youtube.com/watch?v=d8G3K3hEE6U&feature=related --Blake / Michael Still wrote the following on 3/1/2012 10:34 AM: > Found this in one of my RSS feeds this am: > http://www.youtube.com/watch?v=GNOXSmMfcGs > > Sort of explains it. > > On Thu, Mar 1, 2012 at 10:09 AM, Kristian Kielhofner wrote: >> As long as we're talking about cloud networks, Akamai and Riverbed >> have finally let out details on their partnership for "optimizing" >> Cloud applications: >> >> http://www.nojitter.com/post/232601716/rakamai-makes-the-cloud-work-better >> >> While I'm familiar with Akamai (what they do and how they do it) I >> don't have any experience with Riverbed. >> >> Does anyone know what they actually "do" and how they do it? As usual >> it's tough to cut through the marketing on the little detail they make >> available (never a good sign). >> >> -- >> Kristian Kielhofner >> > > From owen at delong.com Fri Mar 2 14:59:46 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Mar 2012 12:59:46 -0800 Subject: dns and software, was Re: Reliable Cloud host ? In-Reply-To: References: <201203011522.q21FM74H095011@aurora.sol.net> <5E50043A-BDB2-4AAB-A7B8-BE71854D7413@delong.com> <601710D0-047D-431B-BFA7-2E34EB75F332@delong.com> Message-ID: <43F86092-707D-4D67-A819-1C9FB19D67B2@delong.com> On Mar 2, 2012, at 10:12 AM, William Herrin wrote: > On Fri, Mar 2, 2012 at 1:03 AM, Owen DeLong wrote: >> On Mar 1, 2012, at 9:34 PM, William Herrin wrote: >>> You know, when I wrote 'socket=connect("www.google.com",80,TCP);' I >>> stopped and thought to myself, "I wonder if I should change that to >>> 'connectbyname' instead just to make it clear that I'm not replacing >>> the existing connect() call?" But then I thought, "No, there's a >>> thousand ways someone determined to misunderstand what I'm saying will >>> find to misunderstand it. To someone who wants to understand my point, >>> this is crystal clear." > > "Hyperbole." If I had remembered the word, I could have skipped the > long description. > >> I'm all for additional library functionality >> I just don't want conect() to stop working the way it does or for getaddrinfo() to stop >> working the way it does. > > Good. Let's move on. > > > First question: who actually maintains the standard for the C sockets > API these days? Is it a POSIX standard? > Well, some of it seems to be documented in RFCs, but, I think what you're wanting doesn't require adds to the sockets library, per se. In fact, I think wanting to make it part of that is a mistake. As I said, this should be a higher level library. For example, in Perl, you have Socket (and Socket6), but, you also have several other abstraction libraries such as Net::HTTP. While there's no hierarchical naming scheme for the functions in libc, if you look at the source for any of the open source libc libraries out there, you'll find definite hierarchy. POSIX certainly controls one standard. The GNU libc maintainers control the standard for the libc that accompanies GCC to the best of my knowledge. I would suggest that is probably the best place to start since I think anything that gains acceptance there will probably filter to the others fairly quickly. > Next, we have a set of APIs which, with sufficient caution and skill > (which is rarely the case) it's possible to string together a > reasonable process which starts with a some kind of name in a text > string and ends with established communication with a remote server > for any sort of name and any sort of protocol. These APIs are complete > but we repeatedly see certain kinds of error committed while using > them. > Right... Since these are user-errors (at the developer level) I wouldn't try to fix them in the APIs. I would, instead, build more developer proof add-on APIs on top of them. > Is there a common set of activities an application programmer intends > to perform 9 times out of 10 when using getaddrinfo+connect? I think > there is, and it has the following functionality: > > Create a [stream].to one of the hosts satisfying [name] + [service] > within [timeout] and return a [socket]. > Seems reasonable, but ignores UDP. If we're going to do this, I think we should target a more complete solution to include a broader range of probabilities than just the most common TCP connect scenario. > Does anybody disagree? Here's my reasoning: > > Better than 9 times out of 10 a steam and usually a TCP stream at > that. Connect also designates a receiver for a connectionless protocol > like UDP, but its use for that has always been a little peculiar since > the protocol doesn't actually connect. And indeed, sendto() can > designate a different receiver for each packet sent through the > socket. > Most applications using UDP that I have seen use sendto()/recvfrom() et. al. Netflow data would suggest that it's less than 9 out of ten times for TCP, but, yes, I would agree it is the most common scenario. > Name + Service. If TCP, a hostname and a port. > That would apply to UDP as well. Just the semantics of what you do once you have the filehandle are different. (and it's not really a stream, per se). > Sometimes you want to start multiple connection attempts in parallel > or have some not-quire-threaded process implement its own scheduler > for dealing with multiple connections at once, but that's the > exception. Usually the only reason for dealing with the connect() in > non-blocking mode is that you want to implement sensible error recover > with timeouts. > Agreed. > And the timeout - the direction that control should be returned to the > caller no later than X. If it would take more than X to complete, then > fail instead. > Actually, this is one thing I would like to see added to connect() and that could be done without breaking the existing API. > > > Next item: how would this work under the hood? > > Well, you have two tasks: find a list of candidate endpoints from the > name, and establish a connection to one of them. > > Find the candidates: ask all available name services in parallel > (hosts, NIS, DNS, etc). Finished when: > > 1. All services have responded negative (failure) > > 2. You have a positive answer and all services which have not yet > answered are at a lower priority (e.g. hosts answers, so you don't > need to wait for NIS and DNS). > > 3. You have a positive answer from at least one name service and 1/2 > of the requested time out has expired. > > 4. The full time out has expired (failure). > I think the existing getaddrinfo() does this pretty well already. I will note that the services you listed only apply to resolving the host name. Don't forget that you might also need to resolve the service to a port number. (An application should be looking up HTTP, not assuming it is 80, for example). Conveniently, getaddrinfo simultaneously handles both of these lookups. > Cache the knowledge somewhere along with TTLs (locally defined if the > name service doesn't explicitly provide a TTL). This may well be the > first of a series of connection requests for the same host. If cached > and TTL valid knowledge was known for this name for a particular > service, don't ask that service again. > I recommend against doing this above the level of getaddrinfo(). Just call getaddrinfo() again each time you need something. If it has cached data, it will return quickly and is cheap. If it doesn't return quickly, it will still work just as quickly as anything else most likely. If getaddrinfo() on a particular system is not well behaved, we should seek to fix that implementation of getaddrinfo(), not write yet another replacement. > Also need to let the app tell us to deprioritize a particular result > later on. Why? Let's say I get an HTTP connection to a host but then > that connection times out. If the app is managing the address list, it > can try again to another address for the same name. We're now hiding > that detail from the app, so we need a callback for the app to tell > us, "when I try again, avoid giving me this answer because it didn't > turn out to work." > I would suggest that instead of making this opaque and then complicating it with these hints when we return, that we return use a mecahism where we return a pointer to a dynamically allocated result (similar to getaddrinfo) and if we get called again with a pointer to that structure, we know to delete the previously connected host from the list we try next time. When the application is done with the struct, it should free it by calling an appropriate free function exported by this new API. > > So, now we have a list of addresses with valid TTLs as of the start of > our connection attempt. Next step: start the connection attempt. > > Pick the "first" address (chosen by whatever the ordering rules are) > and send the connection request packet and let the OS do its normal > retry schedule. Wait one second (system or sysctl configurable) or > until the previous connection request was either accepted or rejected, > whichever is shorter. If not connected yet, background it, pick the > next address and send a connection request. Repeat until a one > connection request has been issued to all possible destination > addresses for the name. > > Finished when: > > 1. Any of the pending connection requests completes (others are aborted). > > 2. The time out is reached (all pending request aborted). > > Once a connection is established, this should be cached alongside the > address and its TTL so that next time around that address can be tried > first. > Seems mostly reasonable. I would consider possibly having some form of inverse exponential backoff on the initial connection attempts. Maybe wait 5 seconds for the first one before trying the second one and waiting 2 seconds, then 1 second if the third one hasn't connected, then bottoming out somewhere around 500ms for the remainder. > > >> Since you were hell bent on calling the existing mechanisms broken rather than >> conceding the point that the current process is not broken, but, could stand some >> improvements in the library > > I hold that if an architecture encourages a certain implementation > mistake largely to the exclusion of correct implementations then that > architecture is in some way broken. That error may be in a particular I don't believe that the architecture encourages the implementation mistake. Rather, I think human behavior and our tendency not to seek proper understanding of the theory of operation of various things prior to implementing things which depend on them is more at fault. I suppose that you can argue that the API should be built to avoid that, but, we'll have to agree to disagree on that point. I think that low-level APIs (and this is a low-level API) have to be able to rely on the engineers that use them making the effort to understand the theory of operation. I believe that the fault here is the lack of a standardized higher-level API in some languages. > component, but it could be that the components themselves are correct. > There could be in a missing component or the components could strung > together in a way that doesn't work right. Regardless of the exact > cause, there is an architecture level mistake which is the root cause > of the consistently broken implementations. > I suppose by your definition this constitutes a missing component. I don't see it that way. I see it as a complete and functional system for a low-level API. There are high-level APIs available. As you have noted, some better than others. A standardized well-written high-level API would, indeed, be useful. However, that does not make the low-level API broken just because it is common for poorly trained users to make improper use of it. It is common for people using hammers to hit their thumbs. This does not mean that hammers are architecturally broken or that they should be re-engineered to have elaborate thumb-protection mechanisms. The fact that you can electrocute yourself by sticking a fork into a toaster while it is operating is likewise, not an indication that toasters are architecturally broken. It is precisely this attitude that has significantly increased the overhead and unnecessary expense of many systems while making product liability lawyers quite wealthy. Owen From davidpeahi at gmail.com Fri Mar 2 15:39:49 2012 From: davidpeahi at gmail.com (david peahi) Date: Fri, 2 Mar 2012 13:39:49 -0800 Subject: Cisco ASR1001 Message-ID: I'm looking for experiences with Cisco ASR1001 as a border router, specifically BGP stability, # full BGP feeds (with 4 GB DRAM), does it perform according to wire speed acl/firewall/deep packet inspection specifications. david From lukasz at bromirski.net Fri Mar 2 15:57:48 2012 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Fri, 02 Mar 2012 22:57:48 +0100 Subject: Cisco ASR1001 In-Reply-To: References: Message-ID: <4F51425C.2010704@bromirski.net> On 2012-03-02 22:39, david peahi wrote: > I'm looking for experiences with Cisco ASR1001 as a border router, > specifically BGP stability, # full BGP feeds (with 4 GB DRAM), does it > perform according to wire speed acl/firewall/deep packet inspection > specifications. Wire speed? You propably misread the data sheet. Look at table 1: http://www.cisco.com/en/US/prod/collateral/routers/ps9343/data_sheet_c78-450070.html The QFP will perform ACLs/DPI very fast, but not at wire speed for commonly used edge ACLs. There will be slight performance hit depending on the lenght of the ACLs and the complexity of the inspection. Also take note half of the theoretical RAM is reserved on start, so you end up running your system with 1GB of usable RAM, other 1GB taken during the start by the IOS-XE. For a lot of BGP peerings you should get at least 8GB to be on the safe side, but the default, cheapest 4GB will work fine with small number of full feeds. Also take note that this is hardware forwarding platform, so FIB size will come into play - not now, but given IPv6 growth, in future. ASR1001 has FIB for 1M of IPv4 *or* 1M of IPv6 prefixes, you'll need to check that from time to time (QFP memory usage that is). -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From cidr-report at potaroo.net Fri Mar 2 16:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Mar 2012 22:00:00 GMT Subject: BGP Update Report Message-ID: <201203022200.q22M00MR043879@wattle.apnic.net> BGP Update Report Interval: 23-Feb-12 -to- 01-Mar-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS24863 93831 2.4% 112.4 -- LINKdotNET-AS 2 - AS8402 68106 1.8% 35.3 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS38750 43096 1.1% 5387.0 -- TDS-AS-ID Telemedia Dinamika Sarana, PT 4 - AS7029 33872 0.9% 9.7 -- WINDSTREAM - Windstream Communications Inc 5 - AS17974 32999 0.9% 16.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 6 - AS9829 32240 0.8% 27.3 -- BSNL-NIB National Internet Backbone 7 - AS12479 31369 0.8% 51.3 -- UNI2-AS France Telecom Espana SA 8 - AS24560 27329 0.7% 26.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 9 - AS10620 26471 0.7% 15.1 -- Telmex Colombia S.A. 10 - AS7552 24573 0.6% 19.2 -- VIETEL-AS-AP Vietel Corporation 11 - AS8151 23607 0.6% 15.7 -- Uninet S.A. de C.V. 12 - AS32528 22763 0.6% 2276.3 -- ABBOTT Abbot Labs 13 - AS5800 20425 0.5% 72.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - AS6389 18897 0.5% 5.5 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 15 - AS28573 17672 0.5% 10.3 -- NET Servicos de Comunicao S.A. 16 - AS9498 17178 0.5% 18.8 -- BBIL-AP BHARTI Airtel Ltd. 17 - AS28683 16016 0.4% 262.6 -- BENINTELECOM 18 - AS8452 15465 0.4% 12.2 -- TE-AS TE-AS 19 - AS4780 15298 0.4% 19.2 -- SEEDNET Digital United Inc. 20 - AS4755 15112 0.4% 9.7 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6066 12622 0.3% 6311.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 2 - AS38750 43096 1.1% 5387.0 -- TDS-AS-ID Telemedia Dinamika Sarana, PT 3 - AS30133 2846 0.1% 2846.0 -- ISC-F-AS - Internet Systems Consortium, Inc. 4 - AS32528 22763 0.6% 2276.3 -- ABBOTT Abbot Labs 5 - AS53360 4180 0.1% 2090.0 -- CUMULUS - Integral Solutions Group 6 - AS53362 956 0.0% 956.0 -- MIXIT-AS - Mixit, Inc. 7 - AS55665 850 0.0% 850.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 8 - AS28666 12023 0.3% 667.9 -- HOSTLOCATION LTDA 9 - AS51976 662 0.0% 662.0 -- JP-TELEKOM-AS JP-Telekom Sp. z o.o. 10 - AS27745 2622 0.1% 437.0 -- Telefonia Bonairiano N.V. 11 - AS3 402 0.0% 1756.0 -- SE-SONYMOBILE SonyEricsson Mobile Communications AB 12 - AS9199 1607 0.0% 401.8 -- RENAM RENAM Association 13 - AS36980 394 0.0% 394.0 -- JOHNHOLT-ASN 14 - AS5313 389 0.0% 389.0 -- DNIC-ASBLK-05120-05376 - DoD Network Information Center 15 - AS31713 2300 0.1% 383.3 -- GWCOMMS-MPLS Gateway Communication 16 - AS56696 7612 0.2% 362.5 -- ASLIQUID-MPLS Liquid Telecommunications Ltd 17 - AS9232 355 0.0% 355.0 -- CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 18 - AS38528 353 0.0% 353.0 -- LANIC-AS-AP Lao National Internet Committee 19 - AS20632 14266 0.4% 331.8 -- PETERSTAR-AS PeterStar 20 - AS56324 321 0.0% 321.0 -- LOGITUS Logitus Sp. z o.o. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 84.204.132.0/24 11453 0.3% AS20632 -- PETERSTAR-AS PeterStar 2 - 130.36.34.0/24 11348 0.2% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.35.0/24 11348 0.2% AS32528 -- ABBOTT Abbot Labs 4 - 202.92.235.0/24 9771 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 5 - 62.36.252.0/22 8395 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 6 - 122.161.0.0/16 7630 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 182.64.0.0/16 7405 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - 217.15.120.0/22 7075 0.2% AS56696 -- ASLIQUID-MPLS Liquid Telecommunications Ltd 9 - 204.29.239.0/24 6312 0.1% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 10 - 150.225.0.0/16 6310 0.1% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 11 - 62.36.249.0/24 6293 0.1% AS12479 -- UNI2-AS France Telecom Espana SA 12 - 205.107.121.0/24 6148 0.1% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - 62.36.241.0/24 5703 0.1% AS12479 -- UNI2-AS France Telecom Espana SA 14 - 62.36.210.0/24 5533 0.1% AS12479 -- UNI2-AS France Telecom Espana SA 15 - 202.179.188.0/24 5387 0.1% AS38750 -- TDS-AS-ID Telemedia Dinamika Sarana, PT 16 - 202.179.191.0/24 5387 0.1% AS38750 -- TDS-AS-ID Telemedia Dinamika Sarana, PT 17 - 202.179.190.0/24 5387 0.1% AS38750 -- TDS-AS-ID Telemedia Dinamika Sarana, PT 18 - 202.179.187.0/24 5387 0.1% AS38750 -- TDS-AS-ID Telemedia Dinamika Sarana, PT 19 - 202.179.186.0/24 5387 0.1% AS38750 -- TDS-AS-ID Telemedia Dinamika Sarana, PT 20 - 202.179.185.0/24 5387 0.1% AS38750 -- TDS-AS-ID Telemedia Dinamika Sarana, PT Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 2 16:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Mar 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201203022200.q22M00xh043874@wattle.apnic.net> This report has been generated at Fri Mar 2 21:12:30 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 24-02-12 400967 232766 25-02-12 401256 232615 26-02-12 400880 232702 27-02-12 401089 232839 28-02-12 401234 233250 29-02-12 401725 232960 01-03-12 401754 233143 02-03-12 401923 232793 AS Summary 40368 Number of ASes in routing system 16903 Number of ASes announcing only one prefix 3459 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 111264288 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'). --- 02Mar12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 402050 232755 169295 42.1% All ASes AS6389 3419 201 3218 94.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3459 1728 1731 50.0% WINDSTREAM - Windstream Communications Inc AS4766 2490 1011 1479 59.4% KIXS-AS-KR Korea Telecom AS22773 1538 119 1419 92.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS2118 1421 14 1407 99.0% RELCOM-AS OOO "NPO Relcom" AS18566 2090 702 1388 66.4% COVAD - Covad Communications Co. AS4323 1612 386 1226 76.1% TWTC - tw telecom holdings, inc. AS28573 1672 458 1214 72.6% NET Servicos de Comunicao S.A. AS4755 1559 397 1162 74.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1880 800 1080 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 1389 399 990 71.3% VZGNI-TRANSIT - Verizon Online LLC AS10620 1758 788 970 55.2% Telmex Colombia S.A. AS7303 1328 398 930 70.0% Telecom Argentina S.A. AS7552 1154 224 930 80.6% VIETEL-AS-AP Vietel Corporation AS8402 1780 877 903 50.7% CORBINA-AS OJSC "Vimpelcom" AS26615 881 33 848 96.3% Tim Celular S.A. AS8151 1486 672 814 54.8% Uninet S.A. de C.V. AS4808 1146 343 803 70.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS18101 950 158 792 83.4% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7545 1648 928 720 43.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS9498 898 212 686 76.4% BBIL-AP BHARTI Airtel Ltd. AS24560 1012 334 678 67.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9394 884 208 676 76.5% CRNET CHINA RAILWAY Internet(CRNET) AS3356 1098 456 642 58.5% LEVEL3 Level 3 Communications AS17974 1732 1100 632 36.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS17676 686 75 611 89.1% GIGAINFRA Softbank BB Corp. AS15557 1088 505 583 53.6% LDCOMNET Societe Francaise du Radiotelephone S.A AS30036 1316 747 569 43.2% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS3549 994 431 563 56.6% GBLX Global Crossing Ltd. AS4780 781 232 549 70.3% SEEDNET Digital United Inc. Total 45149 14936 30213 66.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 37.143.88.0/21 AS8343 DORIS-AS Private joint-stock company (PrJSC) DORIS 37.143.120.0/21 AS174 COGENT Cogent/PSI 37.143.192.0/18 AS43205 BULSATCOM-BG-AS Bulsatcom AD 37.144.0.0/14 AS8402 CORBINA-AS OJSC "Vimpelcom" 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 66.129.0.0/19 AS3901 ARRAKIS - Higher Technology Services 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS14208 74.91.49.0/24 AS14208 74.91.50.0/24 AS14208 74.91.51.0/24 AS14208 74.91.52.0/24 AS14208 74.91.53.0/24 AS14208 74.91.54.0/24 AS14208 74.91.55.0/24 AS14208 74.91.56.0/24 AS14208 74.91.57.0/24 AS14208 74.91.58.0/24 AS14208 74.91.59.0/24 AS14208 74.91.60.0/24 AS14208 74.91.61.0/24 AS14208 74.91.62.0/24 AS14208 74.91.63.0/24 AS14208 91.236.115.0/24 AS57172 GLOBALLAYER Global Layer B.V. 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.86.32.0/20 AS18255 BRISBANE-AP Brisbane City Council 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.133.224.0/19 AS4323 TWTC - tw telecom holdings, inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.222.240.0/22 AS19747 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From randy at psg.com Fri Mar 2 16:35:52 2012 From: randy at psg.com (Randy Bush) Date: Sat, 03 Mar 2012 07:35:52 +0900 Subject: Programmers with network engineering skills In-Reply-To: <4F50E9A7.8050708@gmail.com> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> Message-ID: > In my experience the path of least resistance is to get a junior > network engineer and mentor he/she into improving his/hers programming > skills than go the other way around. and then the organization pays forever to maintain the crap code while the kiddie learned to program. right. brilliant. Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Martin Golding randy From keegan.holley at sungard.com Fri Mar 2 16:45:18 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Fri, 2 Mar 2012 17:45:18 -0500 Subject: Programmers with network engineering skills In-Reply-To: References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> Message-ID: 2012/3/2 Randy Bush > > In my experience the path of least resistance is to get a junior > > network engineer and mentor he/she into improving his/hers programming > > skills than go the other way around. > > and then the organization pays forever to maintain the crap code while > the kiddie learned to program. right. brilliant. > > +1 Although, I've seen the opposite where a brilliant developer writes wonderful code, leaves and you are left with a similarly difficult situation since there are no more programmers in the department and no brilliant developers willing to do programming that requires in depth knowledge of networking. > Always code as if the guy who ends up maintaining your code will be a > violent psychopath who knows where you live. -- Martin Golding > > randy > > > From randy at psg.com Fri Mar 2 16:55:33 2012 From: randy at psg.com (Randy Bush) Date: Sat, 03 Mar 2012 07:55:33 +0900 Subject: Programmers with network engineering skills In-Reply-To: References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> Message-ID: >>> In my experience the path of least resistance is to get a junior >>> network engineer and mentor he/she into improving his/hers programming >>> skills than go the other way around. >> >> and then the organization pays forever to maintain the crap code while >> the kiddie learned to program. right. brilliant. > > +1 Although, I've seen the opposite where a brilliant developer writes > wonderful code, leaves and you are left with a similarly difficult > situation since there are no more programmers in the department and no > brilliant developers willing to do programming that requires in depth > knowledge of networking. that was not a brilliant developer. that was a clever developer. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan and, if the department was not willing to invest in long-term software capability, then they were foolish to enter the game in the first place. go find an open-source solution or buy commercial. and if none fit your needs, and you are not willing to invest in softdev, then you have a problem in your business model. randy From mukom.tamon at gmail.com Sat Mar 3 01:44:38 2012 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Sat, 3 Mar 2012 11:44:38 +0400 Subject: Network Traffic Collection In-Reply-To: References: <4F469E1B.1040100@unfix.org> <4288131ED5E3024C9CD4782CECCAD2C710B04C6D@LMC-MAIL2.exempla.org> Message-ID: Hi Ali On Sat, Feb 25, 2012 at 6:14 PM, Maverick wrote: > Thanks Mukom for the wonderful guide, this is really helpful. I have > few questions about ntop though. > > How can I get access to the log files generated by ntop and do my own > parsing rather than looking for webbased results that are generated. It's been a while i looked under the hood of ntop. Remember that ntop itself usually needs to be 'fed' traffic to analyse. I have never done it myself but if I needed the raw data, I'd mirror a port and capture it with tcpdump into a pcap file (watch disk space!!) the use whatever analysis tool suits my needs to look at it. > Are there any programs available that do parsing of ntops log files. > When I run ntop on pcap I don't get the throughput graphs as rrd > doesn't work on pcap is there any work around for that. Not to my knowledge no. I think there's a switch (-f) for reading data from a pcap file as opposed to a live feed. I have never played with that as well. There are other (possible more feature laden) commercial flow collectors and analysers out there). I also started following trisul earlier on in the project, you might want to check it out. > > Thanks, > Ali > > On Sat, Feb 25, 2012 at 2:27 AM, Mukom Akong T. wrote: >> On Fri, Feb 24, 2012 at 12:20 AM, Matlock, Kenneth L >> wrote: >>> Netflow + netflow collector. >> >> +1 This guide should give you a good start. >> >> http://techowto.files.wordpress.com/2008/09/ntop-guide.pdf >> >> Regards >> >> -- >> Mukom Akong Tamon >> ______________ >> >> "If we can't BREATH, we'll die. Yet, we don't LIVE in order to breath. >> Ditto we SHOULDN'T WORK just to MAKE MONEY. Doing so puts us on a one >> way street to IRRELEVANCE." >> >> >> [In Search of Excellence & Perfection] - http://perfexcellence.org >> [Moments of TechXcellence] - http://techexcellence.net >> [ICT Business Integration] -?http://ibiztech.wordpress.com >> [About Me] - http://about.me/perfexcellence -- Mukom Akong [Tamon] ______________ ?We don't LIVE in order to BREATH. Similarly WORKING in order to make MONEY puts us on a one way street to irrelevance.? [In Search of Excellence & Perfection] - http://perfexcellence.org [Moments of TechXcellence] - http://techexcellence.net [ICT Business Integration] -?http://ibiztech.wordpress.com [About Me] - http://about.me/perfexcellence From tariq198487 at gmail.com Sat Mar 3 01:46:13 2012 From: tariq198487 at gmail.com (Tarig Adam) Date: Fri, 2 Mar 2012 23:46:13 -0800 Subject: which one a Technical Support or Help Desk Message-ID: I am working for a new Small ISP and we are trying to establish a center for receiving technical calls and inquires from customers and the technicians in this center may do some basics troubleshooting. What is the suitable title for this center and what we should call this people who do this job? Technical Support, Helpdesk, or Call Center. does each term has a specific meaning? And is there any standard structure of this center? And what is the relation of this people with other network/software Engineers? Thanks in advance. -- Tarig Adam From mukom.tamon at gmail.com Sat Mar 3 01:48:05 2012 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Sat, 3 Mar 2012 11:48:05 +0400 Subject: IPv6 net tools In-Reply-To: References: Message-ID: As students doing a final project, I'd suggest installing your favourite linux/unix distro, installing these tools on them yourself and learning for yourself which supports IPv6, to what extent. You can later upgrade or produce v6-related documentation pages for those tools as a service to the community (hint: it also will help your reputation in the community as people who share knowledge) On Sun, Feb 26, 2012 at 2:36 AM, Grupo IPv6 wrote: > We are a group of students in telecommunications engineering from Uruguay. > We are studying some network tools for our final project and we would like > to know if someone could tell us which of this tools have IPv6 support: > > ? ? ? ? ? Bprobe > > ? ? ? ? ? Cprobe > > ? ? ? ? ? Pathload > > ? ? ? ? ? Pathrate > > ? ? ? ? ? Pathchar > > ? ? ? ? ? Clink > > ? ? ? ? ? Nettimer > > ? ? ? ? ? Spruce > > ? ? ?Thanks for your help!! > > > Gianina -- Mukom Akong [Tamon] ______________ ?We don't LIVE in order to BREATH. Similarly WORKING in order to make MONEY puts us on a one way street to irrelevance.? [In Search of Excellence & Perfection] - http://perfexcellence.org [Moments of TechXcellence] - http://techexcellence.net [ICT Business Integration] -?http://ibiztech.wordpress.com [About Me] - http://about.me/perfexcellence From mukom.tamon at gmail.com Sat Mar 3 01:51:45 2012 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Sat, 3 Mar 2012 11:51:45 +0400 Subject: Small ISP Need to Know In-Reply-To: References: Message-ID: On Sun, Feb 26, 2012 at 5:02 AM, not common wrote: > > Where is a good place (or places) to start learning ISP operations "Need To > Know"? > The problem with "Need to Know" especially operationally is you end up with lot of advice from 'experienced' people which would be useless to you if you lack the theoretical framework. I'll recommend getting a good book on any entry level network certification (CCNA, Network+ etc) and actually learning to understand (as opposed to pass an exam). Use GNS3 at all levels of your learning. -- Mukom Akong [Tamon] ______________ ?We don't LIVE in order to BREATH. Similarly WORKING in order to make MONEY puts us on a one way street to irrelevance.? [In Search of Excellence & Perfection] - http://perfexcellence.org [Moments of TechXcellence] - http://techexcellence.net [ICT Business Integration] -?http://ibiztech.wordpress.com [About Me] - http://about.me/perfexcellence From mukom.tamon at gmail.com Sat Mar 3 02:33:49 2012 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Sat, 3 Mar 2012 12:33:49 +0400 Subject: Common operational misconceptions In-Reply-To: <4F3C51F4.2020305@rancid.berkeley.edu> References: <20120215144715.18e65a55@w520.localdomain> <4F3C51F4.2020305@rancid.berkeley.edu> Message-ID: On Thu, Feb 16, 2012 at 4:46 AM, Michael Sinatra wrote: > ULA is the IPv6 equivalent of RFC1918 Michael, could you explain this a bit more? In the sense that : a. Anyone can use ULA pretty much as they wish without having to go to their ISP or RIR - same for RFC1918 b. In order to get to the public Internet, with ULA addressing, some kind of translation is required - same for RFC1918 c. Without centralised registration, two different networks could end up using same ULA space - same for RFC1918 There are certainly not identical but I'd think loosely equivalent. What am I missing? > -- Mukom Akong [Tamon] ______________ ?We don't LIVE in order to BREATH. Similarly WORKING in order to make MONEY puts us on a one way street to irrelevance.? [In Search of Excellence & Perfection] - http://perfexcellence.org [Moments of TechXcellence] - http://techexcellence.net [ICT Business Integration] -?http://ibiztech.wordpress.com [About Me] - http://about.me/perfexcellence From faisal at snappydsl.net Sat Mar 3 08:01:29 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sat, 03 Mar 2012 09:01:29 -0500 Subject: which one a Technical Support or Help Desk In-Reply-To: References: Message-ID: <4F522439.1010106@snappydsl.net> You can always call it HelpDesk/Technical Support They both mean the same thing, but create a different feeling in the minds of the customers. Helpdesk is typically perceived to be gentler (more informal / more flexible) providing support on a wider range of technical issues. Technical Support is perceived to be more focused, a bit more formal, and possibly providing support on narrow set of technical issues. We operate in two geographies.... In Athens, Georgia (College Town about 50 mile NE of Atlanta) the support department is knows as the Helpdesk. (We acquired that operation, and previous owners had chosen that term, so we stayed with it). and in South Florida, we call it Tech Support. As you can see from my email signature, we often use those two terms interchangeably. Good Luck with your choice. Regards. Faisal Imtiaz Snappy Internet& Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 3/3/2012 2:46 AM, Tarig Adam wrote: > I am working for a new Small ISP and we are trying to establish a > center for receiving technical calls and inquires from customers and > the technicians in this center may do some basics troubleshooting. > > What is the suitable title for this center and what we should call > this people who do this job? Technical Support, Helpdesk, or Call > Center. does each term has a specific meaning? > And is there any standard structure of this center? And what is the > relation of this people with other network/software Engineers? > > Thanks in advance. > > From bill at herrin.us Sat Mar 3 08:56:42 2012 From: bill at herrin.us (William Herrin) Date: Sat, 3 Mar 2012 09:56:42 -0500 Subject: which one a Technical Support or Help Desk In-Reply-To: References: Message-ID: On Sat, Mar 3, 2012 at 2:46 AM, Tarig Adam wrote: > I am working for a new Small ISP and we are trying to establish a > center for receiving technical calls and inquires from customers and > the technicians in this center may do some basics troubleshooting. > > What is the suitable title for this center and what we should call > this people who do this job? Technical Support, Helpdesk, or Call > Center. does each term has a specific meaning? Hi Tarig, For what it's work, I think of the terms this way: Help Desk: The place I call when I need my employer's IT department to fix my broken computer. Call Center: The place that wants to administer a telephone survey while I'm trying to eat dinner. Technical Support: The place I call when a technology product or service malfunctions. > And is there any standard structure of this center? Varies with size. At one end of the spectrum you have 3 phones with call distribution from the tech support number. At the other you have a dedicated office building containing staff with product specialties. >And what is the > relation of this people with other network/software Engineers? The engineers are second or third tier support. When Tech Support can't solve the problem, Tech Support calls an engineer for help. Once the engineer does his magic, Tech Support verifies it and then responds to the customer. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joesox at gmail.com Sat Mar 3 09:04:52 2012 From: joesox at gmail.com (JoeSox) Date: Sat, 3 Mar 2012 07:04:52 -0800 Subject: which one a Technical Support or Help Desk In-Reply-To: References: Message-ID: Go with 'Technical Support' unless you want to take all sorts of calls with end users wanting help on operational training issues. THIS DOES HAPPEN! -- Thanks, Joe On Sat, Mar 3, 2012 at 6:56 AM, William Herrin wrote: > On Sat, Mar 3, 2012 at 2:46 AM, Tarig Adam wrote: >> I am working for a new Small ISP and we are trying to establish a >> center for receiving technical calls and inquires from customers and >> the technicians in this center may do some basics troubleshooting. >> >> What is the suitable title for this center and what we should call >> this people who do this job? Technical Support, Helpdesk, or Call >> Center. does each term has a specific meaning? > > Hi Tarig, > > For what it's work, I think of the terms this way: > > Help Desk: The place I call when I need my employer's IT department to > fix my broken computer. > > Call Center: The place that wants to administer a telephone survey > while I'm trying to eat dinner. > > Technical Support: The place I call when a technology product or > service malfunctions. > > >> And is there any standard structure of this center? > > Varies with size. At one end of the spectrum you have 3 phones with > call distribution from the tech support number. At the other you have > a dedicated office building containing staff with product specialties. > > >>And what is the >> relation of this people with other network/software Engineers? > > The engineers are second or third tier support. When Tech Support > can't solve the problem, Tech Support calls an engineer for help. Once > the engineer does his magic, Tech Support verifies it and then > responds to the customer. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From Valdis.Kletnieks at vt.edu Sat Mar 3 09:34:07 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 03 Mar 2012 10:34:07 -0500 Subject: which one a Technical Support or Help Desk In-Reply-To: Your message of "Sat, 03 Mar 2012 07:04:52 PST." References: Message-ID: <98180.1330788847@turing-police.cc.vt.edu> On Sat, 03 Mar 2012 07:04:52 PST, JoeSox said: > Go with 'Technical Support' unless you want to take all sorts of calls > with end users wanting help on operational training issues. > THIS DOES HAPPEN! Which is OK, if that's your business model. I know a few small ISPs that are making a comfortable living selling repackaged DSL plus handholding. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jeff-kell at utc.edu Sat Mar 3 09:51:47 2012 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 3 Mar 2012 10:51:47 -0500 Subject: which one a Technical Support or Help Desk In-Reply-To: <98180.1330788847@turing-police.cc.vt.edu> References: <98180.1330788847@turing-police.cc.vt.edu> Message-ID: <4F523E13.8070501@utc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/3/2012 10:34 AM, Valdis.Kletnieks at vt.edu wrote: > On Sat, 03 Mar 2012 07:04:52 PST, JoeSox said: >> Go with 'Technical Support' unless you want to take all sorts of calls >> with end users wanting help on operational training issues. >> THIS DOES HAPPEN! > > Which is OK, if that's your business model. I know a few small ISPs that > are making a comfortable living selling repackaged DSL plus handholding. Especially if a human answers promptly without a horrible accent... Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9SPhMACgkQiwXJq373XhZTgwCg7ImBfYfyanvYaAA6PcIVQCRw Ti0AoKSNAmH7RXrT1J0x1Ss1CVhLa76R =HBJ+ -----END PGP SIGNATURE----- From faisal at snappydsl.net Sat Mar 3 09:57:40 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sat, 03 Mar 2012 10:57:40 -0500 Subject: which one a Technical Support or Help Desk In-Reply-To: <4F523E13.8070501@utc.edu> References: <98180.1330788847@turing-police.cc.vt.edu> <4F523E13.8070501@utc.edu> Message-ID: <4F523F74.9070305@snappydsl.net> > Especially if a human answers promptly without a horrible accent... > > Jeff Like a heavy Southern Drawl ? :) Hope you realize that this list a Global list, and not everyone is talking about "US Only". Cheers, Faisal Imtiaz Snappy Internet& Telecom From dave.nanog at alfordmedia.com Sat Mar 3 10:26:41 2012 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Sat, 03 Mar 2012 10:26:41 -0600 Subject: which one a Technical Support or Help Desk In-Reply-To: <4F523F74.9070305@snappydsl.net> Message-ID: On 3/3/12 9:57 AM, "Faisal Imtiaz" wrote: >>Especially if a human answers promptly without a horrible accent... >> >>Jeff >Like a heavy Southern Drawl ? Saah, Ah resemble that remahk! :^) I think no matter where you're located, having a tech support rep who speaks your language with an accent not too dissimilar to your own can be a huge help. I've had tech support calls go bad because of unintelligible accents when I was calling centers in India and in Ireland, but also in the US when I found the last of the Clampett clan answering phones for an ISP. (I've lived in Texas almost 16 years-- if you're so redneck that *I* can't understand you, you need a job where all your communication is in writing. Or pictures.) -- Dave Pooser Manager of Information Services Alford Media http://www.alfordmedia.com From jeff-kell at utc.edu Sat Mar 3 10:36:28 2012 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 3 Mar 2012 11:36:28 -0500 Subject: which one a Technical Support or Help Desk In-Reply-To: <4F523F74.9070305@snappydsl.net> References: <98180.1330788847@turing-police.cc.vt.edu> <4F523E13.8070501@utc.edu> <4F523F74.9070305@snappydsl.net> Message-ID: <4F52488C.6060700@utc.edu> On 3/3/2012 10:57 AM, Faisal Imtiaz wrote: > >> Especially if a human answers promptly without a horrible accent... >> >> Jeff > Like a heavy Southern Drawl ? Oh yeah, y'all :) The major point was a "human" answering, at least my home ISP (Charter) has this unbearable voice response... in annoyingly perfect English, although there is a Spanish option when it first starts :) If you have humans answering, you can call them anything you like, you're ahead of the curve. If not, "it" is going to be called all sorts of things, and Technical Support or Helpdesk is not among the options that come to mind... Jeff From faisal at snappydsl.net Sat Mar 3 10:48:07 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sat, 03 Mar 2012 11:48:07 -0500 Subject: which one a Technical Support or Help Desk In-Reply-To: References: Message-ID: <4F524B47.4070708@snappydsl.net> Touche....! Being in South Florida, (heavy Latin & Spanish accents) and having customers in Alabama, Tennessee (Heavy Southern accents) etc, we have had to "Tune" our ears as well as our Accents, including carefully choosing our words... It is not uncommon for us to have a new support Rep. get on a call and start making strange facial expressions.. saying.. " I know the caller is speaking English, but I cannot make out a word of what they are saying !"... Which of-course goes both ways, a Southern English speaker has equally hard time understanding heavy Latin and Eastern European accents. The sad part but true reality is, that most folks when they hear a different accent, automatically equate accent with professional competency .. and that is the toughest thing to overcome for phone support work. City folks, will often equate Southern accent with someone who is less proficient and slow, while the Southern folks will equate the Northern Accent with someone trying to be slick and pulling a fast one on them.. And then of course we have our favorite New Yorkers, (Manhattan / Queens etc) who simply equate politeness as a sing of weakness and try to railroad you if you are too polite. It's all good, it's all fun, it's all part of life, and surprising to most, this is COMMON HUMAN behavior across ALL Parts of the World. Not just unique to USA and Indian Call Centers.. :) Regards Faisal Imtiaz Snappy Internet& Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 3/3/2012 11:26 AM, Dave Pooser wrote: > On 3/3/12 9:57 AM, "Faisal Imtiaz" wrote: > >>> Especially if a human answers promptly without a horrible accent... >>> >>> Jeff >> Like a heavy Southern Drawl ? > Saah, Ah resemble that remahk! > > :^) > > I think no matter where you're located, having a tech support rep who > speaks your language with an accent not too dissimilar to your own can be > a huge help. I've had tech support calls go bad because of unintelligible > accents when I was calling centers in India and in Ireland, but also in > the US when I found the last of the Clampett clan answering phones for an > ISP. (I've lived in Texas almost 16 years-- if you're so redneck that *I* > can't understand you, you need a job where all your communication is in > writing. Or pictures.) From faisal at snappydsl.net Sat Mar 3 11:07:50 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sat, 03 Mar 2012 12:07:50 -0500 Subject: which one a Technical Support or Help Desk In-Reply-To: <4F52488C.6060700@utc.edu> References: <98180.1330788847@turing-police.cc.vt.edu> <4F523E13.8070501@utc.edu> <4F523F74.9070305@snappydsl.net> <4F52488C.6060700@utc.edu> Message-ID: <4F524FE6.6010502@snappydsl.net> Funny u mentioned Charter, had to call in a support ticket to them this morning. ( Cable down, due to yesterday's nasty storms). Having no accent is always preferred, but not possible. And as to Automated service... we see two kinds of folks... Ones who have a preference for self service, and another who wants human contact. I was actually impressed with the Charter Customer Service Phone front end. It recognized me by my Caller ID phone number, It was clean, crisp, and voice recognition was pretty good and it immediately told me that there was an outage in my area, and they are working on fixing it, plus it offered to call me back once the problem is resolved. After it gave me the info, I asked to speak to a Support Rep, and it transferred me to them. So far this is one the best Customer Service Phone system front end I have come across in a long time. Yes, humans are preferred, but if I can have the system give me updates quickly, vs. having to hold for 20 or 30 min for a human to give me the same info... I prefer the machine.... :) Faisal Imtiaz Snappy Internet& Telecom On 3/3/2012 11:36 AM, Jeff Kell wrote: > If you have humans answering, you can call them anything you like, > you're ahead of the curve. If not, "it" is going to be called all sorts > of things, and Technical Support or Helpdesk is not among the options > that come to mind... From gbonser at seven.com Sat Mar 3 11:13:47 2012 From: gbonser at seven.com (George Bonser) Date: Sat, 3 Mar 2012 17:13:47 +0000 Subject: which one a Technical Support or Help Desk In-Reply-To: <4F523F74.9070305@snappydsl.net> References: <98180.1330788847@turing-police.cc.vt.edu> <4F523E13.8070501@utc.edu> <4F523F74.9070305@snappydsl.net> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CFA60E@RWC-MBX1.corp.seven.com> > -----Original Message----- > From: Faisal Imtiaz > Sent: Saturday, March 03, 2012 7:58 AM > To: nanog at nanog.org > Subject: Re: which one a Technical Support or Help Desk > > > > Especially if a human answers promptly without a horrible accent... > > > > Jeff > Like a heavy Southern Drawl ? > > :) > > Hope you realize that this list a Global list, and not everyone is > talking about "US Only". Well, it is a North American list. A "heavy Southern drawl" is perfectly fine in the Southeastern US, and might even be welcome by customers there. It's no worse than a thick New England accent. But there are plenty of places, particularly in the mountain West of the US, where such help is relatively inexpensive and the accent is neutral. A call center in Montana/Utah/Wyoming/Idaho or even the Dakotas/Nebraska/Kansas for a national player isn't a bad idea. Help is relatively inexpensive, the people can be understood nationally, and in Central or Mountain timezone give you decent national coverage without a bunch of overtime. The help center doesn't have to be physically located with your actual network operations infrastructure. In fact, there are good reasons why you don't want that. If your operations have experienced a catastrophic failure (power outage, lightning strike, cable cut), your customers could still reach a real live person. But having customer reps that speak in the same "accent" as the customers they are serving can be a nice touch, too. If most of your customers are in the Southeastern or Northeastern US, maybe you WANT reps that sound like your customers. From jeff-kell at utc.edu Sat Mar 3 11:14:28 2012 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 3 Mar 2012 12:14:28 -0500 Subject: which one a Technical Support or Help Desk In-Reply-To: <4F524B47.4070708@snappydsl.net> References: <4F524B47.4070708@snappydsl.net> Message-ID: <4F525174.3090206@utc.edu> On 3/3/2012 11:48 AM, Faisal Imtiaz wrote: > Touche....! > > Being in South Florida, (heavy Latin & Spanish accents) and having > customers in Alabama, Tennessee (Heavy Southern accents) etc, we have > had to "Tune" our ears as well as our Accents, including carefully > choosing our words... Yes, it goes both ways :) It would be very interesting to get some statistics/reports out of Apple's Siri project as to the "hardest cases". My cousin recently got an iPhone with Siri. She has a much worse drawl than mine :) She told it to "Call Jeff", and Siri says "I see no J F in your contacts". (Imagine a very heavily drawled "Jeff" more like "Jaaay-Yufff", decidedly two syllables there...) She's had mixed results with Siri :) It may be beneficial speech therapy for her, but hard to change decades of Southern :) Jeff From michael at rancid.berkeley.edu Sat Mar 3 12:55:08 2012 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sat, 03 Mar 2012 10:55:08 -0800 Subject: Common operational misconceptions In-Reply-To: References: <20120215144715.18e65a55@w520.localdomain> <4F3C51F4.2020305@rancid.berkeley.edu> Message-ID: <4F52690C.7010908@rancid.berkeley.edu> On 03/03/12 00:33, Mukom Akong T. wrote: > On Thu, Feb 16, 2012 at 4:46 AM, Michael Sinatra > wrote: >> ULA is the IPv6 equivalent of RFC1918 > > Michael, could you explain this a bit more? In the sense that : > > a. Anyone can use ULA pretty much as they wish without having to go to > their ISP or RIR - same for RFC1918 > b. In order to get to the public Internet, with ULA addressing, some > kind of translation is required - same for RFC1918 Actually, (b) isn't quite correct, especially depending on how you define "the public Internet." If you define it as "the DFZ," then we're *probably* okay. If you define it as "any commercial ISP and/or any inter-AS traffic," then it's not so clear. To plagiarize myself in a previous private response to someone else: ULAs allow for native routing across a commercial ISP backbone to support "extranets" (ugh, I hate that word)--essentially to allow an enterprise to use a regular ISP (or ISPs) to carry ULA traffic between sites. RFC 1918 requires that all privately-addressed traffic be encapsulated if it is routed into another AS. The consequence is that any AS can filter all RFC 1918 routes *and* traffic at its border(s) and ISPs can (and SHOULD) refuse to route unencapsulated RFC 1918-addressed traffic between ASes. ULAs may require holes to be poked in any blanket filter. I see that as a significant difference because you can no longer "guarantee" non-routability of the space, which is what people tend to count on. (We hope this won't happen, but it's not explicitly prevented by RFC 4193 as it is by RFC 1918. And see Ted Hardie's "rant" on the subject at NANOG 40 for an argument that it might: www.nanog.org/meetings/nanog40/presentations/ula-nanog.pdf) My own view on this is that it's likely that ULA will stay out of the DFZ (due to the now-widespread availability of IPv6 PI), but that you may not be able to count on security (i.e. *traffic*) filters being magically in place everywhere as one does for RFC 1918. (Again, that's probably a misconception of RFC 1918, but there is still a big difference in the potential for the consistent violation of the "magic filter" assumption for ULA.) > c. Without centralised registration, two different networks could end > up using same ULA space - same for RFC1918 Yeah, but there's an orders-of-magnitude difference in the ability to generate a reasonable expectation of uniqueness. Look at common RFC1918 usage--it often falls into 192.168.0.0/23 (e.g. most CPE NAT devices) or 10.0.0.0/23. Larger users tend to be all over net 10, which makes merging networks a lot harder. It's much more likely that such mergers will work better with ULA. The large ULA space had put pressure on the standards community to define something like ULA-C, but PI IPv6 has relieved that pressure. However, the fact that ULA-C-like-things were ever proposed illustrates the differences between ULA and RFC 1918 space. > There are certainly not identical but I'd think loosely equivalent. > What am I missing? There's also a third difference that interacts with the typical misconception that RFC 1918 implies or somehow specifies NAT (which I think I mentioned elsewhere). When people think that RFC 1918 == NAT, they get really surprised that there's no stateful NAT in IPv6. Given the address space of IPv6, stateless prefix translation could go a long way toward giving one the same functionality, but people tend to want NAT to perform the stateful overloading of public IP addresses. So there are really three misconceptions at work here: RFC 1918 implies NAT NAT is defined as stateful overloading of a small pool of public IP addresses to support lots of private IP addresses. (Stateless NAT? Whut??) ULAs are the same as RFC 1918 addresses I realize that last one is cheating a bit because it it requires three misconceptions to create the resultant confusion about there not being stateful NAT66, but it *does* exist in the wild. michael From joesox at gmail.com Sat Mar 3 13:05:25 2012 From: joesox at gmail.com (JoeSox) Date: Sat, 3 Mar 2012 11:05:25 -0800 Subject: which one a Technical Support or Help Desk In-Reply-To: <98180.1330788847@turing-police.cc.vt.edu> References: <98180.1330788847@turing-police.cc.vt.edu> Message-ID: On Sat, Mar 3, 2012 at 7:34 AM, wrote: > Which is OK, if that's your business model. ?I know a few small ISPs that > are making a comfortable living selling repackaged DSL plus handholding. > In the case I was thinking of, a small Techsupport group answering questions about 'How does my customer get an account." These questions really needs to be answered by their supervisor. "But aren't you the 'HelpDesk' I call when I need help!?" That makes sense for the DSL business. -- Thanks, Joe From nanog.guru at gmail.com Sat Mar 3 13:34:20 2012 From: nanog.guru at gmail.com (Guru NANOG) Date: Sat, 3 Mar 2012 13:34:20 -0600 Subject: Spread Spectrum IP Addressing - SOURCE Address Field ROTATED|shifted? Left 2 Bits Message-ID: Common Misconception With Spread Spectrum IP Addressing the 32-bit Source Address Field is Shifted LEFT 2-bits by the originator of the packet. That Folds the IPv4 Legacy Address Space into 1/4th tsize table The lost 2-bits are stored in the Right-Most 2 bits of the 32-bit field and in other places in the IPv4 Header The Destination can easily recover the Source Address - if the proper algorithms are in use Responses blindly sent back to the shifted Source Address may fall into agile hands or not With the advanced Spread-Spectrum techniques, additional addressing bits are created from the noise intentionally stored in the Right-Most 2 bits NANOG Operators buying /8s or /6s may want to look at the Spread-Spectrum CODE in the Linux-based CPE Routers The following table is deprecated and 1/4th the size: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt With Spread-Spectrum collisions and mis-directions are OK and expected but other techniques ensure the packets get to the right place. http://NANOG.GURU From lykinsbd at gmail.com Sat Mar 3 14:00:16 2012 From: lykinsbd at gmail.com (Brett Lykins) Date: Sat, 3 Mar 2012 15:00:16 -0500 Subject: which one a Technical Support or Help Desk In-Reply-To: References: Message-ID: At a Small-to-Medium ISP I worked for, they went through structuring changes like this all the time. But the following seems to be the best setup: First was "Customer Support" which dealt with billing and basic instruction (setup mail clients, reset passwords, etc). Second tier was "Customer Data Support" or CDS, which covered troubleshooting connectivity and doing advanced instruction. Third tier support was the Network Operations Center. CDS escalated to them if there was a particularly difficult or CO Equipment related issue. The NOC could then escalate to the actual Engineering department or to the CO Repair staff as needed. -- The nice thing about this setup was that it grew with the company. Each of those departments started out as one or two people, but grew their own sub-tiers/sub-teams as systems grew and became more complicated. Also, the name didn't really matter too much to the customer. They chose the option for "Problems with your connection or if you need technical support" from the phone tree, and we just answered with the company's name. We never said "Customer Data Support, this is Brett", just "CompanyX, this is Brett" There are a couple of good System Administration guide books out there that give basic Help Desk structuring and reporting paths. They are usually geared more towards the enterprise, but some good information can be gleaned from them as well. Hope this helps, -Brett Lykins On Mar 3, 2012, at 2:46 AM, Tarig Adam wrote: > I am working for a new Small ISP and we are trying to establish a > center for receiving technical calls and inquires from customers and > the technicians in this center may do some basics troubleshooting. > > What is the suitable title for this center and what we should call > this people who do this job? Technical Support, Helpdesk, or Call > Center. does each term has a specific meaning? > And is there any standard structure of this center? And what is the > relation of this people with other network/software Engineers? > > Thanks in advance. > > > -- > Tarig Adam > From kmedcalf at dessus.com Sat Mar 3 15:13:33 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 03 Mar 2012 14:13:33 -0700 Subject: Spread Spectrum IP Addressing - SOURCE Address Field ROTATED|shifted? Left 2 Bits In-Reply-To: Message-ID: <62f21866f6a61a47baa629971c156170@mail.dessus.com> Is it April already? I though April Fools Day wasn't until next month. I did, I did. I did see a snake-oil salesman! --- ()? ascii ribbon campaign against html e-mail /\? www.asciiribbon.org > -----Original Message----- > From: Guru NANOG [mailto:nanog.guru at gmail.com] > Sent: Saturday, 03 March, 2012 12:34 > To: nanog at nanog.org > Subject: Spread Spectrum IP Addressing - SOURCE Address Field > ROTATED|shifted? Left 2 Bits > > Common Misconception > > With Spread Spectrum IP Addressing the 32-bit Source Address Field is > Shifted LEFT 2-bits by the originator of the packet. > > That Folds the IPv4 Legacy Address Space into 1/4th tsize table > > The lost 2-bits are stored in the Right-Most 2 bits of the 32-bit > field and in other places in the IPv4 Header > > The Destination can easily recover the Source Address - if the proper > algorithms are in use > > Responses blindly sent back to the shifted Source Address may fall > into agile hands or not > > With the advanced Spread-Spectrum techniques, additional addressing > bits are created from the noise intentionally stored in the Right-Most > 2 bits > > NANOG Operators buying /8s or /6s may want to look at the > Spread-Spectrum CODE in the Linux-based CPE Routers > > The following table is deprecated and 1/4th the size: > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt > > With Spread-Spectrum collisions and mis-directions are OK and expected but > other > techniques ensure the packets get to the right place. > > http://NANOG.GURU From mysidia at gmail.com Sat Mar 3 16:39:55 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 3 Mar 2012 16:39:55 -0600 Subject: Spread Spectrum IP Addressing - SOURCE Address Field ROTATED|shifted? Left 2 Bits In-Reply-To: <62f21866f6a61a47baa629971c156170@mail.dessus.com> References: <62f21866f6a61a47baa629971c156170@mail.dessus.com> Message-ID: On Sat, Mar 3, 2012 at 3:13 PM, Keith Medcalf wrote: > Is it April already? ?I though April Fools Day wasn't until next month. > I did, I did. ?I did see a snake-oil salesman! It sounds like the "IPv3" / "IPv8" guy crawled back out of the woodwork. Yeah, April fools is next month, but that's for actual pranks/jokes; I suspect the poster is actually serious, however misguided; April fools is just one day -- misguided folks make nonsensical suggestions ~365.24219 days a year (on average). -- -JH From nanog.guru at gmail.com Sat Mar 3 17:02:29 2012 From: nanog.guru at gmail.com (Guru NANOG) Date: Sat, 3 Mar 2012 17:02:29 -0600 Subject: NANOG Operational TTL Alert for 160-bit Headers (aka IPv4) Message-ID: Common Misconception - IPv4 is Out of Address Space NANOG Operational TTL Alert for 160-bit Headers (aka IPv4) The 8-bit TTL field is reduced to 4-bits plus two 11 bits stuck at 1 for a long time The new 8-bit fields are: SD11TTTT Packets without the 11 will enter Deep Packet Inspection processing (slow) SD are new Source and Destination Address bits set via the generic AAAA 128-bit records 4+8+12+30+6 = 60 + 68 = 128 VRHL+111.T1.000+Port12+30+Frag6 T1 sets the TTL bits - Use T0 at your own risk - VRHL=0101=5 NANOG.GURU.? From robertg at garlic.com Sat Mar 3 17:25:41 2012 From: robertg at garlic.com (Robert Glover) Date: Sat, 3 Mar 2012 15:25:41 -0800 Subject: NANOG Operational TTL Alert for 160-bit Headers (aka IPv4) In-Reply-To: References: Message-ID: Someone get this man a Xanax! -----Original message----- From: Guru NANOG To: nanog Sent: 2012 Mar, Sun, 4 00:01:04 GMT+00:00 Subject: NANOG Operational TTL Alert for 160-bit Headers (aka IPv4) Common Misconception - IPv4 is Out of Address Space NANOG Operational TTL Alert for 160-bit Headers (aka IPv4) The 8-bit TTL field is reduced to 4-bits plus two 11 bits stuck at 1 for a long time The new 8-bit fields are: SD11TTTT Packets without the 11 will enter Deep Packet Inspection processing (slow) SD are new Source and Destination Address bits set via the generic AAAA 128-bit records 4+8+12+30+6 = 60 + 68 = 128 VRHL+111.T1.000+Port12+30+Frag6 T1 sets the TTL bits - Use T0 at your own risk - VRHL=0101=5 NANOG.GURU.? From randy_94108 at yahoo.com Sat Mar 3 17:36:05 2012 From: randy_94108 at yahoo.com (Randy) Date: Sat, 3 Mar 2012 15:36:05 -0800 (PST) Subject: Spread Spectrum IP Addressing - SOURCE Address Field ROTATED|shifted? Left 2 Bits In-Reply-To: Message-ID: <1330817765.25804.YahooMailClassic@web181103.mail.ne1.yahoo.com> --- On Sat, 3/3/12, Jimmy Hess wrote: > From: Jimmy Hess > Subject: Re: Spread Spectrum IP Addressing - SOURCE Address Field ROTATED|shifted? Left 2 Bits > To: "Keith Medcalf" > Cc: "nanog at nanog.org" > Date: Saturday, March 3, 2012, 2:39 PM > On Sat, Mar 3, 2012 at 3:13 PM, Keith > Medcalf > wrote: > > Is it April already? ?I though April Fools Day wasn't > until next month. > > I did, I did. ?I did see a snake-oil salesman! > > It sounds like the "IPv3" / "IPv8"? guy crawled back > out of the woodwork. > > Yeah, April fools is next month,? but that's for actual > pranks/jokes; > I suspect the poster > is actually serious,? however > misguided;???April fools is just one day > -- misguided folks > make nonsensical suggestions ~365.24219 days a year (on > average). > > -- > -JH > I am reminded of: "The mathematical reality of IPv4". At least that made for interesting bed time reading... disposition: removed. ./Randy From leigh.porter at ukbroadband.com Sat Mar 3 18:12:47 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sun, 4 Mar 2012 00:12:47 +0000 Subject: NANOG Operational TTL Alert for 160-bit Headers (aka IPv4) In-Reply-To: References: , Message-ID: <97E575DA-9C0B-4182-8A5D-99B4B5D762B1@ukbroadband.com> He has a point. The IPv4 exhaustion problem was manufactured by the illuminati to usher in their IPv6 protocol (note the use of the number 6, the number if the beast. Combined with the tuple of source, destination address and protocol type this is 666!). The illuminati want us to deploy IPv6 so they can use it to control people ready for the new world order. It was all predicted by Nostradamus. Innit. -- Leigh Porter On 3 Mar 2012, at 23:27, "Robert Glover" wrote: > Someone get this man a Xanax! > > -----Original message----- > From: Guru NANOG > To: nanog > Sent: 2012 Mar, Sun, 4 00:01:04 GMT+00:00 > Subject: NANOG Operational TTL Alert for 160-bit Headers (aka IPv4) > > Common Misconception - IPv4 is Out of Address Space > > NANOG Operational TTL Alert for 160-bit Headers (aka IPv4) > > The 8-bit TTL field is reduced to 4-bits plus two 11 bits stuck at 1 > for a long time > > The new 8-bit fields are: SD11TTTT > > Packets without the 11 will enter Deep Packet Inspection processing (slow) > > SD are new Source and Destination Address bits set via the generic > AAAA 128-bit records > > 4+8+12+30+6 = 60 + 68 = 128 > > VRHL+111.T1.000+Port12+30+Frag6 > > T1 sets the TTL bits - Use T0 at your own risk - VRHL=0101=5 > > NANOG.GURU.? > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From MGauvin at dryden.ca Sat Mar 3 19:20:21 2012 From: MGauvin at dryden.ca (Mark Gauvin) Date: Sat, 3 Mar 2012 19:20:21 -0600 Subject: NANOG Operational TTL Alert for 160-bit Headers (aka IPv4) In-Reply-To: References: Message-ID: Someone has been drinking the bong water Sent from my iPhone On 2012-03-03, at 5:03 PM, "Guru NANOG" wrote: > Common Misconception - IPv4 is Out of Address Space > > NANOG Operational TTL Alert for 160-bit Headers (aka IPv4) > > The 8-bit TTL field is reduced to 4-bits plus two 11 bits stuck at 1 > for a long time > > The new 8-bit fields are: SD11TTTT > > Packets without the 11 will enter Deep Packet Inspection processing > (slow) > > SD are new Source and Destination Address bits set via the generic > AAAA 128-bit records > > 4+8+12+30+6 = 60 + 68 = 128 > > VRHL+111.T1.000+Port12+30+Frag6 > > T1 sets the TTL bits - Use T0 at your own risk - VRHL=0101=5 > > NANOG.GURU.? > From ops.lists at gmail.com Sat Mar 3 20:24:05 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 4 Mar 2012 07:54:05 +0530 Subject: which one a Technical Support or Help Desk In-Reply-To: <4F52488C.6060700@utc.edu> References: <98180.1330788847@turing-police.cc.vt.edu> <4F523E13.8070501@utc.edu> <4F523F74.9070305@snappydsl.net> <4F52488C.6060700@utc.edu> Message-ID: A newsgroup I used to read a decade back used to call it "helldesk" But seriously, live humans with whatever location or accent, answering an actual phone, are the costliest sort of ticket an ISP has to handle. The focus needs to be on providing the customer enough self help tools, wikis, user forums, email support, IVR .. before they even need to phone your helpdesk and have a human open or work a ticket for them. It is that or watch your margins get shredded due to spiraling support costs. --srs On 3/3/12, Jeff Kell wrote: > On 3/3/2012 10:57 AM, Faisal Imtiaz wrote: >> >>> Especially if a human answers promptly without a horrible accent... >>> >>> Jeff >> Like a heavy Southern Drawl ? > > Oh yeah, y'all :) > > The major point was a "human" answering, at least my home ISP (Charter) > has this unbearable voice response... in annoyingly perfect English, > although there is a Spanish option when it first starts :) > > If you have humans answering, you can call them anything you like, > you're ahead of the curve. If not, "it" is going to be called all sorts > of things, and Technical Support or Helpdesk is not among the options > that come to mind... > > Jeff > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From jay at west.net Sat Mar 3 20:29:28 2012 From: jay at west.net (Jay Hennigan) Date: Sat, 03 Mar 2012 18:29:28 -0800 Subject: NANOG Operational TTL Alert for 160-bit Headers (aka IPv4) In-Reply-To: References: Message-ID: <4F52D388.3090103@west.net> On 3/3/12 3:02 PM, Guru NANOG wrote: > Common Misconception - IPv4 is Out of Address Space You couldn't wait just 29 more days to post this? It would have been so much more appropriate. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From goemon at anime.net Sat Mar 3 20:45:06 2012 From: goemon at anime.net (goemon at anime.net) Date: Sat, 3 Mar 2012 18:45:06 -0800 (PST) Subject: is 74.218.84.10 a road runner IP address? In-Reply-To: <4F52D388.3090103@west.net> References: <4F52D388.3090103@west.net> Message-ID: abuse at rr.com doesn't seem to think so. -Dan From jackson.tim at gmail.com Sat Mar 3 21:03:13 2012 From: jackson.tim at gmail.com (Tim Jackson) Date: Sat, 3 Mar 2012 21:03:13 -0600 Subject: Spread Spectrum IP Addressing - SOURCE Address Field ROTATED|shifted? Left 2 Bits In-Reply-To: References: Message-ID: http:// www.timecube.com/ Goes together well.. On Mar 3, 2012 1:34 PM, "Guru NANOG" wrote: > Common Misconception > > With Spread Spectrum IP Addressing the 32-bit Source Address Field is > Shifted LEFT 2-bits by the originator of the packet. > > That Folds the IPv4 Legacy Address Space into 1/4th tsize table > > The lost 2-bits are stored in the Right-Most 2 bits of the 32-bit > field and in other places in the IPv4 Header > > The Destination can easily recover the Source Address - if the proper > algorithms are in use > > Responses blindly sent back to the shifted Source Address may fall > into agile hands or not > > With the advanced Spread-Spectrum techniques, additional addressing > bits are created from the noise intentionally stored in the Right-Most > 2 bits > > NANOG Operators buying /8s or /6s may want to look at the > Spread-Spectrum CODE in the Linux-based CPE Routers > > The following table is deprecated and 1/4th the size: > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt > > With Spread-Spectrum collisions and mis-directions are OK and expected but > other > techniques ensure the packets get to the right place. > > http://NANOG.GURU > > From randy at psg.com Sat Mar 3 21:12:10 2012 From: randy at psg.com (Randy Bush) Date: Sun, 04 Mar 2012 12:12:10 +0900 Subject: which one a Technical Support or Help Desk In-Reply-To: References: <98180.1330788847@turing-police.cc.vt.edu> <4F523E13.8070501@utc.edu> <4F523F74.9070305@snappydsl.net> <4F52488C.6060700@utc.edu> Message-ID: > The focus needs to be on providing the customer enough self help > tools, wikis, user forums, email support, IVR .. before they even need > to phone your helpdesk and have a human open or work a ticket for > them. i might toss in "a solid reliable working service" randy From hello at codatory.me Sat Mar 3 21:15:53 2012 From: hello at codatory.me (Alex Conner) Date: Sat, 03 Mar 2012 22:15:53 -0500 Subject: is 74.218.84.10 a road runner IP address? In-Reply-To: <4F52DE25.5040207@codatory.com> References: <4F52D388.3090103@west.net> <4F52DE25.5040207@codatory.com> Message-ID: <4F52DE69.7040403@codatory.me> According to Whois that's a commercial roadrunner connection, and it falls in one of their netblocks. Plenty of info here: http://bgp.he.net/ip/74.218.84.10 > goemon at anime.net > March 3, 2012 9:45 PM > abuse at rr.com doesn't seem to think so. > > -Dan > > > From Valdis.Kletnieks at vt.edu Sat Mar 3 21:15:37 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 03 Mar 2012 22:15:37 -0500 Subject: Spread Spectrum IP Addressing - SOURCE Address Field ROTATED|shifted? Left 2 Bits In-Reply-To: Your message of "Sat, 03 Mar 2012 13:34:20 CST." References: Message-ID: <124181.1330830937@turing-police.cc.vt.edu> On Sat, 03 Mar 2012 13:34:20 CST, Guru NANOG said: > http://NANOG.GURU I knew the ICANN expansion of TLDs would lead to no good... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From randy at psg.com Sat Mar 3 21:20:24 2012 From: randy at psg.com (Randy Bush) Date: Sun, 04 Mar 2012 12:20:24 +0900 Subject: Spread Spectrum IP Addressing - SOURCE Address Field ROTATED|shifted? Left 2 Bits In-Reply-To: <124181.1330830937@turing-police.cc.vt.edu> References: <124181.1330830937@turing-police.cc.vt.edu> Message-ID: show some sympathy or hit delete. this is likely a very sad person who needs professional, and i do not mean net geek, help. randy From goemon at anime.net Sat Mar 3 23:48:25 2012 From: goemon at anime.net (goemon at anime.net) Date: Sat, 3 Mar 2012 21:48:25 -0800 (PST) Subject: is 74.218.84.10 a road runner IP address? In-Reply-To: <4F52DE69.7040403@codatory.me> References: <4F52D388.3090103@west.net> <4F52DE25.5040207@codatory.com> <4F52DE69.7040403@codatory.me> Message-ID: So anyone have a roadrunner contact with some clue? -Dan On Sat, 3 Mar 2012, Alex Conner wrote: > According to Whois that's a commercial roadrunner connection, and it falls in > one of their netblocks. > > Plenty of info here: http://bgp.he.net/ip/74.218.84.10 >> goemon at anime.net >> March 3, 2012 9:45 PM >> abuse at rr.com doesn't seem to think so. >> >> -Dan >> >> >> > From bonomi at mail.r-bonomi.com Sun Mar 4 00:21:45 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 4 Mar 2012 00:21:45 -0600 (CST) Subject: Spread Spectrum IP Addressing - SOURCE Address Field ROTATED|shifted? Left 2 Bits In-Reply-To: Message-ID: <201203040621.q246LjZ6047946@mail.r-bonomi.com> On Mar 3, 2012 1:34 PM, "Guru NANOG" wrote: > > Common Misconception > > With Spread Spectrum IP Addressing the 32-bit Source Address Field is > Shifted LEFT 2-bits by the originator of the packet. [ [sneck ]] A unique way to get his two bits in. I trust he remembers to set the evil bit -- for mandatory RFC 3514 compliance. From drohan at gmail.com Sun Mar 4 00:41:58 2012 From: drohan at gmail.com (Daniel Rohan) Date: Sun, 4 Mar 2012 09:41:58 +0300 Subject: which one a Technical Support or Help Desk In-Reply-To: References: Message-ID: On Sat, Mar 3, 2012 at 10:46 AM, Tarig Adam wrote: > I am working for a new Small ISP and we are trying to establish a > center for receiving technical calls and inquires from customers and > the technicians in this center may do some basics troubleshooting. > > What is the suitable title for this center and what we should call > this people who do this job? Technical Support, Helpdesk, or Call > Center. does each term has a specific meaning? > And is there any standard structure of this center? And what is the > relation of this people with other network/software Engineers? Is your organization adopting any governance frameworks? In ITIL-speak, the function you are describing is called the Service Desk (but could actually be called anything you'd like-- i.e, The Genius Brothel, etc) >From the ITIL description of the Service Desk function: "The Service Desk acts as the central point of contact between service providers and users on a day to day basis. It is also a focal point for reporting incidents and for service requests. It can also provide an interface, for other service management activities (such as change, problem, configuration, release and continuity management)." I'd add to this description that it's a single point of contact (first in, last out) for any and all types of requests, including change management and internal requests. They also recognize that some organizations would also have local premises service desks where people could actually walk up to or be helped in a matter of minutes-- and that this function would be considered a "help desk", but only as *part* of a larger service desk. For more details on how ITIL structures this function, check the wikipedia page- they have some basic info that can get you started. -Dan From fernando at gont.com.ar Sun Mar 4 06:59:55 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Sun, 04 Mar 2012 09:59:55 -0300 Subject: IPv6 NIDS evasion and IPv6 fragmentation/reassembly improvements Message-ID: <4F53674B.5050501@gont.com.ar> Folks, FYI, It contains some test results regarding the implementation of RFC 5722 and draft-ietf-6man-ipv6-atomic-fragments. Thanks, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From streiner at cluebyfour.org Sun Mar 4 10:09:15 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 4 Mar 2012 11:09:15 -0500 (EST) Subject: Programmers with network engineering skills In-Reply-To: <22089644C8B3E843B2CA338CFEA9E4DF010ABF0FB1@sv2exmb01.us.win.equinix.com> References: <6088002.1109.1330381386271.JavaMail.root@benjamin.baylink.com> <4F4C0431.1010308@dougbarton.us> <22089644C8B3E843B2CA338CFEA9E4DF010ABF0FB1@sv2exmb01.us.win.equinix.com> Message-ID: On Mon, 27 Feb 2012, Jared Newell wrote: > I think the difference is that network engineers typically find > themselves wanting to learn some form of programming to automate routine > tasks while doing their job as a network engineer. They've actually > managed to be interested in programming while pursuing a career in > networking out of necessity. That pretty much the path that I took. I found a lot of value in automating tasks, which eventually grew into a configuration backup system that was used company-wide. I could have deployed one of several configuration management systems, but I wanted to build one from the ground up. While the code I wrote wasn't exactly pretty, it worked. No doubt there was a lot of room to do it better, and one of my long-term goals was to re-write the whole thing in a language that was better suited to the task at hand, I ended up moving on to a new gig before that came to pass. I still have the code (previous employer was OK with that), and I still tinker with it from time to time. It taught me a lot more about some of the nuts-and-bolts aspects of both coding and SNMP that I ever would have encountered, had I not written that system. I think I would also add to the wish list for "the perfect candidate" is some database experience. Sometimes data is much easier to work with in the SQL world than 'live'. jms From nanog.guru at gmail.com Sun Mar 4 10:22:15 2012 From: nanog.guru at gmail.com (Guru NANOG) Date: Sun, 4 Mar 2012 10:22:15 -0600 Subject: Evil Bit and Spread Spectrum IP Addressing - NANOG Source Address Shaping Message-ID: Common Misconception: One additional bit of IPv4 Addressing will solve world hunger The Evil Bit (or spare unused bit) can be used to store (restore) one bit The Left-Most bit of the 32-bit Source Address Field can be SET to Zero no matter what the original value. The Evil bit can be set IFF the Left-Most bit is **changed**. Setting the Left-Most bit to zero **folds** this table in half. http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Setting the Left-Most bit to ONE would move return traffic to the upper half of the Spectrum which has vast quantities of unused /8s Wide-spread consensus shows that TWO bits can work. Three bits folds the table to 1/8th. Governments want a 4-bit Return Prefix to their Super-Hubs for IPv6-like intercept. The U.S.FCC is expected to issue the regulations on how Spread Spectrum Source Address Shaping will work in their licensed CPE wireless devices. There are 160-bits in the deprecated header so there are many ways to go. One-Way Broadcast IP Addressing is now available. The Source Address Field is used for the second half of the 64-bit Destination Address. The DF (Did Flip) bit near the Evil Bit is used to note the two halves of the Destination Address have been *flipped*. NANOGers simply route 32 and then 32 after the flip based only on the Destination Field. There is no Source Address, only a channel (port). Keywords: WRT DNSMASQ Tomato WIFI Linux CPE From paul at paulgraydon.co.uk Sun Mar 4 12:09:21 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Sun, 04 Mar 2012 08:09:21 -1000 Subject: Evil Bit and Spread Spectrum IP Addressing - NANOG Source Address Shaping In-Reply-To: References: Message-ID: <4F53AFD1.5060500@paulgraydon.co.uk> ... Great, that's another filter to add to my mailserver. Paul On 3/4/2012 6:22 AM, Guru NANOG wrote: > Common Misconception: One additional bit of IPv4 Addressing will solve > world hunger > > The Evil Bit (or spare unused bit) can be used to store (restore) one bit > > The Left-Most bit of the 32-bit Source Address Field can be SET to > Zero no matter what the original value. The Evil bit can be set IFF > the Left-Most bit is **changed**. > > Setting the Left-Most bit to zero **folds** this table in half. > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt > > Setting the Left-Most bit to ONE would move return traffic to the > upper half of the Spectrum which has vast quantities of unused /8s > > Wide-spread consensus shows that TWO bits can work. Three bits folds > the table to 1/8th. > Governments want a 4-bit Return Prefix to their Super-Hubs for > IPv6-like intercept. > > The U.S.FCC is expected to issue the regulations on how Spread > Spectrum Source Address Shaping will work in their licensed CPE > wireless devices. There are 160-bits > in the deprecated header so there are many ways to go. > > One-Way Broadcast IP Addressing is now available. The Source Address > Field is used > for the second half of the 64-bit Destination Address. The DF (Did > Flip) bit near the Evil > Bit is used to note the two halves of the Destination Address have > been *flipped*. > NANOGers simply route 32 and then 32 after the flip based only on the > Destination Field. > There is no Source Address, only a channel (port). > > Keywords: WRT DNSMASQ Tomato WIFI Linux CPE > > From Valdis.Kletnieks at vt.edu Sun Mar 4 12:26:01 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 04 Mar 2012 13:26:01 -0500 Subject: which one a Technical Support or Help Desk In-Reply-To: Your message of "Sun, 04 Mar 2012 09:41:58 +0300." References: Message-ID: <155956.1330885561@turing-police.cc.vt.edu> On Sun, 04 Mar 2012 09:41:58 +0300, Daniel Rohan said: > Is your organization adopting any governance frameworks? I certainly hope not - any organization that needs that many buzzwords in a seven word sentence has probably jumped the shark so far that it needs more than a governance framework to cure the dysfunction. http://www.itgovernanceusa.com/itil.aspx "ITIL (Information Technology Infrastructure Library) is a best practice methodology for managing IT as a service. Developed by the UK's Office of Government Commerce (OGC), ITIL is the most widely used approach for IT Service Management in the world and is used by companies including Disney, NASA, HSBC and HP. Organizations cannot be certified against ITIL, however it is widely used as a method of preparation for achieving ISO20000 certification. Individuals can be certified against ITIL, and you can read about ITIL qualifications below. ITIL provides a clear framework for the identification, planning, delivery and support of IT services to an organisation. ITIL's core principle is that IT services must be aligned with the requirements of the business and underpin all processes within the business. IT services should be a business driver, facilitating change, growth and meeting business goals. There are five core titles in the ITIL publication suite which cover:" Ouch. "IT services must be aligned with the requirements"??!? I've always wondered how companies stay in business if they're so dysfunctional that they need a framework to recognize stuff like that. Does deploying this stuff in functional organizations actually work? Does it do any good? (OK.. I'll admit there's a one-sentence throw-away about SLA's at the very bottom of that page - though we don't use them for "governance", just making sure that everybody's on the same page about stuff like who calls who when stuff breaks. Usually ends up including lots of clauses like "If you want us to fix the router you wanted installed in your building, you have to make sure our techs can get into the building..") -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From techgrrl at gmail.com Sun Mar 4 12:43:03 2012 From: techgrrl at gmail.com (Elle Plato) Date: Sun, 4 Mar 2012 10:43:03 -0800 Subject: Evil Bit and Spread Spectrum IP Addressing - NANOG Source Address Shaping In-Reply-To: References: Message-ID: On Sun, Mar 4, 2012 at 8:22 AM, Guru NANOG wrote: > Common Misconception: One additional bit of IPv4 Addressing will solve > world hunger > Why not just fold source and destination into a single 64 bit end station address field, and use the evil bit to say whether or not the packet is going to, or coming from, google. We could call it IPv5, or IPv4++. and I am sure the merchants would have it in silicon within a week. Sadly this is a few weeks too early for people to be seriously thinking of an RFC for this. Elle Plato From bruns at 2mbit.com Sun Mar 4 17:39:38 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 04 Mar 2012 16:39:38 -0700 Subject: Spread Spectrum IP Addressing - SOURCE Address Field ROTATED|shifted? Left 2 Bits In-Reply-To: References: Message-ID: <4F53FD3A.300@2mbit.com> On 3/3/12 12:34 PM, Guru NANOG wrote: > Common Misconception > > With Spread Spectrum IP Addressing the 32-bit Source Address Field is > Shifted LEFT 2-bits by the originator of the packet. > > > http://NANOG.GURU > Guillaume Fontaine, is that you? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jhellenthal at dataix.net Sun Mar 4 21:24:23 2012 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sun, 4 Mar 2012 22:24:23 -0500 Subject: Falling for address collection (Was: Evil Bit and Spread Spectrum IP Addressing - NANOG Source Address Shaping) In-Reply-To: References: Message-ID: <20120305032423.GA73452@DataIX.net> Why does everyone keep falling for the same address collector ? ;-) -- LoL On Sun, Mar 04, 2012 at 10:22:15AM -0600, Guru NANOG wrote: > Common Misconception: One additional bit of IPv4 Addressing will solve > world hunger > > The Evil Bit (or spare unused bit) can be used to store (restore) one bit > > The Left-Most bit of the 32-bit Source Address Field can be SET to > Zero no matter what the original value. The Evil bit can be set IFF > the Left-Most bit is **changed**. > > Setting the Left-Most bit to zero **folds** this table in half. > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt > > Setting the Left-Most bit to ONE would move return traffic to the > upper half of the Spectrum which has vast quantities of unused /8s > > Wide-spread consensus shows that TWO bits can work. Three bits folds > the table to 1/8th. > Governments want a 4-bit Return Prefix to their Super-Hubs for > IPv6-like intercept. > > The U.S.FCC is expected to issue the regulations on how Spread > Spectrum Source Address Shaping will work in their licensed CPE > wireless devices. There are 160-bits > in the deprecated header so there are many ways to go. > > One-Way Broadcast IP Addressing is now available. The Source Address > Field is used > for the second half of the 64-bit Destination Address. The DF (Did > Flip) bit near the Evil > Bit is used to note the two halves of the Destination Address have > been *flipped*. > NANOGers simply route 32 and then 32 after the flip based only on the > Destination Field. > There is no Source Address, only a channel (port). > > Keywords: WRT DNSMASQ Tomato WIFI Linux CPE -- ;s =; From ops.lists at gmail.com Mon Mar 5 01:44:06 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 5 Mar 2012 13:14:06 +0530 Subject: which one a Technical Support or Help Desk In-Reply-To: <155956.1330885561@turing-police.cc.vt.edu> References: <155956.1330885561@turing-police.cc.vt.edu> Message-ID: At least to the extent of providing clear, auditable metrics on change management and SLA, making sure all support and ops cases are actually covered (again, so it can be subject to an audit) etc ... You probably fulfil every single requirement of ITIL already, except for the piles of paperwork required to pass an ISO2700x audit :) On Sun, Mar 4, 2012 at 11:56 PM, wrote: > > "IT services must be aligned with the requirements"??!? ?I've always wondered > how companies stay in business if they're so dysfunctional that they need a framework > to recognize stuff like that. ?Does deploying this stuff in functional organizations > actually work? ?Does it do any good? -- Suresh Ramasubramanian (ops.lists at gmail.com) From leigh.porter at ukbroadband.com Mon Mar 5 04:59:28 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 5 Mar 2012 10:59:28 +0000 Subject: Falling for address collection (Was: Evil Bit and Spread Spectrum IP Addressing - NANOG Source Address Shaping) In-Reply-To: <20120305032423.GA73452@DataIX.net> References: <20120305032423.GA73452@DataIX.net> Message-ID: I'm sorry but I have failed to understand the grammar of these bizarre posts. Is it just me or do they actually make very little sense? What is perhaps scary is that I know somebody who talks just like that (i.e. makes little sense) and I really thought it may be them... It isn't because they died last year, but still, who knows.. -- Leigh Porter > -----Original Message----- > From: Jason Hellenthal [mailto:jhellenthal at dataix.net] > Sent: 05 March 2012 03:27 > To: nanog at nanog.org > Subject: Falling for address collection (Was: Evil Bit and Spread > Spectrum IP Addressing - NANOG Source Address Shaping) > > > Why does everyone keep falling for the same address collector ? ;-) > > -- LoL > > On Sun, Mar 04, 2012 at 10:22:15AM -0600, Guru NANOG wrote: > > Common Misconception: One additional bit of IPv4 Addressing will > solve > > world hunger > > > > The Evil Bit (or spare unused bit) can be used to store (restore) one > > bit > > > > The Left-Most bit of the 32-bit Source Address Field can be SET to > > Zero no matter what the original value. The Evil bit can be set IFF > > the Left-Most bit is **changed**. > > > > Setting the Left-Most bit to zero **folds** this table in half. > > http://www.iana.org/assignments/ipv4-address-space/ipv4-address- > space. > > txt > > > > Setting the Left-Most bit to ONE would move return traffic to the > > upper half of the Spectrum which has vast quantities of unused /8s > > > > Wide-spread consensus shows that TWO bits can work. Three bits folds > > the table to 1/8th. > > Governments want a 4-bit Return Prefix to their Super-Hubs for > > IPv6-like intercept. > > > > The U.S.FCC is expected to issue the regulations on how Spread > > Spectrum Source Address Shaping will work in their licensed CPE > > wireless devices. There are 160-bits in the deprecated header so > there > > are many ways to go. > > > > One-Way Broadcast IP Addressing is now available. The Source Address > > Field is used for the second half of the 64-bit Destination Address. > > The DF (Did > > Flip) bit near the Evil > > Bit is used to note the two halves of the Destination Address have > > been *flipped*. > > NANOGers simply route 32 and then 32 after the flip based only on the > > Destination Field. > > There is no Source Address, only a channel (port). > > > > Keywords: WRT DNSMASQ Tomato WIFI Linux CPE > > -- > ;s =; > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud > service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From jra at baylink.com Mon Mar 5 08:17:03 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 5 Mar 2012 09:17:03 -0500 (EST) Subject: Falling for address collection (Was: Evil Bit and Spread Spectrum IP Addressing - NANOG Source Address Shaping) In-Reply-To: Message-ID: <9341681.2999.1330957023408.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Leigh Porter" > I'm sorry but I have failed to understand the grammar of these bizarre > posts. Is it just me or do they actually make very little sense? UNaltered REPRODUCTION and DISSEMINATION of this IMPORTANT information is strongly ENCOURAGED. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From carlosm3011 at gmail.com Mon Mar 5 10:08:39 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Mon, 05 Mar 2012 14:08:39 -0200 Subject: Programmers with network engineering skills In-Reply-To: References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> Message-ID: <4F54E507.4070204@gmail.com> Never said it was *perfect*. But you probably haven't a good (in CV terms at least) prorgrammer assigned to you but didn't know the difference between a TCP port and an IP protocol number. Or the difference between an Ethernet and an IP address. For me at least (and I grant you that everyone's mileage may vary), it has been a lot easier to teach networkers to program than the other way around. I remember (not very fondly) the time when I was assigned to the team which was going to write a DNS provisioning system, which was going to be used by clients to get x.tld domains, and which had to periodically generate the zone. A team of programmers, fully into the maintainability, lifecycle, corporate IT thing was created. They didn't know what a DNS zone was, or a SOA record, or a CNAME record for that matter. The project failed before I could bring the matter of AAAA records up. Several tens of thousands of dollars were spent on a failed project that could have been saved by a different choice of programmers. The same problem was solved some two years later by a team composed mainly of network engineers with one or two corporate IT programmers who were in charge of ensuring lifecycle and integration with business systems. And a programming engineer (even if he/she is by default an electrical/network engineer) is a far cry from a script kiddie. Sorry to differ on that. cheers! Carlos On 3/2/12 8:35 PM, Randy Bush wrote: >> In my experience the path of least resistance is to get a junior >> network engineer and mentor he/she into improving his/hers programming >> skills than go the other way around. > and then the organization pays forever to maintain the crap code while > the kiddie learned to program. right. brilliant. > > Always code as if the guy who ends up maintaining your code will be a > violent psychopath who knows where you live. -- Martin Golding > > randy From dan at danweeks.net Mon Mar 5 10:32:53 2012 From: dan at danweeks.net (Dan Weeks) Date: Mon, 05 Mar 2012 11:32:53 -0500 Subject: IBM/BNT G8264, VMready, and OpenFlow Message-ID: <4F54EAB5.20608@danweeks.net> My organization is looking into various software-defined switches for some dynamic firewall and virtualization applications. Can anyone here speak about experience with IBM/BNT VMready or OpenFlow or specifically about the BNT G8264? Any feedback would be greatly appreciated. -- Daniel M. Weeks From khelms at ispalliance.net Mon Mar 5 11:53:34 2012 From: khelms at ispalliance.net (Scott Helms) Date: Mon, 05 Mar 2012 12:53:34 -0500 Subject: Programmers with network engineering skills In-Reply-To: <4F54E507.4070204@gmail.com> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> Message-ID: <4F54FD9E.2020606@ispalliance.net> I've played on both sides of the fence of this one, but I think the key piece is that you have to get enough software engineering for your tool to fit the life cycle it needs to follow and enough domain specific knowledge to for the tool to do what it exists to do. If you lack *either* of those you're going to suffer either through a tool that doesn't do what its supposed to or a tool that does everything it should right *now* but can't be efficiently expanded when the project scope suddenly expands. The real challenge is understanding what the scope of your project is and what it will likely be in ~4 years. If its not going to change much then the need for professional software engineering methodologies & practices is much lower than if you're going to have to add new features each quarter. Your target audience also has a big impact on what you need to do. Most internal projects have little need for a professional UI designer, but if you have a project that's going to touch thousands of people using a range of PC's and other devices you had better spend a lot of time on UI. tl;dr I don't think there is a *right* answer to be found because it depends on the project. BTW, just replying to Carlos in general not in specific. On 3/5/2012 11:08 AM, Carlos Martinez-Cagnazzo wrote: > Never said it was *perfect*. But you probably haven't a good (in CV > terms at least) prorgrammer assigned to you but didn't know the > difference between a TCP port and an IP protocol number. Or the > difference between an Ethernet and an IP address. > > For me at least (and I grant you that everyone's mileage may vary), it > has been a lot easier to teach networkers to program than the other way > around. > > I remember (not very fondly) the time when I was assigned to the team > which was going to write a DNS provisioning system, which was going to > be used by clients to get x.tld domains, and which had to periodically > generate the zone. > > A team of programmers, fully into the maintainability, lifecycle, > corporate IT thing was created. They didn't know what a DNS zone was, or > a SOA record, or a CNAME record for that matter. The project failed > before I could bring the matter of AAAA records up. Several tens of > thousands of dollars were spent on a failed project that could have been > saved by a different choice of programmers. > > The same problem was solved some two years later by a team composed > mainly of network engineers with one or two corporate IT programmers who > were in charge of ensuring lifecycle and integration with business systems. > > And a programming engineer (even if he/she is by default an > electrical/network engineer) is a far cry from a script kiddie. Sorry to > differ on that. > > cheers! > > Carlos > > On 3/2/12 8:35 PM, Randy Bush wrote: >>> In my experience the path of least resistance is to get a junior >>> network engineer and mentor he/she into improving his/hers programming >>> skills than go the other way around. >> and then the organization pays forever to maintain the crap code while >> the kiddie learned to program. right. brilliant. >> >> Always code as if the guy who ends up maintaining your code will be a >> violent psychopath who knows where you live. -- Martin Golding >> >> randy > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From manager at monmouth.com Mon Mar 5 12:46:15 2012 From: manager at monmouth.com (Mark Stevens) Date: Mon, 05 Mar 2012 13:46:15 -0500 Subject: Global Naps? In-Reply-To: <4F54FD9E.2020606@ispalliance.net> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> Message-ID: <4F5509F7.6060508@monmouth.com> Global NAPs seemingly shutdown all tandem services last week and it is causing major congestion issues with routing calls. Anyone have more information on this mess as it seems to be in it's 4th day? Thanks Mark Stevens From alex at corp.nac.net Mon Mar 5 13:14:12 2012 From: alex at corp.nac.net (Alex Rubenstein) Date: Mon, 5 Mar 2012 14:14:12 -0500 Subject: Global Naps? Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB813BA778D4A@EXCHMBX.hq.nac.net> Bankruptcy liquidation. ----- Original Message ----- From: Mark Stevens To: nanog at nanog.org Sent: Mon Mar 05 13:46:15 2012 Subject: Global Naps? Global NAPs seemingly shutdown all tandem services last week and it is causing major congestion issues with routing calls. Anyone have more information on this mess as it seems to be in it's 4th day? Thanks Mark Stevens From carlosm3011 at gmail.com Mon Mar 5 13:27:05 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Mon, 05 Mar 2012 17:27:05 -0200 Subject: Programmers with network engineering skills In-Reply-To: <4F54FD9E.2020606@ispalliance.net> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> Message-ID: <4F551389.4070209@gmail.com> Scott, I fully agree with you. In fact, I was just commenting on *my* experiences and never implied that they would / should apply the same for everyone. cheers! Carlos On 3/5/12 3:53 PM, Scott Helms wrote: > I've played on both sides of the fence of this one, but I think the > key piece is that you have to get enough software engineering for your > tool to fit the life cycle it needs to follow and enough domain > specific knowledge to for the tool to do what it exists to do. If you > lack *either* of those you're going to suffer either through a tool > that doesn't do what its supposed to or a tool that does everything it > should right *now* but can't be efficiently expanded when the project > scope suddenly expands. The real challenge is understanding what the > scope of your project is and what it will likely be in ~4 years. If > its not going to change much then the need for professional software > engineering methodologies & practices is much lower than if you're > going to have to add new features each quarter. Your target audience > also has a big impact on what you need to do. Most internal projects > have little need for a professional UI designer, but if you have a > project that's going to touch thousands of people using a range of > PC's and other devices you had better spend a lot of time on UI. > > tl;dr I don't think there is a *right* answer to be found because it > depends on the project. > > > BTW, just replying to Carlos in general not in specific. > > On 3/5/2012 11:08 AM, Carlos Martinez-Cagnazzo wrote: >> Never said it was *perfect*. But you probably haven't a good (in CV >> terms at least) prorgrammer assigned to you but didn't know the >> difference between a TCP port and an IP protocol number. Or the >> difference between an Ethernet and an IP address. >> >> For me at least (and I grant you that everyone's mileage may vary), it >> has been a lot easier to teach networkers to program than the other way >> around. >> >> I remember (not very fondly) the time when I was assigned to the team >> which was going to write a DNS provisioning system, which was going to >> be used by clients to get x.tld domains, and which had to periodically >> generate the zone. >> >> A team of programmers, fully into the maintainability, lifecycle, >> corporate IT thing was created. They didn't know what a DNS zone was, or >> a SOA record, or a CNAME record for that matter. The project failed >> before I could bring the matter of AAAA records up. Several tens of >> thousands of dollars were spent on a failed project that could have been >> saved by a different choice of programmers. >> >> The same problem was solved some two years later by a team composed >> mainly of network engineers with one or two corporate IT programmers who >> were in charge of ensuring lifecycle and integration with business >> systems. >> >> And a programming engineer (even if he/she is by default an >> electrical/network engineer) is a far cry from a script kiddie. Sorry to >> differ on that. >> >> cheers! >> >> Carlos >> >> On 3/2/12 8:35 PM, Randy Bush wrote: >>>> In my experience the path of least resistance is to get a junior >>>> network engineer and mentor he/she into improving his/hers programming >>>> skills than go the other way around. >>> and then the organization pays forever to maintain the crap code while >>> the kiddie learned to program. right. brilliant. >>> >>> Always code as if the guy who ends up maintaining your code will be a >>> violent psychopath who knows where you live. -- Martin Golding >>> >>> randy >> > > From manager at monmouth.com Mon Mar 5 13:43:23 2012 From: manager at monmouth.com (Mark Stevens) Date: Mon, 05 Mar 2012 14:43:23 -0500 Subject: Global Naps? In-Reply-To: References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <4F5509F7.6060508@monmouth.com> Message-ID: <4F55175B.1080208@monmouth.com> Seems some carriers ignored the fact GNAPs was shutting down and are still trying route calls to them which then causes a serious post dial delay while route advancing is taking place. I hope some carriers read this thread and check their routing. Mark On 3/5/2012 1:56 PM, Bill Woodcock wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > On Mar 5, 2012, at 10:46 AM, Mark Stevens wrote: > >> Global NAPs seemingly shutdown all tandem services last week and it is causing major congestion issues with routing calls. Anyone have more information on this mess as it seems to be in it's 4th day? >> >> Thanks >> >> Mark Stevens > Mark: > > I'm not able to find anything with a google search on "GNAPS bankruptcy" but my understanding was that all equipment was to be shut down and offered for sale at the end of February. We had a router and some servers at the Boston IX, but they were inside a GNAPS cage, and we were told they'd be auctioned off if we didn't get them out by the end of February. > > In the absence of anything more concrete, please don't attribute this to me. > > Thanks, > > -Bill > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJPVQxHAAoJEG+kcEsoi3+HYMQQAKnbKUuh/0+riq5AyDlvuDHW > ofqI4+256YuMV26uWC7s9h9UueJ4oM8AhpaJknjTE1ojlXQbCsIQTgYL7ugIY0gI > 4VICnJRvCxRL3MASwo8i736AzPJvOGb212oTgZDmY7aoSmV42ZfwgiYApU79UUkK > vCYsVtkWosUslkwOY7g6kL7ct7GSy3MCK3JImPXTc8gpYfaK+DDvWkVteIxfuTYN > yzBAfl2WmEwaQI6jNTry+G3lkrj+q3Sf/nNcRCZDpX3C8h8eyifKoL6t94lT2/L7 > orWDOVAhJ0Jpuo7z3mSsEpZ2kw5Xr+atR9uICTm5DwKqmiJuR/2FvI+1PaGouiB8 > mODDAtvk4CUM03NBKBx6QV3jeoeZhqvLHgbb63eaWQDjxlW9E13Tyq5XRyllL/4+ > g+DWspSWZCknJqr0izVGPXdaFm4BHLXrb+zG3gxbdYdQ63DC5UFzy6z52zgQqkhI > YXF5/QY6eXjzUPoo4FA3lRB83QsWoTFtOSLGT0DF07UeQiTYNMHD7G480MJ4vio7 > KfmHqVgoGfXUS/LHYETnE10uzfd0TPuO2KQzk35MddOYfOkTYRMjQkkQx87kHS/T > 8kgQZoyowmpZkxQAOZZDEto8q9QeQO8iWBetRO1uP1ylJAGnami598B0bidpwb/i > qCW3X+jYSYYxE4ZmYgj8 > =XJwh > -----END PGP SIGNATURE----- > > > From owen at delong.com Mon Mar 5 14:29:36 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 5 Mar 2012 12:29:36 -0800 Subject: Programmers with network engineering skills In-Reply-To: <4F54FD9E.2020606@ispalliance.net> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> Message-ID: <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> Given my experience to date with the assumptions made by programers about networking in the following: Apps (iOS apps, Droid apps, etc.) Consumer Electronics Microcontrollers Home Routers I have to say that the strategy being used to date, whichever one it is, is not working. I will also note that the erroneous assumptions, incorrect behaviors, and other problems I have encountered with these items are indicative of coders that almost learned networking more than of networkers that almost learned software development. Owen On Mar 5, 2012, at 9:53 AM, Scott Helms wrote: > I've played on both sides of the fence of this one, but I think the key piece is that you have to get enough software engineering for your tool to fit the life cycle it needs to follow and enough domain specific knowledge to for the tool to do what it exists to do. If you lack *either* of those you're going to suffer either through a tool that doesn't do what its supposed to or a tool that does everything it should right *now* but can't be efficiently expanded when the project scope suddenly expands. The real challenge is understanding what the scope of your project is and what it will likely be in ~4 years. If its not going to change much then the need for professional software engineering methodologies & practices is much lower than if you're going to have to add new features each quarter. Your target audience also has a big impact on what you need to do. Most internal projects have little need for a professional UI designer, but if you have a project that's going to touch thousands of people using a range of PC's and other devices you had better spend a lot of time on UI. > > tl;dr I don't think there is a *right* answer to be found because it depends on the project. > > > BTW, just replying to Carlos in general not in specific. > > On 3/5/2012 11:08 AM, Carlos Martinez-Cagnazzo wrote: >> Never said it was *perfect*. But you probably haven't a good (in CV >> terms at least) prorgrammer assigned to you but didn't know the >> difference between a TCP port and an IP protocol number. Or the >> difference between an Ethernet and an IP address. >> >> For me at least (and I grant you that everyone's mileage may vary), it >> has been a lot easier to teach networkers to program than the other way >> around. >> >> I remember (not very fondly) the time when I was assigned to the team >> which was going to write a DNS provisioning system, which was going to >> be used by clients to get x.tld domains, and which had to periodically >> generate the zone. >> >> A team of programmers, fully into the maintainability, lifecycle, >> corporate IT thing was created. They didn't know what a DNS zone was, or >> a SOA record, or a CNAME record for that matter. The project failed >> before I could bring the matter of AAAA records up. Several tens of >> thousands of dollars were spent on a failed project that could have been >> saved by a different choice of programmers. >> >> The same problem was solved some two years later by a team composed >> mainly of network engineers with one or two corporate IT programmers who >> were in charge of ensuring lifecycle and integration with business systems. >> >> And a programming engineer (even if he/she is by default an >> electrical/network engineer) is a far cry from a script kiddie. Sorry to >> differ on that. >> >> cheers! >> >> Carlos >> >> On 3/2/12 8:35 PM, Randy Bush wrote: >>>> In my experience the path of least resistance is to get a junior >>>> network engineer and mentor he/she into improving his/hers programming >>>> skills than go the other way around. >>> and then the organization pays forever to maintain the crap code while >>> the kiddie learned to program. right. brilliant. >>> >>> Always code as if the guy who ends up maintaining your code will be a >>> violent psychopath who knows where you live. -- Martin Golding >>> >>> randy >> > > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > From keegan.holley at sungard.com Mon Mar 5 14:32:44 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Mon, 5 Mar 2012 15:32:44 -0500 Subject: Programmers with network engineering skills In-Reply-To: References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> Message-ID: 2012/3/2 Randy Bush > >>> In my experience the path of least resistance is to get a junior > >>> network engineer and mentor he/she into improving his/hers programming > >>> skills than go the other way around. > >> > >> and then the organization pays forever to maintain the crap code while > >> the kiddie learned to program. right. brilliant. > > > > +1 Although, I've seen the opposite where a brilliant developer writes > > wonderful code, leaves and you are left with a similarly difficult > > situation since there are no more programmers in the department and no > > brilliant developers willing to do programming that requires in depth > > knowledge of networking. > > that was not a brilliant developer. that was a clever developer. > > Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it. -- Brian W. Kernighan > > It's not so much that the code was too clever to troubleshoot, just that we were fresh out of developers. > and, if the department was not willing to invest in long-term software > capability, then they were foolish to enter the game in the first place. > If I said this was the first time I saw a large corporation do something foolish I'd be lying... I was consulting on a project that created a need to modify the existing code. I probably could have tackled it but I have a day job and didn't want to become the "house developer". Watching people try to explain to upper management why their band of merry router jockeys should have a developer was interesting. Sometimes it comes down to convincing the business side to invest time and money into creating the development position for code that hasn't been touched in years.. If you just look at the technical bits, the need is usually obvious. > > go find an open-source solution or buy commercial. and if none fit your > needs, and you are not willing to invest in softdev, then you have a > problem in your business model. > Agreed... but I was consulting. My business model was satisfied when I walked through the door. I'm not saying there shouldn't be developers on a team of network engineers, it's was just interesting to see what happens when the one-eye'd man leaves. From keegan.holley at sungard.com Mon Mar 5 14:40:26 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Mon, 5 Mar 2012 15:40:26 -0500 Subject: Programmers with network engineering skills In-Reply-To: <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> Message-ID: 2012/3/5 Owen DeLong > Given my experience to date with the assumptions made by programers about > networking in the following: > > Apps (iOS apps, Droid apps, etc.) > Consumer Electronics > Microcontrollers > Home Routers > > I have to say that the strategy being used to date, whichever one it is, > is not working. I will also note that the erroneous assumptions, incorrect > behaviors, and other problems I have encountered with these items are > indicative of coders that almost learned networking more than of networkers > that almost learned software development. > > I think it comes down to economics mostly. Most development jobs either do not require knowledge of networking or do not enforce the requirement. There are plenty of jobs where developers do not need to know networking so when it's a sticking point it just becomes harder to find someone that fits. This doesn't give the average developer much incentive to learn networking, even if it leads to buggy or incorrectly written code. On the other hand a senior net-eng that can code is worth is weight in gold, especially if he can spit out palatable webUI's for everything. From khelms at ispalliance.net Mon Mar 5 14:51:33 2012 From: khelms at ispalliance.net (Scott Helms) Date: Mon, 05 Mar 2012 15:51:33 -0500 Subject: Programmers with network engineering skills In-Reply-To: <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> Message-ID: <4F552755.2050102@ispalliance.net> Owen, I'd say that everyone's PoV on this is going to be experience driven. I've seen both approaches work (and both fail) and IMO the determining factor was matching the "right" approach with the project. I don't believe that you can develop a large scale project (large scale being a team of 12 or more full time developers working for more than a year on the same project) with people who primarily want to be network engineers. Its not a matter of skill set so much as it as what interests each group and they are very different. Today I manage network engineers, Unix/Linux System Administrators, and Java (and Flex) developers and while there are tasks I can move from one group to another there is usually a best home for a specific project. Where I usually run into trouble is when I put a project into a non-optimal group usually because of deadlines. On 3/5/2012 3:29 PM, Owen DeLong wrote: > Given my experience to date with the assumptions made by programers about networking in the following: > > Apps (iOS apps, Droid apps, etc.) > Consumer Electronics > Microcontrollers > Home Routers > > I have to say that the strategy being used to date, whichever one it is, is not working. I will also note that the erroneous assumptions, incorrect behaviors, and other problems I have encountered with these items are indicative of coders that almost learned networking more than of networkers that almost learned software development. > > Owen > > On Mar 5, 2012, at 9:53 AM, Scott Helms wrote: > >> I've played on both sides of the fence of this one, but I think the key piece is that you have to get enough software engineering for your tool to fit the life cycle it needs to follow and enough domain specific knowledge to for the tool to do what it exists to do. If you lack *either* of those you're going to suffer either through a tool that doesn't do what its supposed to or a tool that does everything it should right *now* but can't be efficiently expanded when the project scope suddenly expands. The real challenge is understanding what the scope of your project is and what it will likely be in ~4 years. If its not going to change much then the need for professional software engineering methodologies& practices is much lower than if you're going to have to add new features each quarter. Your target audience also has a big impact on what you need to do. Most internal projects have little need for a professional UI designer, but if you have a project that's going to touch thousands of people using a range of PC's and other devices you had better spend a lot of time on UI. >> >> tl;dr I don't think there is a *right* answer to be found because it depends on the project. >> >> >> BTW, just replying to Carlos in general not in specific. >> >> On 3/5/2012 11:08 AM, Carlos Martinez-Cagnazzo wrote: >>> Never said it was *perfect*. But you probably haven't a good (in CV >>> terms at least) prorgrammer assigned to you but didn't know the >>> difference between a TCP port and an IP protocol number. Or the >>> difference between an Ethernet and an IP address. >>> >>> For me at least (and I grant you that everyone's mileage may vary), it >>> has been a lot easier to teach networkers to program than the other way >>> around. >>> >>> I remember (not very fondly) the time when I was assigned to the team >>> which was going to write a DNS provisioning system, which was going to >>> be used by clients to get x.tld domains, and which had to periodically >>> generate the zone. >>> >>> A team of programmers, fully into the maintainability, lifecycle, >>> corporate IT thing was created. They didn't know what a DNS zone was, or >>> a SOA record, or a CNAME record for that matter. The project failed >>> before I could bring the matter of AAAA records up. Several tens of >>> thousands of dollars were spent on a failed project that could have been >>> saved by a different choice of programmers. >>> >>> The same problem was solved some two years later by a team composed >>> mainly of network engineers with one or two corporate IT programmers who >>> were in charge of ensuring lifecycle and integration with business systems. >>> >>> And a programming engineer (even if he/she is by default an >>> electrical/network engineer) is a far cry from a script kiddie. Sorry to >>> differ on that. >>> >>> cheers! >>> >>> Carlos >>> >>> On 3/2/12 8:35 PM, Randy Bush wrote: >>>>> In my experience the path of least resistance is to get a junior >>>>> network engineer and mentor he/she into improving his/hers programming >>>>> skills than go the other way around. >>>> and then the organization pays forever to maintain the crap code while >>>> the kiddie learned to program. right. brilliant. >>>> >>>> Always code as if the guy who ends up maintaining your code will be a >>>> violent psychopath who knows where you live. -- Martin Golding >>>> >>>> randy >> >> -- >> Scott Helms >> Vice President of Technology >> ISP Alliance, Inc. DBA ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From goemon at anime.net Mon Mar 5 15:26:24 2012 From: goemon at anime.net (goemon at anime.net) Date: Mon, 5 Mar 2012 13:26:24 -0800 (PST) Subject: Clueful road runner contact? In-Reply-To: <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com> References: <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx> <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com> <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com> Message-ID: Anyone have a clueful road runner contact? -Dan From jra at baylink.com Mon Mar 5 15:40:02 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 5 Mar 2012 16:40:02 -0500 (EST) Subject: POLL: Network and Service Status Pages In-Reply-To: <28851707.3139.1330982650933.JavaMail.root@benjamin.baylink.com> Message-ID: <31959529.3147.1330983602289.JavaMail.root@benjamin.baylink.com> Every six months or so, I poll the mailing list for links to your favorite status pages for carriers, web services, and the like, to add to the Dashboard page at http://www.outages.org If you have any you like, which you know are still working, and are publicly accessible, that you'd like posted there for everyone's benefit, please mail them to me *off-list*, and I'll double-check them, and post them ASAP. Thanks, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From bhmccie at gmail.com Mon Mar 5 15:49:37 2012 From: bhmccie at gmail.com (-Hammer-) Date: Mon, 05 Mar 2012 15:49:37 -0600 Subject: Clueful road runner contact? In-Reply-To: References: <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx> <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com> <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com> Message-ID: <4F5534F1.2080702@gmail.com> Wile E Coyote knows all about him. Sorry, couldn't resist. -Hammer- "I was a normal American nerd" -Jack Herer On 3/5/2012 3:26 PM, goemon at anime.net wrote: > Anyone have a clueful road runner contact? > > -Dan > > From dougb at dougbarton.us Mon Mar 5 17:31:57 2012 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 05 Mar 2012 17:31:57 -0600 Subject: Global Naps? In-Reply-To: <4F5509F7.6060508@monmouth.com> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <4F5509F7.6060508@monmouth.com> Message-ID: <4F554CED.2070609@dougbarton.us> FYI, picking an existing message, hitting reply, and then changing the subject line is not a good way to start a new thread. It causes your message to appear in an odd location for those of us who use threaded mail readers, and may cause your message to be ignored altogether. hth, Doug From owen at delong.com Mon Mar 5 17:46:11 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 5 Mar 2012 15:46:11 -0800 Subject: Programmers with network engineering skills In-Reply-To: <4F552755.2050102@ispalliance.net> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> <4F552755.2050102@ispalliance.net> Message-ID: <4A83E8A0-E655-4C92-95C9-E0C26DBB218F@delong.com> On Mar 5, 2012, at 12:51 PM, Scott Helms wrote: > Owen, > > I'd say that everyone's PoV on this is going to be experience driven. I've seen both approaches work (and both fail) and IMO the determining factor was matching the "right" approach with the project. I don't believe that you can develop a large scale project (large scale being a team of 12 or more full time developers working for more than a year on the same project) with people who primarily want to be network engineers. Its not a matter of skill set so much as it as what interests each group and they are very different. > I completely agree. In fact, such an effort is likely to fail in a rather spectacular and obvious manner if anyone were even to attempt it. I think everyone pretty much realizes the truth of this statement intuitively. However, the bigger problem (from my experience-driven POV) is that it is not so intuitively obvious that developing a network-based product using a team consisting entirely of developers who view the network as an unnecessarily complicated serial port (which, really is about the approach most developers seem to take to networking) is also doomed to a certain amount of failure. Usually that comes in the form of products that make invalid assumptions/assertions about the environment(s) in which they will operate. For example, most apps designed to work with consumer electronics make the assumption that everything in a given household will be within the same broadcast domain as the device on which the app is running. However, in my household, the wireless network and the wired network are in separate broadcast domains. The consumer electronics are by and large on the wired network. The iPad, iPhone, and other portable network-capable electronics are not. Faced with a support request regarding this problem, the universal answer has been to insist that this assumption is correct and that I should work with my router vendor to correct the problems in my network. > Today I manage network engineers, Unix/Linux System Administrators, and Java (and Flex) developers and while there are tasks I can move from one group to another there is usually a best home for a specific project. Where I usually run into trouble is when I put a project into a non-optimal group usually because of deadlines. > Of course. But when the task crosses the skill-sets of the different groups, it's not always obvious which group is optimal or how to go about merging the correct blend of talents from each. Owen > > On 3/5/2012 3:29 PM, Owen DeLong wrote: >> Given my experience to date with the assumptions made by programers about networking in the following: >> >> Apps (iOS apps, Droid apps, etc.) >> Consumer Electronics >> Microcontrollers >> Home Routers >> >> I have to say that the strategy being used to date, whichever one it is, is not working. I will also note that the erroneous assumptions, incorrect behaviors, and other problems I have encountered with these items are indicative of coders that almost learned networking more than of networkers that almost learned software development. >> >> Owen >> >> On Mar 5, 2012, at 9:53 AM, Scott Helms wrote: >> >>> I've played on both sides of the fence of this one, but I think the key piece is that you have to get enough software engineering for your tool to fit the life cycle it needs to follow and enough domain specific knowledge to for the tool to do what it exists to do. If you lack *either* of those you're going to suffer either through a tool that doesn't do what its supposed to or a tool that does everything it should right *now* but can't be efficiently expanded when the project scope suddenly expands. The real challenge is understanding what the scope of your project is and what it will likely be in ~4 years. If its not going to change much then the need for professional software engineering methodologies& practices is much lower than if you're going to have to add new features each quarter. Your target audience also has a big impact on what you need to do. Most internal projects have little need for a professional UI designer, but if you have a project that's going to touch thousands of people using a range of PC's and other devices you had better spend a lot of time on UI. >>> >>> tl;dr I don't think there is a *right* answer to be found because it depends on the project. >>> >>> >>> BTW, just replying to Carlos in general not in specific. >>> >>> On 3/5/2012 11:08 AM, Carlos Martinez-Cagnazzo wrote: >>>> Never said it was *perfect*. But you probably haven't a good (in CV >>>> terms at least) prorgrammer assigned to you but didn't know the >>>> difference between a TCP port and an IP protocol number. Or the >>>> difference between an Ethernet and an IP address. >>>> >>>> For me at least (and I grant you that everyone's mileage may vary), it >>>> has been a lot easier to teach networkers to program than the other way >>>> around. >>>> >>>> I remember (not very fondly) the time when I was assigned to the team >>>> which was going to write a DNS provisioning system, which was going to >>>> be used by clients to get x.tld domains, and which had to periodically >>>> generate the zone. >>>> >>>> A team of programmers, fully into the maintainability, lifecycle, >>>> corporate IT thing was created. They didn't know what a DNS zone was, or >>>> a SOA record, or a CNAME record for that matter. The project failed >>>> before I could bring the matter of AAAA records up. Several tens of >>>> thousands of dollars were spent on a failed project that could have been >>>> saved by a different choice of programmers. >>>> >>>> The same problem was solved some two years later by a team composed >>>> mainly of network engineers with one or two corporate IT programmers who >>>> were in charge of ensuring lifecycle and integration with business systems. >>>> >>>> And a programming engineer (even if he/she is by default an >>>> electrical/network engineer) is a far cry from a script kiddie. Sorry to >>>> differ on that. >>>> >>>> cheers! >>>> >>>> Carlos >>>> >>>> On 3/2/12 8:35 PM, Randy Bush wrote: >>>>>> In my experience the path of least resistance is to get a junior >>>>>> network engineer and mentor he/she into improving his/hers programming >>>>>> skills than go the other way around. >>>>> and then the organization pays forever to maintain the crap code while >>>>> the kiddie learned to program. right. brilliant. >>>>> >>>>> Always code as if the guy who ends up maintaining your code will be a >>>>> violent psychopath who knows where you live. -- Martin Golding >>>>> >>>>> randy >>> >>> -- >>> Scott Helms >>> Vice President of Technology >>> ISP Alliance, Inc. DBA ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >>> >> > > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > From bill at herrin.us Mon Mar 5 17:57:00 2012 From: bill at herrin.us (William Herrin) Date: Mon, 5 Mar 2012 18:57:00 -0500 Subject: Programmers with network engineering skills In-Reply-To: <4A83E8A0-E655-4C92-95C9-E0C26DBB218F@delong.com> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> <4F552755.2050102@ispalliance.net> <4A83E8A0-E655-4C92-95C9-E0C26DBB218F@delong.com> Message-ID: On Mon, Mar 5, 2012 at 6:46 PM, Owen DeLong wrote: > However, the bigger problem (from my experience-driven >POV) is that it is not so intuitively obvious that developing >a network-based product using a team consisting entirely >of developers who view the network as an unnecessarily >complicated serial port (which, really is about the approach >most developers seem to take to networking) is also >doomed to a certain amount of failure. Owen, Surely you don't mean to suggest that having someone with domain knowledge develop a set of requirements and then kick it over the wall to folks who know how to program but have no domain knowledge is a recipe for failure? That having linchpin members of the team with core competencies in both software development -and- the product-relevant knowledge domains is critical to success? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike at mtcc.com Mon Mar 5 18:01:35 2012 From: mike at mtcc.com (Michael Thomas) Date: Mon, 05 Mar 2012 16:01:35 -0800 Subject: Programmers with network engineering skills In-Reply-To: <4A83E8A0-E655-4C92-95C9-E0C26DBB218F@delong.com> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> <4F552755.2050102@ispalliance.net> <4A83E8A0-E655-4C92-95C9-E0C26DBB218F@delong.com> Message-ID: <4F5553DF.3040009@mtcc.com> On 03/05/2012 03:46 PM, Owen DeLong wrote: > However, the bigger problem (from my experience-driven POV) is that it is not so intuitively obvious that developing a network-based product using a team consisting entirely of developers who view the network as an unnecessarily complicated serial port Here's a thought: if you want network clueful programmers, do what everybody else does when they need a XXX clueful programmer: hire them fresh and mold them. Programmers don't come with built in skills for the vast array of possibilities, so they have to learn it *somewhere*. Mike, networking is no different than any other specialized area, imo From streiner at cluebyfour.org Mon Mar 5 18:09:15 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 5 Mar 2012 19:09:15 -0500 (EST) Subject: Programmers with network engineering skills In-Reply-To: <4A83E8A0-E655-4C92-95C9-E0C26DBB218F@delong.com> References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> <4F552755.2050102@ispalliance.net> <4A83E8A0-E655-4C92-95C9-E0C26DBB218F@delong.com> Message-ID: On Mon, 5 Mar 2012, Owen DeLong wrote: > However, the bigger problem (from my experience-driven POV) is that it > is not so intuitively obvious that developing a network-based product > using a team consisting entirely of developers who view the network as > an unnecessarily complicated serial port (which, really is about the > approach most developers seem to take to networking) is also doomed to a > certain amount of failure. I'd also add that many software developers are either ignorant of how protocols operate, or they take a "meh, it's close enough, XYZ gets through, doesn't it?" approach. That's not to say that those developers aren't good at what they do - they just might not be accustomed to working the way that people with a more network-centric (or task-agnostic) view would likely choose to work. This would include things like digesting RFCs/standards/BCPs, boiling those down to finite-state machines and then writing code to execute the machine. Admittedly we (the 'network guys') don't always make it easy for them. RFCs get obsoleted by newer RFCs, but the newer RFCs might still reference items from the original RFC, etc. This can turn into developing for something that is still a moving target (DHCPv6, anyone?), which can turn into scope creep, and ultimately, frustrated developers (see: "meh, it's close enough, XYZ gets through, doesn't it?"). > For example, most apps designed to work with consumer electronics make > the assumption that everything in a given household will be within the > same broadcast domain as the device on which the app is running. > However, in my household, the wireless network and the wired network are > in separate broadcast domains. The consumer electronics are by and large > on the wired network. The iPad, iPhone, and other portable > network-capable electronics are not. Other common, but misguided assumptions (even in 2012): 1. You will be using IPv4. We have no idea what this IPv6 nonsense is. Looks complicated and scary. 2. 255.255.255.0 is the only valid netmask. 3. You are using Internet Explorer, and our web management interface has ActiveX controls that require you to do so. 4. You will be assimilated. Resistance is futile. jms From mysidia at gmail.com Mon Mar 5 20:36:41 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 5 Mar 2012 20:36:41 -0600 Subject: Programmers with network engineering skills In-Reply-To: References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> <4F552755.2050102@ispalliance.net> <4A83E8A0-E655-4C92-95C9-E0C26DBB218F@delong.com> Message-ID: On Mon, Mar 5, 2012 at 6:09 PM, Justin M. Streiner wrote: > Admittedly we (the 'network guys') don't always make it easy for them. RFCs > get obsoleted by newer RFCs, but the newer RFCs might still reference items > from the original RFC, etc. ?This can turn into developing for something Yes, this is problematic. The preferred result should be one specification for each protocol, with references only for optional extensions. > Other common, but misguided assumptions (even in 2012): > 1. You will be using IPv4. ?We have no idea what this IPv6 nonsense is. > Looks complicated and scary. > 2. 255.255.255.0 is the only valid netmask. > 3. You are using Internet Explorer, and our web management interface has > ActiveX controls that require you to do so. > 4. You will be assimilated. ?Resistance is futile. Add some additional misguided assumptions: (5) Any IP address whose first octet is 192. or 1. is a private IP. (6) Any IP address whose first octet is not 192. is not a valid LAN IP. (7) Any IP address whose last octet is .0 is an invalid IP host address (8) Any IP address whose last octet is .255 is an invalid IP host address (9) If my DNS service supports DNSSEC validation, even with no trust anchors configured, it's cool to go ahead and send all queries with the CD and DO bits set to 1 and perform no validation; it's even cooler if I only support SHA1 keys and no RSA/SHA-256. (10) Everyone enters their NTP, and AD servers by IP address, so it is best to have a textbox that only allows IPs, not hostnames. (11) Nobody actually uses SRV records, so don't bother looking for them. (12) Once a DNS lookup has been performed, the IP never changes, so it makes sense to keep this in memory until we reboot. (13) Nobody has more than 1 recursive DNS server, 1 NTP server, 1 LDAP server, 1 Syslog server, and 1 Snmp management station; so a single IP entry text box for each will suffice. (14) Nobody has more than 2 recursive DNS servers, so just allow only 2 to be entered. (15) 30 seconds per resolver seems like a good timeout for DNS queries, so no need for a configurable timeout; just try each server sequentially, make the UI hang, the user will be happy to wait 5 minutes; also make the service provided by the device temporarily stop -- users likes it when their devices stop working, to remind them to get their first DNS server back up. (16) The default gateway's IP address is always 192.168.0.1 (17) The user portion of E-mail addresses never contain special characters like "-" "+" "$" "~" "." ",", "[", "]" > jms -- -JH From ahebert at pubnix.net Mon Mar 5 21:18:58 2012 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 05 Mar 2012 22:18:58 -0500 Subject: Programmers with network engineering skills In-Reply-To: References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> <4F552755.2050102@ispalliance.net> <4A83E8A0-E655-4C92-95C9-E0C26DBB218F@delong.com> Message-ID: <4F558222.7010306@pubnix.net> About (5 thru 6) Hard to keep a straight face in front of a customer when, after assigning him a IP in our 192.172.250.0 range... ... He ask why are we NATing using private IP's. We also had plenty of experience with ppl getting confused about 16, 17. Your could add L2 Trunking and VRRP to your list... I spent many hours explaining those to no avail on many occasion. Sad. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 03/05/12 21:36, Jimmy Hess wrote: > On Mon, Mar 5, 2012 at 6:09 PM, Justin M. Streiner > wrote: > >> Admittedly we (the 'network guys') don't always make it easy for them. RFCs >> get obsoleted by newer RFCs, but the newer RFCs might still reference items >> from the original RFC, etc. This can turn into developing for something > Yes, this is problematic. The preferred result should be one specification > for each protocol, with references only for optional extensions. > >> Other common, but misguided assumptions (even in 2012): >> 1. You will be using IPv4. We have no idea what this IPv6 nonsense is. >> Looks complicated and scary. >> 2. 255.255.255.0 is the only valid netmask. >> 3. You are using Internet Explorer, and our web management interface has >> ActiveX controls that require you to do so. >> 4. You will be assimilated. Resistance is futile. > Add some additional misguided assumptions: > > (5) Any IP address whose first octet is 192. or 1. is a private IP. > (6) Any IP address whose first octet is not 192. is not a valid LAN IP. > (7) Any IP address whose last octet is .0 is an invalid IP host address > (8) Any IP address whose last octet is .255 is an invalid IP host address > > (9) If my DNS service supports DNSSEC validation, even with no trust anchors > configured, it's cool to go ahead and send all queries with > the CD and DO bits > set to 1 > and perform no validation; it's even cooler if I only > support SHA1 keys and > no RSA/SHA-256. > > (10) Everyone enters their NTP, and AD servers by IP address, so it > is best to have a textbox that only allows IPs, not hostnames. > > (11) Nobody actually uses SRV records, so don't bother looking for them. > > (12) Once a DNS lookup has been performed, the IP never changes, so > it makes sense > to keep this in memory until we reboot. > > (13) Nobody has more than 1 recursive DNS server, 1 NTP server, 1 > LDAP server, > 1 Syslog server, and 1 Snmp management station; > so a single IP entry text box for each will suffice. > > (14) Nobody has more than 2 recursive DNS servers, so just allow > only 2 to be entered. > > (15) 30 seconds per resolver seems like a good timeout for DNS queries, so no > need for a configurable timeout; just try each server > sequentially, make the > UI hang, the user will be happy to wait 5 minutes; also make > the service > provided by the device temporarily stop -- users likes it > when their devices > stop working, to remind them to get their first DNS server back up. > > (16) The default gateway's IP address is always 192.168.0.1 > (17) The user portion of E-mail addresses never contain special > characters like "-" "+" "$" "~" "." ",", "[", "]" > > > >> jms > -- > -JH > > From marka at isc.org Mon Mar 5 21:33:59 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 06 Mar 2012 14:33:59 +1100 Subject: Programmers with network engineering skills In-Reply-To: Your message of "Mon, 05 Mar 2012 20:36:41 MDT." References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> <4F552755.2050102@ispalliance.net> <4A83E8A0-E655-4C92-95C9-E0C26DBB218F@delong.com> Message-ID: <20120306033359.ACE5F1E15A48@drugs.dv.isc.org> In message , Jimmy Hess writes: > On Mon, Mar 5, 2012 at 6:09 PM, Justin M. Streiner > wrote: > > > Admittedly we (the 'network guys') don't always make it easy for them. RF= > Cs > > get obsoleted by newer RFCs, but the newer RFCs might still reference ite= > ms > > from the original RFC, etc. =A0This can turn into developing for somethin= > g > > Yes, this is problematic. The preferred result should be one specificati= > on > for each protocol, with references only for optional extensions. > > > Other common, but misguided assumptions (even in 2012): > > 1. You will be using IPv4. =A0We have no idea what this IPv6 nonsense is. > > Looks complicated and scary. > > 2. 255.255.255.0 is the only valid netmask. > > 3. You are using Internet Explorer, and our web management interface has > > ActiveX controls that require you to do so. > > 4. You will be assimilated. =A0Resistance is futile. > > Add some additional misguided assumptions: > > (5) Any IP address whose first octet is 192. or 1. is a private IP. > (6) Any IP address whose first octet is not 192. is not a valid LAN IP= > . > (7) Any IP address whose last octet is .0 is an invalid IP host addres= > s > (8) Any IP address whose last octet is .255 is an invalid IP host addre= > ss > > (9) If my DNS service supports DNSSEC validation, even with no trust an= > chors > configured, it's cool to go ahead and send all queries with > the CD and DO bits > set to 1 > and perform no validation; it's even cooler if I only > support SHA1 keys and > no RSA/SHA-256. Setting DO to 1 is fine. CD however should be zero unless CD was one on the request. > (10) Everyone enters their NTP, and AD servers by IP address, so it > is best to have a textbox that only allows IPs, not hostnames. > > (11) Nobody actually uses SRV records, so don't bother looking for them. > > (12) Once a DNS lookup has been performed, the IP never changes, so > it makes sense > to keep this in memory until we reboot. > > (13) Nobody has more than 1 recursive DNS server, 1 NTP server, 1 > LDAP server, > 1 Syslog server, and 1 Snmp management station; > so a single IP entry text box for each will suffice. > > (14) Nobody has more than 2 recursive DNS servers, so just allow > only 2 to be entered. > > (15) 30 seconds per resolver seems like a good timeout for DNS queries, s= > o no > need for a configurable timeout; just try each server > sequentially, make the > UI hang, the user will be happy to wait 5 minutes; also make > the service > provided by the device temporarily stop -- users likes it > when their devices > stop working, to remind them to get their first DNS server back up. > > (16) The default gateway's IP address is always 192.168.0.1 > (17) The user portion of E-mail addresses never contain special > characters like "-" "+" "$" "~" "." ",", "[", "]" (18) DNS doesn't use TCP so I won't forward it. (19) I only need to offer 1 DNS server though I learnt 3 from upstream and they all have different characteristics. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From randy_94108 at yahoo.com Mon Mar 5 22:38:30 2012 From: randy_94108 at yahoo.com (Randy) Date: Mon, 5 Mar 2012 20:38:30 -0800 (PST) Subject: Programmers with network engineering skills In-Reply-To: <4F558222.7010306@pubnix.net> Message-ID: <1331008710.53007.YahooMailClassic@web181109.mail.ne1.yahoo.com> if I may chime in - It is the nature of the corporate-beast which has changed. When I was starting out in the 80's and even through the early 90's network eng and sys eng went hand in hand. Today it is far more silo'd. NetEng, SysEng are very *distinct* and as a result different groups today from an operational standpoint. NetEng deals with tcp/ip(without having a clue as to how apps interact with tcp/ip (generally speaking!!) and the opposite applies to SysEng(once again, generally speaking!) So, programmers with network engineering skills and vise-versa are a rare-commodity to say the least. I don't think it has anything to do with who is *inherently* interested in network eng or sys eng. In the end: upto the "$Employer". Know what you are *really* looking for, give them the opportunity to expand their horizons and you will have found your-network engineer/programmer(you will still find people who are willing to learn - that is you greatest asset!!) ( I used to script, write; maybe a few lines of C many many years ago....as a Sr. Network Engineer. Haven't done that for years because $employer doesn't want it as a part of my job: and to $employer, I The "Sr. Network Architect"..... My 02c's worth wrt this thread. ./Randy --- On Mon, 3/5/12, Alain Hebert wrote: > From: Alain Hebert > Subject: Re: Programmers with network engineering skills > To: nanog at nanog.org > Date: Monday, March 5, 2012, 7:18 PM > ? ???About (5 > thru 6) > > ? ???Hard to keep a straight face in > front of a customer when, after > assigning him a IP in our 192.172.250.0 range... > > ? ???... He ask why are we NATing using > private IP's. > > ? ???We also had plenty of experience > with ppl getting confused about > 16, 17. > > ? ???Your could add L2 Trunking and VRRP > to your list...? I spent many > hours explaining those to no avail on many occasion. > > ? ???Sad. > > ----- > Alain Hebert? ? ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770? ???Beaconsfield, > Quebec? ???H9W 6G7 > Tel: 514-990-5911? http://www.pubnix.net? ? Fax: > 514-990-9443 > > > On 03/05/12 21:36, Jimmy Hess wrote: > > On Mon, Mar 5, 2012 at 6:09 PM, Justin M. Streiner > > ? > wrote: > > > >> Admittedly we (the 'network guys') don't always > make it easy for them. RFCs > >> get obsoleted by newer RFCs, but the newer RFCs > might still reference items > >> from the original RFC, etc.? This can turn > into developing for something > > Yes, this is problematic.? ? The preferred > result should be one specification > > for each protocol,???with references > only for optional extensions. > > > >> Other common, but misguided assumptions (even in > 2012): > >> 1. You will be using IPv4.? We have no idea > what this IPv6 nonsense is. > >> Looks complicated and scary. > >> 2. 255.255.255.0 is the only valid netmask. > >> 3. You are using Internet Explorer, and our web > management interface has > >> ActiveX controls that require you to do so. > >> 4. You will be assimilated.? Resistance is > futile. > > Add some additional misguided assumptions: > > > >? ???(5)? Any IP address whose > first octet is 192.? or? 1.? is a private > IP. > >? ???(6)? Any IP address whose > first octet is not 192.? is not a valid LAN IP. > >? ???(7)? Any IP address whose > last octet is .0? is an invalid IP host address > >? ???(8)? Any IP address whose > last octet is .255 is an invalid IP host address > > > >? ???(9)? If my DNS service > supports DNSSEC validation, even with no trust anchors > >? ? ? ? > ???configured,? it's cool to go ahead > and send all queries with > > the CD and DO bits > >? ? ? ? ???set to 1 > >? ? ? ? ???and > perform no validation;? it's even cooler if I only > > support SHA1 keys and > >? ? ? ? ???no > RSA/SHA-256. > > > >? ? (10)? Everyone enters their > NTP,? and AD servers by IP address, so it > >? ? ? ? ???is best > to? have a textbox that only allows IPs,? not > hostnames. > > > >? ? (11)? Nobody actually uses SRV > records, so don't bother looking for them. > > > >? ? (12)? Once a DNS lookup has been > performed, the IP never changes, so > > it makes sense > >? ? ? ? ???to keep > this in memory? until we reboot. > > > >? ? (13)? Nobody has more than 1 > recursive DNS server,? 1 NTP server, 1 > > LDAP server, > >? ? ? ? ???1 Syslog > server,? and? 1 Snmp management station; > >? ? ? ? ???so a > single IP entry text box? for each will suffice. > > > >? ? (14)? Nobody has more than 2 > recursive DNS servers, so just allow > > only 2 to be entered. > > > >? ? (15) 30 seconds per resolver seems like a > good timeout for DNS queries, so no > >? ? ? ? ? need for a > configurable timeout;? just? try each server > > sequentially, make the > >? ? ? ? ? UI hang, the user > will be happy to wait 5 minutes;? also make > > the service > >? ? ? ? ? provided by the > device temporarily stop --???users likes it > > when their devices > >? ? ? ? ? stop working, to > remind them to get their first DNS server back up. > > > >? ???(16)? The default > gateway's IP address is always 192.168.0.1 > >? ???(17) The user portion of E-mail > addresses never contain special > > characters like? "-" "+"? > "$"???"~"? "."? ",", "[",? > "]" > > > > > > > >> jms > > -- > > -JH > > > > > > From leigh.porter at ukbroadband.com Tue Mar 6 03:24:07 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 6 Mar 2012 09:24:07 +0000 Subject: Huawei edge routers.. Message-ID: HI All, Has anybody had any experience of Huawei Mobile/Metro edge routers? I'm looking for something that will handle various MPLS services (Layer 2/3), QinQ with about 10x1Gb Ethernet interfaces (no need for 10G). How are they compared to JNPR/CSCO/etc equivalent ? Thanks, Leigh Porter UK Broadband/PCCW ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From saku at ytti.fi Tue Mar 6 03:49:39 2012 From: saku at ytti.fi (Saku Ytti) Date: Tue, 6 Mar 2012 11:49:39 +0200 Subject: Huawei edge routers.. In-Reply-To: References: Message-ID: <20120306094939.GA311@pob.ytti.fi> On (2012-03-06 09:24 +0000), Leigh Porter wrote: > Has anybody had any experience of Huawei Mobile/Metro edge routers? I'm looking for something that will handle various MPLS services (Layer 2/3), QinQ with about 10x1Gb Ethernet interfaces (no need for 10G). > > How are they compared to JNPR/CSCO/etc equivalent ? You probably want the CX600 series box if you're looking something to compete against ASR9k/MX. It should do what you need (10GE also). I've not really used them much, I think I've just configured enough to get 6VPE working, and it worked (against CSCO and JNPR) and was easy enough to do without docs. On paper they look fine, CLI is worse than IOS, but honestly if CLI is critical to you, you're probably doing something wrong anyhow (meaning, systems should be touching routers, not people) But personally, I'd only buy it, if there were significant long-term cost benefits. Just because getting community support for IOS/JunOS is so much easier. And investing time learning Cisco/Juniper platforms inside-out, seems better personal investment in EMEA market. -- ++ytti From bjorn at mork.no Tue Mar 6 04:05:06 2012 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 06 Mar 2012 11:05:06 +0100 Subject: Huawei edge routers.. In-Reply-To: <20120306094939.GA311@pob.ytti.fi> (Saku Ytti's message of "Tue, 6 Mar 2012 11:49:39 +0200") References: <20120306094939.GA311@pob.ytti.fi> Message-ID: <87ipiiujsd.fsf@nemi.mork.no> Saku Ytti writes: > I've not really used them much, I think I've just configured enough to get > 6VPE working, and it worked (against CSCO and JNPR) and was easy enough to > do without docs. On paper they look fine, CLI is worse than IOS, but > honestly if CLI is critical to you, you're probably doing something wrong > anyhow (meaning, systems should be touching routers, not people) Hmm, we have systems using CLI as interface to the routers. What other options do these boxes provide? Bj?rn From saku at ytti.fi Tue Mar 6 04:20:03 2012 From: saku at ytti.fi (Saku Ytti) Date: Tue, 6 Mar 2012 12:20:03 +0200 Subject: Huawei edge routers.. In-Reply-To: <87ipiiujsd.fsf@nemi.mork.no> References: <20120306094939.GA311@pob.ytti.fi> <87ipiiujsd.fsf@nemi.mork.no> Message-ID: <20120306102003.GA3382@pob.ytti.fi> On (2012-03-06 11:05 +0100), Bj?rn Mork wrote: > > do without docs. On paper they look fine, CLI is worse than IOS, but > > honestly if CLI is critical to you, you're probably doing something wrong > > anyhow (meaning, systems should be touching routers, not people) > > Hmm, we have systems using CLI as interface to the routers. What other > options do these boxes provide? I've not looked if they do netconf or whatnot, but that wasn't really my point. My point was, your system doesn't complain to you daily that working with huawei CLI is more annoying than IOS. -- ++ytti From packetjockey at gmail.com Tue Mar 6 09:18:53 2012 From: packetjockey at gmail.com (Rafael Rodriguez) Date: Tue, 6 Mar 2012 10:18:53 -0500 Subject: DiViNetworks experiences? Message-ID: Hello list, Does anyone have experience (good or bad) with DiViNetworks and their DiViLink products? Off-list replies welcomed. Thanks. From alan at alanbryant.com Tue Mar 6 10:07:07 2012 From: alan at alanbryant.com (Alan Bryant) Date: Tue, 6 Mar 2012 10:07:07 -0600 Subject: VLAN Troubles Message-ID: I hope everyone is having a better workday so far than I am. I am trying to clean up the network for the Hospital I work for, and part of that is creating two VLAN's for two separate subnets on our network. Before, it was not separated by VLANs. We are also replacing our aged Juniper firewall with an ASA. I'm very new to VLAN's, so I am hoping this is something simple that you guys can help me out with. We have two switches that do not seem to be passing VLAN traffic. The two switches are a Dell Powerconnect 5324 & a Cisco 3560G. The Cisco switch appears to be functioning fine, but the Dell switch is only passing traffic to the Cisco that is on the default untagged VLAN1. Our second VLAN is not getting passed to the Cisco at all, I am not seeing any packets tagged with the particular vlan in Wireshark. I have Port 1 on the Dell switch connected to port 29 on the Cisco switch, and port 1 on the Cisco switch connected to the ASA. I have the following config on the relevant ports on the Cisco switch: interface GigabitEthernet0/1 description ASA 5505 switchport trunk encapsulation dot1q switchport mode trunk interface GigabitEthernet0/29 description Radiology Switch switchport trunk encapsulation dot1q switchport mode trunk Here is the config for the Dell switch: interface ethernet g1 speed 1000 duplex full exit interface ethernet g2 speed 1000 duplex full exit interface ethernet g3 speed 1000 duplex full exit interface ethernet g4 speed 1000 duplex full exit interface ethernet g5 speed 1000 duplex full exit interface ethernet g7 speed 1000 duplex full exit interface ethernet g9 speed 1000 duplex full exit interface ethernet g10 speed 1000 duplex full exit interface ethernet g12 speed 1000 duplex full exit interface ethernet g14 speed 1000 duplex full exit interface ethernet g15 speed 1000 duplex full exit port jumbo-frame interface ethernet g1 switchport mode trunk exit interface ethernet g24 switchport mode trunk exit vlan database vlan 12,22 exit interface range ethernet g(2,4,7,12,14-15) switchport access vlan 12 exit interface vlan 12 name Radiology exit interface vlan 22 name Guest exit interface vlan 1 exit Anyone have any ideas or pointers? Is there more information that I need to provide? Vlan1 works just fine, of course. It is Vlan 12 that is not working. Everything on the Dell switch is communicating with each other just fine on the same subnet. From peterehiwe at gmail.com Tue Mar 6 10:36:35 2012 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Tue, 6 Mar 2012 17:36:35 +0100 Subject: VLAN Troubles In-Reply-To: References: Message-ID: Verify what protocol the dell switch uses to tag the traffic(from the datasheet) , i have seen some switches that wont trunk .1q with cisco On Tue, Mar 6, 2012 at 5:07 PM, Alan Bryant wrote: > I hope everyone is having a better workday so far than I am. > > I am trying to clean up the network for the Hospital I work for, and > part of that is creating two VLAN's for two separate subnets on our > network. Before, it was not separated by VLANs. We are also replacing > our aged Juniper firewall with an ASA. > > I'm very new to VLAN's, so I am hoping this is something simple that > you guys can help me out with. > > We have two switches that do not seem to be passing VLAN traffic. The > two switches are a Dell Powerconnect 5324 & a Cisco 3560G. The Cisco > switch appears to be functioning fine, but the Dell switch is only > passing traffic to the Cisco that is on the default untagged VLAN1. > Our second VLAN is not getting passed to the Cisco at all, I am not > seeing any packets tagged with the particular vlan in Wireshark. > > I have Port 1 on the Dell switch connected to port 29 on the Cisco > switch, and port 1 on the Cisco switch connected to the ASA. > > I have the following config on the relevant ports on the Cisco switch: > > interface GigabitEthernet0/1 > description ASA 5505 > switchport trunk encapsulation dot1q > switchport mode trunk > > interface GigabitEthernet0/29 > description Radiology Switch > switchport trunk encapsulation dot1q > switchport mode trunk > > Here is the config for the Dell switch: > > interface ethernet g1 > speed 1000 > duplex full > exit > interface ethernet g2 > speed 1000 > duplex full > exit > interface ethernet g3 > speed 1000 > duplex full > exit > interface ethernet g4 > speed 1000 > duplex full > exit > interface ethernet g5 > speed 1000 > duplex full > exit > interface ethernet g7 > speed 1000 > duplex full > exit > interface ethernet g9 > speed 1000 > duplex full > exit > interface ethernet g10 > speed 1000 > duplex full > exit > interface ethernet g12 > speed 1000 > duplex full > exit > interface ethernet g14 > speed 1000 > duplex full > exit > interface ethernet g15 > speed 1000 > duplex full > exit > port jumbo-frame > interface ethernet g1 > switchport mode trunk > exit > interface ethernet g24 > switchport mode trunk > exit > vlan database > vlan 12,22 > exit > interface range ethernet g(2,4,7,12,14-15) > switchport access vlan 12 > exit > interface vlan 12 > name Radiology > exit > interface vlan 22 > name Guest > exit > interface vlan 1 > exit > > Anyone have any ideas or pointers? Is there more information that I > need to provide? Vlan1 works just fine, of course. It is Vlan 12 that > is not working. Everything on the Dell switch is communicating with > each other just fine on the same subnet. > > -- Warm Regards Peter(CCIE 23782). From alan at alanbryant.com Tue Mar 6 10:36:21 2012 From: alan at alanbryant.com (Alan Bryant) Date: Tue, 6 Mar 2012 10:36:21 -0600 Subject: VLAN Troubles In-Reply-To: References: Message-ID: Thank you for the suggestions, unfortunately none of them are working. I have tried with the uplink in general & trunk mode. I have allowed all vlans and allowed only the specific vlans I am using tagged and untagged, but it is still not passing vlan 12. From peterehiwe at gmail.com Tue Mar 6 10:39:42 2012 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Tue, 6 Mar 2012 17:39:42 +0100 Subject: VLAN Troubles In-Reply-To: References: Message-ID: yep , verify how dell tags the vlans , it may use a proprietory tagging method for the trunk. On Tue, Mar 6, 2012 at 5:36 PM, Alan Bryant wrote: > Thank you for the suggestions, unfortunately none of them are working. > > I have tried with the uplink in general & trunk mode. I have allowed > all vlans and allowed only the specific vlans I am using tagged and > untagged, but it is still not passing vlan 12. > > -- Warm Regards Peter(CCIE 23782). From jbates at brightok.net Tue Mar 6 10:51:24 2012 From: jbates at brightok.net (Jack Bates) Date: Tue, 06 Mar 2012 10:51:24 -0600 Subject: Huawei edge routers.. In-Reply-To: <20120306102003.GA3382@pob.ytti.fi> References: <20120306094939.GA311@pob.ytti.fi> <87ipiiujsd.fsf@nemi.mork.no> <20120306102003.GA3382@pob.ytti.fi> Message-ID: <4F56408C.8030905@brightok.net> On 3/6/2012 4:20 AM, Saku Ytti wrote: > I've not looked if they do netconf or whatnot, but that wasn't really > my point. My point was, your system doesn't complain to you daily that > working with huawei CLI is more annoying than IOS. On the other hand, if you hop into other people's Huawei routers via CLI you will curse and scream. As close as I could tell, it handles most functionality of IOS, but they tried to find a synonym for every word cisco used in the cli. I thought working in Alcatel was bad compared to IOS/Junos, but Huawei definitely is up there as bad. Communicating with their installers in a multi-vendor environment left a lot to be desired. Their documentation was somewhat readable. In general, it is like all the other vendors. A ton of research to make sure the product does exactly what you want it to do, testing and adapting engineering plans based on what it will actually do. Extremely long delays in fixing any bugs or problems which you can't resolve yourself. Jack (spends too much time in cli, needs a versatile translation system for quick contract work). From greg.grimes at msstate.edu Tue Mar 6 11:04:51 2012 From: greg.grimes at msstate.edu (Greg T. Grimes) Date: Tue, 6 Mar 2012 11:04:51 -0600 (CST) Subject: VLAN Troubles In-Reply-To: References: Message-ID: On the cisco, do a 'show interface trunk'. Be sure that it thinks it's supposed to pass those VLANs. Make sure "Vlans allowed on trunk" includes the VLAN. Same for "Vlans allowed and active in management domain". Then the important one is "Vlans in spanning tree forwarding state and not pruned". If it's not there then it's being pruned. Also on your Dell uplink add the following line to the uplink port: switchport access vlan add 12,22 See what that does for you. On Tue, 6 Mar 2012, Alan Bryant wrote: > I hope everyone is having a better workday so far than I am. > > I am trying to clean up the network for the Hospital I work for, and > part of that is creating two VLAN's for two separate subnets on our > network. Before, it was not separated by VLANs. We are also replacing > our aged Juniper firewall with an ASA. > > I'm very new to VLAN's, so I am hoping this is something simple that > you guys can help me out with. > > We have two switches that do not seem to be passing VLAN traffic. The > two switches are a Dell Powerconnect 5324 & a Cisco 3560G. The Cisco > switch appears to be functioning fine, but the Dell switch is only > passing traffic to the Cisco that is on the default untagged VLAN1. > Our second VLAN is not getting passed to the Cisco at all, I am not > seeing any packets tagged with the particular vlan in Wireshark. > > I have Port 1 on the Dell switch connected to port 29 on the Cisco > switch, and port 1 on the Cisco switch connected to the ASA. > > I have the following config on the relevant ports on the Cisco switch: > > interface GigabitEthernet0/1 > description ASA 5505 > switchport trunk encapsulation dot1q > switchport mode trunk > > interface GigabitEthernet0/29 > description Radiology Switch > switchport trunk encapsulation dot1q > switchport mode trunk > > Here is the config for the Dell switch: > > interface ethernet g1 > speed 1000 > duplex full > exit > interface ethernet g2 > speed 1000 > duplex full > exit > interface ethernet g3 > speed 1000 > duplex full > exit > interface ethernet g4 > speed 1000 > duplex full > exit > interface ethernet g5 > speed 1000 > duplex full > exit > interface ethernet g7 > speed 1000 > duplex full > exit > interface ethernet g9 > speed 1000 > duplex full > exit > interface ethernet g10 > speed 1000 > duplex full > exit > interface ethernet g12 > speed 1000 > duplex full > exit > interface ethernet g14 > speed 1000 > duplex full > exit > interface ethernet g15 > speed 1000 > duplex full > exit > port jumbo-frame > interface ethernet g1 > switchport mode trunk > exit > interface ethernet g24 > switchport mode trunk > exit > vlan database > vlan 12,22 > exit > interface range ethernet g(2,4,7,12,14-15) > switchport access vlan 12 > exit > interface vlan 12 > name Radiology > exit > interface vlan 22 > name Guest > exit > interface vlan 1 > exit > > Anyone have any ideas or pointers? Is there more information that I > need to provide? Vlan1 works just fine, of course. It is Vlan 12 that > is not working. Everything on the Dell switch is communicating with > each other just fine on the same subnet. > > -- Greg T. Grimes Senior Network Analyst Information Technology Services Mississippi State University greg.grimes at msstate.edu From davidpeahi at gmail.com Tue Mar 6 11:53:30 2012 From: davidpeahi at gmail.com (david peahi) Date: Tue, 6 Mar 2012 09:53:30 -0800 Subject: Fwd: VLAN Troubles In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: david peahi Date: Tue, Mar 6, 2012 at 9:47 AM Subject: Re: VLAN Troubles To: Alan Bryant Why don't you replace the Dell switches with Cisco 3560s, and that way you are working with a single implementation of the IEEE 802.1q trunking standard? I think the very existence of this email thread proves that much time and effort is wasted in the attempt to seamlessly interoperate devices from multiple vendors. In this email thread alone I counted 2 CLI's to be learned, 2 tech support organizations to call, and 2 hardware types to spare. David On Tue, Mar 6, 2012 at 8:07 AM, Alan Bryant wrote: > I hope everyone is having a better workday so far than I am. > > I am trying to clean up the network for the Hospital I work for, and > part of that is creating two VLAN's for two separate subnets on our > network. Before, it was not separated by VLANs. We are also replacing > our aged Juniper firewall with an ASA. > > I'm very new to VLAN's, so I am hoping this is something simple that > you guys can help me out with. > > We have two switches that do not seem to be passing VLAN traffic. The > two switches are a Dell Powerconnect 5324 & a Cisco 3560G. The Cisco > switch appears to be functioning fine, but the Dell switch is only > passing traffic to the Cisco that is on the default untagged VLAN1. > Our second VLAN is not getting passed to the Cisco at all, I am not > seeing any packets tagged with the particular vlan in Wireshark. > > I have Port 1 on the Dell switch connected to port 29 on the Cisco > switch, and port 1 on the Cisco switch connected to the ASA. > > I have the following config on the relevant ports on the Cisco switch: > > interface GigabitEthernet0/1 > description ASA 5505 > switchport trunk encapsulation dot1q > switchport mode trunk > > interface GigabitEthernet0/29 > description Radiology Switch > switchport trunk encapsulation dot1q > switchport mode trunk > > Here is the config for the Dell switch: > > interface ethernet g1 > speed 1000 > duplex full > exit > interface ethernet g2 > speed 1000 > duplex full > exit > interface ethernet g3 > speed 1000 > duplex full > exit > interface ethernet g4 > speed 1000 > duplex full > exit > interface ethernet g5 > speed 1000 > duplex full > exit > interface ethernet g7 > speed 1000 > duplex full > exit > interface ethernet g9 > speed 1000 > duplex full > exit > interface ethernet g10 > speed 1000 > duplex full > exit > interface ethernet g12 > speed 1000 > duplex full > exit > interface ethernet g14 > speed 1000 > duplex full > exit > interface ethernet g15 > speed 1000 > duplex full > exit > port jumbo-frame > interface ethernet g1 > switchport mode trunk > exit > interface ethernet g24 > switchport mode trunk > exit > vlan database > vlan 12,22 > exit > interface range ethernet g(2,4,7,12,14-15) > switchport access vlan 12 > exit > interface vlan 12 > name Radiology > exit > interface vlan 22 > name Guest > exit > interface vlan 1 > exit > > Anyone have any ideas or pointers? Is there more information that I > need to provide? Vlan1 works just fine, of course. It is Vlan 12 that > is not working. Everything on the Dell switch is communicating with > each other just fine on the same subnet. > > From jason at thebaughers.com Tue Mar 6 11:55:31 2012 From: jason at thebaughers.com (Jason Baugher) Date: Tue, 06 Mar 2012 11:55:31 -0600 Subject: VLAN Troubles In-Reply-To: References: Message-ID: <4F564F93.2030607@thebaughers.com> +1 on show interface trunk, which will probably tell you that only vlan 1 is allowed on your trunk interfaces. I find it easy to forget that a Cisco switch will not pass tagged traffic for a vlan if that vlan isn't created on the switch. Even if you do something like "switchport trunk allow vlan 12" on a trunk port, it won't create the vlan on the switch unless you specifically create it or you add it to an access port like "switchport access vlan 12". Jason On 3/6/2012 11:04 AM, Greg T. Grimes wrote: > > On the cisco, do a 'show interface trunk'. Be sure that it thinks > it's supposed to pass those VLANs. Make sure "Vlans allowed on trunk" > includes the VLAN. Same for "Vlans allowed and active in management > domain". Then the important one is "Vlans in spanning tree forwarding > state and not pruned". If it's not there then it's being pruned. > Also on your Dell uplink add the following line to the uplink port: > > switchport access vlan add 12,22 > > See what that does for you. > > On Tue, 6 Mar 2012, Alan Bryant wrote: > >> I hope everyone is having a better workday so far than I am. >> >> I am trying to clean up the network for the Hospital I work for, and >> part of that is creating two VLAN's for two separate subnets on our >> network. Before, it was not separated by VLANs. We are also replacing >> our aged Juniper firewall with an ASA. >> >> I'm very new to VLAN's, so I am hoping this is something simple that >> you guys can help me out with. >> >> We have two switches that do not seem to be passing VLAN traffic. The >> two switches are a Dell Powerconnect 5324 & a Cisco 3560G. The Cisco >> switch appears to be functioning fine, but the Dell switch is only >> passing traffic to the Cisco that is on the default untagged VLAN1. >> Our second VLAN is not getting passed to the Cisco at all, I am not >> seeing any packets tagged with the particular vlan in Wireshark. >> >> I have Port 1 on the Dell switch connected to port 29 on the Cisco >> switch, and port 1 on the Cisco switch connected to the ASA. >> >> I have the following config on the relevant ports on the Cisco switch: >> >> interface GigabitEthernet0/1 >> description ASA 5505 >> switchport trunk encapsulation dot1q >> switchport mode trunk >> >> interface GigabitEthernet0/29 >> description Radiology Switch >> switchport trunk encapsulation dot1q >> switchport mode trunk >> >> Here is the config for the Dell switch: >> >> interface ethernet g1 >> speed 1000 >> duplex full >> exit >> interface ethernet g2 >> speed 1000 >> duplex full >> exit >> interface ethernet g3 >> speed 1000 >> duplex full >> exit >> interface ethernet g4 >> speed 1000 >> duplex full >> exit >> interface ethernet g5 >> speed 1000 >> duplex full >> exit >> interface ethernet g7 >> speed 1000 >> duplex full >> exit >> interface ethernet g9 >> speed 1000 >> duplex full >> exit >> interface ethernet g10 >> speed 1000 >> duplex full >> exit >> interface ethernet g12 >> speed 1000 >> duplex full >> exit >> interface ethernet g14 >> speed 1000 >> duplex full >> exit >> interface ethernet g15 >> speed 1000 >> duplex full >> exit >> port jumbo-frame >> interface ethernet g1 >> switchport mode trunk >> exit >> interface ethernet g24 >> switchport mode trunk >> exit >> vlan database >> vlan 12,22 >> exit >> interface range ethernet g(2,4,7,12,14-15) >> switchport access vlan 12 >> exit >> interface vlan 12 >> name Radiology >> exit >> interface vlan 22 >> name Guest >> exit >> interface vlan 1 >> exit >> >> Anyone have any ideas or pointers? Is there more information that I >> need to provide? Vlan1 works just fine, of course. It is Vlan 12 that >> is not working. Everything on the Dell switch is communicating with >> each other just fine on the same subnet. >> >> > From nanog.guru at gmail.com Tue Mar 6 12:00:28 2012 From: nanog.guru at gmail.com (Guru NANOG) Date: Tue, 6 Mar 2012 12:00:28 -0600 Subject: .NA - North America or NAMIBIA ? Message-ID: https://www.iana.org/domains/root/db/na.html Namibian Network Information Center PO Box 1342 Swakopmund Namibia This gets confusing for the new Top Level Domains http://NA.NOG http://NANOG.GURU What happened to NEW.NOG ? There are only 256 members of NANOG ? http://www.nanog.org/membership_main.html#list Could (Does) each member *manage* a /8 ? http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Many /8s are not used and many others are wasted. Why is that ? Are people really paid $400,000 per year to manage that list ? From jason at thebaughers.com Tue Mar 6 12:00:52 2012 From: jason at thebaughers.com (Jason Baugher) Date: Tue, 06 Mar 2012 12:00:52 -0600 Subject: Fwd: VLAN Troubles In-Reply-To: References: Message-ID: <4F5650D4.9040109@thebaughers.com> There's Heaven, where IT has an unlimited budget and management understands the reasoning you state below. And there's reality, where IT is a cost center, has to beg for every penny spent, and often times has to make do with what they have. Besides, how much fun would it be if everything was clear-cut and easy? Jason On 3/6/2012 11:53 AM, david peahi wrote: > ---------- Forwarded message ---------- > From: david peahi > Date: Tue, Mar 6, 2012 at 9:47 AM > Subject: Re: VLAN Troubles > To: Alan Bryant > > > Why don't you replace the Dell switches with Cisco 3560s, and that way you > are working with a single implementation of the IEEE 802.1q trunking > standard? I think the very existence of this email thread proves that much > time and effort is wasted in the attempt to seamlessly interoperate devices > from multiple vendors. In this email thread alone I counted 2 CLI's to be > learned, 2 tech support organizations to call, and 2 hardware types to > spare. > > David > > On Tue, Mar 6, 2012 at 8:07 AM, Alan Bryant wrote: > >> I hope everyone is having a better workday so far than I am. >> >> I am trying to clean up the network for the Hospital I work for, and >> part of that is creating two VLAN's for two separate subnets on our >> network. Before, it was not separated by VLANs. We are also replacing >> our aged Juniper firewall with an ASA. >> >> I'm very new to VLAN's, so I am hoping this is something simple that >> you guys can help me out with. >> >> We have two switches that do not seem to be passing VLAN traffic. The >> two switches are a Dell Powerconnect 5324& a Cisco 3560G. The Cisco >> switch appears to be functioning fine, but the Dell switch is only >> passing traffic to the Cisco that is on the default untagged VLAN1. >> Our second VLAN is not getting passed to the Cisco at all, I am not >> seeing any packets tagged with the particular vlan in Wireshark. >> >> I have Port 1 on the Dell switch connected to port 29 on the Cisco >> switch, and port 1 on the Cisco switch connected to the ASA. >> >> I have the following config on the relevant ports on the Cisco switch: >> >> interface GigabitEthernet0/1 >> description ASA 5505 >> switchport trunk encapsulation dot1q >> switchport mode trunk >> >> interface GigabitEthernet0/29 >> description Radiology Switch >> switchport trunk encapsulation dot1q >> switchport mode trunk >> >> Here is the config for the Dell switch: >> >> interface ethernet g1 >> speed 1000 >> duplex full >> exit >> interface ethernet g2 >> speed 1000 >> duplex full >> exit >> interface ethernet g3 >> speed 1000 >> duplex full >> exit >> interface ethernet g4 >> speed 1000 >> duplex full >> exit >> interface ethernet g5 >> speed 1000 >> duplex full >> exit >> interface ethernet g7 >> speed 1000 >> duplex full >> exit >> interface ethernet g9 >> speed 1000 >> duplex full >> exit >> interface ethernet g10 >> speed 1000 >> duplex full >> exit >> interface ethernet g12 >> speed 1000 >> duplex full >> exit >> interface ethernet g14 >> speed 1000 >> duplex full >> exit >> interface ethernet g15 >> speed 1000 >> duplex full >> exit >> port jumbo-frame >> interface ethernet g1 >> switchport mode trunk >> exit >> interface ethernet g24 >> switchport mode trunk >> exit >> vlan database >> vlan 12,22 >> exit >> interface range ethernet g(2,4,7,12,14-15) >> switchport access vlan 12 >> exit >> interface vlan 12 >> name Radiology >> exit >> interface vlan 22 >> name Guest >> exit >> interface vlan 1 >> exit >> >> Anyone have any ideas or pointers? Is there more information that I >> need to provide? Vlan1 works just fine, of course. It is Vlan 12 that >> is not working. Everything on the Dell switch is communicating with >> each other just fine on the same subnet. >> >> From aledm at qix.co.uk Tue Mar 6 12:04:38 2012 From: aledm at qix.co.uk (Aled Morris) Date: Tue, 6 Mar 2012 18:04:38 +0000 Subject: VLAN Troubles In-Reply-To: <4F564F93.2030607@thebaughers.com> References: <4F564F93.2030607@thebaughers.com> Message-ID: "show vlan" will tell you if the VLAN has been created on the Cisco. The config to create it is easy (and necessary): ! vlan 25 name Radiology ! Aled On 6 March 2012 17:55, Jason Baugher wrote: > +1 on show interface trunk, which will probably tell you that only vlan 1 > is allowed on your trunk interfaces. > > I find it easy to forget that a Cisco switch will not pass tagged traffic > for a vlan if that vlan isn't created on the switch. Even if you do > something like "switchport trunk allow vlan 12" on a trunk port, it won't > create the vlan on the switch unless you specifically create it or you add > it to an access port like "switchport access vlan 12". > > Jason > > > > On 3/6/2012 11:04 AM, Greg T. Grimes wrote: > >> >> On the cisco, do a 'show interface trunk'. Be sure that it thinks it's >> supposed to pass those VLANs. Make sure "Vlans allowed on trunk" includes >> the VLAN. Same for "Vlans allowed and active in management domain". Then >> the important one is "Vlans in spanning tree forwarding state and not >> pruned". If it's not there then it's being pruned. Also on your Dell >> uplink add the following line to the uplink port: >> >> switchport access vlan add 12,22 >> >> See what that does for you. >> >> On Tue, 6 Mar 2012, Alan Bryant wrote: >> >> I hope everyone is having a better workday so far than I am. >>> >>> I am trying to clean up the network for the Hospital I work for, and >>> part of that is creating two VLAN's for two separate subnets on our >>> network. Before, it was not separated by VLANs. We are also replacing >>> our aged Juniper firewall with an ASA. >>> >>> I'm very new to VLAN's, so I am hoping this is something simple that >>> you guys can help me out with. >>> >>> We have two switches that do not seem to be passing VLAN traffic. The >>> two switches are a Dell Powerconnect 5324 & a Cisco 3560G. The Cisco >>> switch appears to be functioning fine, but the Dell switch is only >>> passing traffic to the Cisco that is on the default untagged VLAN1. >>> Our second VLAN is not getting passed to the Cisco at all, I am not >>> seeing any packets tagged with the particular vlan in Wireshark. >>> >>> I have Port 1 on the Dell switch connected to port 29 on the Cisco >>> switch, and port 1 on the Cisco switch connected to the ASA. >>> >>> I have the following config on the relevant ports on the Cisco switch: >>> >>> interface GigabitEthernet0/1 >>> description ASA 5505 >>> switchport trunk encapsulation dot1q >>> switchport mode trunk >>> >>> interface GigabitEthernet0/29 >>> description Radiology Switch >>> switchport trunk encapsulation dot1q >>> switchport mode trunk >>> >>> Here is the config for the Dell switch: >>> >>> interface ethernet g1 >>> speed 1000 >>> duplex full >>> exit >>> interface ethernet g2 >>> speed 1000 >>> duplex full >>> exit >>> interface ethernet g3 >>> speed 1000 >>> duplex full >>> exit >>> interface ethernet g4 >>> speed 1000 >>> duplex full >>> exit >>> interface ethernet g5 >>> speed 1000 >>> duplex full >>> exit >>> interface ethernet g7 >>> speed 1000 >>> duplex full >>> exit >>> interface ethernet g9 >>> speed 1000 >>> duplex full >>> exit >>> interface ethernet g10 >>> speed 1000 >>> duplex full >>> exit >>> interface ethernet g12 >>> speed 1000 >>> duplex full >>> exit >>> interface ethernet g14 >>> speed 1000 >>> duplex full >>> exit >>> interface ethernet g15 >>> speed 1000 >>> duplex full >>> exit >>> port jumbo-frame >>> interface ethernet g1 >>> switchport mode trunk >>> exit >>> interface ethernet g24 >>> switchport mode trunk >>> exit >>> vlan database >>> vlan 12,22 >>> exit >>> interface range ethernet g(2,4,7,12,14-15) >>> switchport access vlan 12 >>> exit >>> interface vlan 12 >>> name Radiology >>> exit >>> interface vlan 22 >>> name Guest >>> exit >>> interface vlan 1 >>> exit >>> >>> Anyone have any ideas or pointers? Is there more information that I >>> need to provide? Vlan1 works just fine, of course. It is Vlan 12 that >>> is not working. Everything on the Dell switch is communicating with >>> each other just fine on the same subnet. >>> >>> >>> >> > > From alan at alanbryant.com Tue Mar 6 12:10:48 2012 From: alan at alanbryant.com (Alan Bryant) Date: Tue, 6 Mar 2012 12:10:48 -0600 Subject: VLAN Troubles In-Reply-To: References: <4F564F93.2030607@thebaughers.com> Message-ID: Just wanted to say a quick thank you to everyone who chimed in. Like I thought, it turned out to be something very simple and routine. I had not added the vlan to the Cisco switch. I had added it during testing, but I removed all testing config from the switch before I went to vlan's and did not add it back. On top of that, right before I saw the message to run sh vlan, I attempted to upgrade the firmware on the Dell switch and followed Dell's instructions to the T, but it appears that the switch is now non-functional. It is in a continuous reboot cycle and I can't even get anything over the console. Thankfully I had another switch ready and swapped it out and we are running strong with vlans. Again, thank you so much for all of your help, and hopefully one day I will be at the level to help someone else out on here. From faisal at snappydsl.net Tue Mar 6 12:13:36 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Tue, 06 Mar 2012 13:13:36 -0500 Subject: VLAN Troubles In-Reply-To: References: Message-ID: <4F5653D0.6000307@snappydsl.net> It is best to configure the Dell using the Web interface on it. You will have to use IE to access it , (need less to say it also needs a management interface '[). I find the CL to be a bit confusing , but that is me.... Speaking only for the Dell Side config. Comparing your config to some of my Dell Switch setups... You seem to be missing... (similar) ------------------------- interface range Ethernet g(1,17-18) switch port trunk allowed vlan add 500 --------------------------- from your config, it appear you are missing Vlan12 from the trunk port. Regards. Faisal Imtiaz Snappy Internet& Telecom On 3/6/2012 11:07 AM, Alan Bryant wrote: > I hope everyone is having a better workday so far than I am. > > I am trying to clean up the network for the Hospital I work for, and > part of that is creating two VLAN's for two separate subnets on our > network. Before, it was not separated by VLANs. We are also replacing > our aged Juniper firewall with an ASA. > > I'm very new to VLAN's, so I am hoping this is something simple that > you guys can help me out with. > > We have two switches that do not seem to be passing VLAN traffic. The > two switches are a Dell Powerconnect 5324& a Cisco 3560G. The Cisco > switch appears to be functioning fine, but the Dell switch is only > passing traffic to the Cisco that is on the default untagged VLAN1. > Our second VLAN is not getting passed to the Cisco at all, I am not > seeing any packets tagged with the particular vlan in Wireshark. > > I have Port 1 on the Dell switch connected to port 29 on the Cisco > switch, and port 1 on the Cisco switch connected to the ASA. > > I have the following config on the relevant ports on the Cisco switch: > > interface GigabitEthernet0/1 > description ASA 5505 > switchport trunk encapsulation dot1q > switchport mode trunk > > interface GigabitEthernet0/29 > description Radiology Switch > switchport trunk encapsulation dot1q > switchport mode trunk > > Here is the config for the Dell switch: > > interface ethernet g1 > speed 1000 > duplex full > exit > interface ethernet g2 > speed 1000 > duplex full > exit > interface ethernet g3 > speed 1000 > duplex full > exit > interface ethernet g4 > speed 1000 > duplex full > exit > interface ethernet g5 > speed 1000 > duplex full > exit > interface ethernet g7 > speed 1000 > duplex full > exit > interface ethernet g9 > speed 1000 > duplex full > exit > interface ethernet g10 > speed 1000 > duplex full > exit > interface ethernet g12 > speed 1000 > duplex full > exit > interface ethernet g14 > speed 1000 > duplex full > exit > interface ethernet g15 > speed 1000 > duplex full > exit > port jumbo-frame > interface ethernet g1 > switchport mode trunk > exit > interface ethernet g24 > switchport mode trunk > exit > vlan database > vlan 12,22 > exit > interface range ethernet g(2,4,7,12,14-15) > switchport access vlan 12 > exit > interface vlan 12 > name Radiology > exit > interface vlan 22 > name Guest > exit > interface vlan 1 > exit > > Anyone have any ideas or pointers? Is there more information that I > need to provide? Vlan1 works just fine, of course. It is Vlan 12 that > is not working. Everything on the Dell switch is communicating with > each other just fine on the same subnet. > > From jason at lixfeld.ca Tue Mar 6 13:54:24 2012 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 6 Mar 2012 14:54:24 -0500 Subject: AS209/CenturyLink NOC email? Message-ID: <8E69C309-2751-4781-A52D-6E70442863EA@lixfeld.ca> Anyone from AS209/CentryLink around to troubleshoot some routing weirdness? If not, anyone have a NOC email address for them? Google-fu and RADB searches came up empty. Thanks in advance. From kwallace at pcconnection.com Tue Mar 6 14:21:59 2012 From: kwallace at pcconnection.com (Wallace Keith) Date: Tue, 6 Mar 2012 15:21:59 -0500 Subject: AS209/CenturyLink NOC email? In-Reply-To: <8E69C309-2751-4781-A52D-6E70442863EA@lixfeld.ca> References: <8E69C309-2751-4781-A52D-6E70442863EA@lixfeld.ca> Message-ID: Have you tried looking under Qwest? -----Original Message----- From: Jason Lixfeld [mailto:jason at lixfeld.ca] Sent: Tuesday, March 06, 2012 2:54 PM To: nanog at nanog.org Subject: AS209/CenturyLink NOC email? Anyone from AS209/CentryLink around to troubleshoot some routing weirdness? If not, anyone have a NOC email address for them? Google-fu and RADB searches came up empty. Thanks in advance. From msa at latt.net Tue Mar 6 14:37:24 2012 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 6 Mar 2012 13:37:24 -0700 Subject: AS209/CenturyLink NOC email? In-Reply-To: References: <8E69C309-2751-4781-A52D-6E70442863EA@lixfeld.ca> Message-ID: <20120306203723.GD26753@puck.nether.net> On Tue, Mar 06, 2012 at 03:21:59PM -0500, Wallace Keith wrote: > Have you tried looking under Qwest? Generally speaking, emailing a Qwest address is useless these days. You'll get some sort of redirect message, in many cases to a new address that doesn't work. Rebranding for the win... --msa From merlyn at geeks.org Tue Mar 6 14:42:50 2012 From: merlyn at geeks.org (Doug McIntyre) Date: Tue, 6 Mar 2012 14:42:50 -0600 Subject: AS209/CenturyLink NOC email? In-Reply-To: <8E69C309-2751-4781-A52D-6E70442863EA@lixfeld.ca> References: <8E69C309-2751-4781-A52D-6E70442863EA@lixfeld.ca> Message-ID: <20120306204250.GA24485@geeks.org> On Tue, Mar 06, 2012 at 02:54:24PM -0500, Jason Lixfeld wrote: > Anyone from AS209/CentryLink around to troubleshoot some routing weirdness? If not, anyone have a NOC email address for them? Google-fu and RADB searches came up empty. Qwest/CenturyLink doesn't do email. As a customer, you have to call them or use their borked ticket system. As a non-customer, you probably have to call them. http://puck.nether.net/netops/nocs.cgi You can try the email listed there, but I seriously doubt it'll go through or ever get read. From lists at cmsws.com Tue Mar 6 14:46:10 2012 From: lists at cmsws.com (Jim Lucas) Date: Tue, 06 Mar 2012 12:46:10 -0800 Subject: AS209/CenturyLink NOC email? In-Reply-To: <20120306204250.GA24485@geeks.org> References: <8E69C309-2751-4781-A52D-6E70442863EA@lixfeld.ca> <20120306204250.GA24485@geeks.org> Message-ID: <4F567792.9040402@cmsws.com> On 03/06/2012 12:42 PM, Doug McIntyre wrote: > On Tue, Mar 06, 2012 at 02:54:24PM -0500, Jason Lixfeld wrote: >> Anyone from AS209/CentryLink around to troubleshoot some routing weirdness? If not, anyone have a NOC email address for them? Google-fu and RADB searches came up empty. > > Qwest/CenturyLink doesn't do email. Not sure what you are talking about. I email them all the time. And yes, they do respond. And yes, they were helpful. > > As a customer, you have to call them or use their borked ticket system. If you are a customer, then you need to talk with your sales rep and they will get it to the correct department. > > As a non-customer, you probably have to call them. > http://puck.nether.net/netops/nocs.cgi > > You can try the email listed there, but I seriously doubt it'll go > through or ever get read. > > > -- Jim Lucas http://www.cmsws.com/ http://www.cmsws.com/examples/ http://www.bendsource.com/ From nanog.guru at gmail.com Tue Mar 6 14:57:00 2012 From: nanog.guru at gmail.com (Guru NANOG) Date: Tue, 6 Mar 2012 14:57:00 -0600 Subject: IETF - Overlapping IPv4 Address Support Message-ID: Adding four more bits to the Left of the Source Address and setting those bits to 1111 (0xF) can help to start the migration to "Regions" and more IPv4 Addresses - Using and Re-Using legacy spectrumhttp://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt 16 /8s for "Future use" - it looks like the "Future" has arrived 240/8 Future use 1981-09 RESERVED [15] 241/8 Future use 1981-09 RESERVED [15] 242/8 Future use ... 253/8 Future use 1981-09 RESERVED [15] 254/8 Future use 1981-09 RESERVED [15] 255/8 Future use 1981-09 RESERVED [15] http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs-014.13. Overlapping IPv4 Address Support Wi-Fi Service Provider may segment the network into regions. Two regions may use overlap IPv4 address space. This is particularly important when the Internet is transitioning to IPv6. The Wi-Fi SP may not have enough unique public IPv4 addresses to globally address large number of Wi-Fi device. From randy.whitney at verizon.com Tue Mar 6 15:09:23 2012 From: randy.whitney at verizon.com (Randy Whitney) Date: Tue, 06 Mar 2012 16:09:23 -0500 Subject: IETF - Overlapping IPv4 Address Support In-Reply-To: References: Message-ID: <4F567D03.3080606@verizon.com> On 3/6/2012 3:57 PM, Guru NANOG wrote: > Adding four more bits to the Left of the Source Address and setting > those bits to 1111 (0xF) can help to start the migration to "Regions" > and more IPv4 Addresses - Using and Re-Using legacy > spectrumhttp://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt > > 16 /8s for "Future use" - it looks like the "Future" has arrived > > 240/8 Future use 1981-09 > RESERVED [15] > 241/8 Future use 1981-09 > RESERVED [15] > 242/8 Future use > ... > 253/8 Future use 1981-09 > RESERVED [15] > 254/8 Future use 1981-09 > RESERVED [15] > 255/8 Future use 1981-09 > RESERVED [15] > > http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs-014.13. > Overlapping IPv4 Address Support Wi-Fi Service Provider may segment the > network into regions. Two regions may use overlap IPv4 address space. This > is particularly important when the Internet is transitioning to IPv6. The > Wi-Fi SP may not have enough unique public IPv4 addresses to globally > address large number of Wi-Fi device. Please tell me this is a poor attempt at humor. -- Randy. From jeroen at mompl.net Tue Mar 6 15:09:51 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 06 Mar 2012 13:09:51 -0800 Subject: Programmers with network engineering skills In-Reply-To: References: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com> <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <4F50E9A7.8050708@gmail.com> <4F54E507.4070204@gmail.com> <4F54FD9E.2020606@ispalliance.net> <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com> <4F552755.2050102@ispalliance.net> <4A83E8A0-E655-4C92-95C9-E0C26DBB218F@delong.com> Message-ID: <4F567D1F.3070108@mompl.net> Jimmy Hess wrote: > (15) 30 seconds per resolver seems like a good timeout for DNS queries, so no > need for a configurable timeout; just try each server > sequentially, make the > UI hang, Of course you HAVE to use "busy waiting" in order to be able to quickly act upon the query timing out so you can swiftly move to the next dns server. That way the UI hangs for the least amount of time possible. (that was sarcasm) -- Earthquake Magnitude: 4.6 Date: Tuesday, March 6, 2012 09:50:22 UTC Location: near the east coast of Honshu, Japan Latitude: 37.7614; Longitude: 141.6382 Depth: 46.10 km From streiner at cluebyfour.org Tue Mar 6 15:22:13 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 6 Mar 2012 16:22:13 -0500 (EST) Subject: IETF - Overlapping IPv4 Address Support In-Reply-To: References: Message-ID: On Tue, 6 Mar 2012, Guru NANOG wrote: > Adding four more bits to the Left of the Source Address and setting > those bits to 1111 (0xF) can help to start the migration to "Regions" > and more IPv4 Addresses - Using and Re-Using legacy > spectrum > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Drugs are bad, mmmmmkay? *plonk* jms From nanog.guru at gmail.com Tue Mar 6 15:30:08 2012 From: nanog.guru at gmail.com (Guru NANOG) Date: Tue, 6 Mar 2012 15:30:08 -0600 Subject: Spread Spectrum NANOG Operational Alert - Source Addresses with 240 to 255 Message-ID: Adding four more bits to the Left of the Source Address and setting those bits to 1111 (0xF) can help to start the migration to "Regions" and more IPv4 Addresses - Using and Re-Using legacy spectrum . The real Source Address is shifted 4 bits to the Right. The bits shifted off are placed in the Deprecated TOS field in the DDDD bits. The new TOS field has the SSSS.DDDD for the CPE. If a router attempts to reply or return to the Source Address it will hit one of the Regional Hubs. There are 16 of those. Agile CPE can reply in other ways to the Agile CPE that sent the Source Address with the 1111 bits. NANOG operators may want to study the evolution of 6to4 (2002:IPv4:0000) to 6RD (IPv4:IPv4) which tunnels using Re-Used legacy 32-bit addresses. The Legacy 32-bit Address Space will likely be around a long long time and be reused in many ways. That may increase the market value of /8s. Brokers are now selling /8s on the open market. http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt 16 /8s for "Future use" - it looks like the "Future" has arrived 240/8 Future use 1981-09 RESERVED [15] ... 255/8 Future use 1981-09 RESERVED [15] http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs 014.13. Overlapping IPv4 Address Support Wi-Fi Service Provider may segment the network into regions. Two regions may use overlap IPv4 address space. This is particularly important when the Internet is transitioning to IPv6. The Wi-Fi SP may not have enough unique public IPv4 addresses to globally address large number of Wi-Fi device. From Jonathon.Exley at kordia.co.nz Tue Mar 6 15:32:33 2012 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Tue, 6 Mar 2012 21:32:33 +0000 Subject: VLAN Troubles In-Reply-To: References: Message-ID: If it's still not working, try capturing traffic from the Dell switches with Wireshark and then send traffic from the Cisco switch and also capture that. Compare the frames and check that the salient parts line up - e.g. Ethertype. Jonathon -----Original Message----- From: Peter Ehiwe [mailto:peterehiwe at gmail.com] Sent: Wednesday, 7 March 2012 5:40 a.m. To: Alan Bryant Cc: nanog at nanog.org Subject: Re: VLAN Troubles yep , verify how dell tags the vlans , it may use a proprietory tagging method for the trunk. On Tue, Mar 6, 2012 at 5:36 PM, Alan Bryant wrote: > Thank you for the suggestions, unfortunately none of them are working. > > I have tried with the uplink in general & trunk mode. I have allowed > all vlans and allowed only the specific vlans I am using tagged and > untagged, but it is still not passing vlan 12. > > -- Warm Regards Peter(CCIE 23782). This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From ecables at gmail.com Tue Mar 6 15:39:01 2012 From: ecables at gmail.com (Eric Cables) Date: Tue, 6 Mar 2012 13:39:01 -0800 Subject: Centralized NOC Monitoring Solutions Message-ID: I am evaluating outsourced NOC solutions, where all of the device monitoring and pro-active response is handled by a centralized NOC (NaaS? :-)). The goal is to reduce the day-to-day overhead of calling carriers to troubleshoot circuit problems, basic network troubleshooting when congestion occurs, pro-active response and notification when critical systems go down during off hours, etc. The focus is network related to start, but could branch out into servers in the future. Any feedback on: companies used, what to look for, and general thoughts on a centralized NOC approach would be appreciated. -- Eric Cables From Jonathon.Exley at kordia.co.nz Tue Mar 6 15:41:57 2012 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Tue, 6 Mar 2012 21:41:57 +0000 Subject: Huawei edge routers.. In-Reply-To: <4F56408C.8030905@brightok.net> References: <20120306094939.GA311@pob.ytti.fi> <87ipiiujsd.fsf@nemi.mork.no> <20120306102003.GA3382@pob.ytti.fi> <4F56408C.8030905@brightok.net> Message-ID: I last played with Huawei routers about 10 years ago and it looked very much like IOS. Interesting that they have changed. Also interesting that you don't like Alcatel's TiMOS - I prefer it to IOS, and find it comparable to Junos. I suppose we all have our own tastes... Jonathon -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Wednesday, 7 March 2012 5:51 a.m. To: nanog at nanog.org Subject: Re: Huawei edge routers.. On 3/6/2012 4:20 AM, Saku Ytti wrote: > I've not looked if they do netconf or whatnot, but that wasn't really > my point. My point was, your system doesn't complain to you daily that > working with huawei CLI is more annoying than IOS. On the other hand, if you hop into other people's Huawei routers via CLI you will curse and scream. As close as I could tell, it handles most functionality of IOS, but they tried to find a synonym for every word cisco used in the cli. I thought working in Alcatel was bad compared to IOS/Junos, but Huawei definitely is up there as bad. Communicating with their installers in a multi-vendor environment left a lot to be desired. Their documentation was somewhat readable. In general, it is like all the other vendors. A ton of research to make sure the product does exactly what you want it to do, testing and adapting engineering plans based on what it will actually do. Extremely long delays in fixing any bugs or problems which you can't resolve yourself. Jack (spends too much time in cli, needs a versatile translation system for quick contract work). This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From morrowc.lists at gmail.com Tue Mar 6 15:42:08 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 6 Mar 2012 16:42:08 -0500 Subject: Spread Spectrum NANOG Operational Alert - Source Addresses with 240 to 255 In-Reply-To: References: Message-ID: http://tools.ietf.org/html/draft-fuller-240space-02 On Tue, Mar 6, 2012 at 4:30 PM, Guru NANOG wrote: > Adding four more bits to the Left of the Source Address and setting > those bits to 1111 (0xF) can help to start the migration to "Regions" > and more IPv4 Addresses - Using and Re-Using legacy spectrum > . > > The real Source Address is shifted 4 bits to the Right. The bits > shifted off are placed in the Deprecated TOS field in the DDDD bits. > The new TOS field has the SSSS.DDDD for the CPE. > > If a router attempts to reply or return to the Source Address it will > hit one of the Regional Hubs. There are 16 of those. > Agile CPE can reply in other ways to the Agile CPE that sent the > Source Address with the 1111 bits. > > NANOG operators may want to study the evolution of 6to4 (2002:IPv4:0000) to > 6RD (IPv4:IPv4) which tunnels using Re-Used legacy 32-bit addresses. > > The Legacy 32-bit Address Space will likely be around a long long time > and be reused in many ways. > That may increase the market value of /8s. Brokers are now selling /8s > on the open market. > > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt > > > 16 /8s for "Future use" - it looks like the "Future" has arrived > > 240/8 ?Future use ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1981-09 > ? ? ? ? ?RESERVED ? ?[15] > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ... > ? 255/8 ?Future use ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1981-09 > ? ? ? ? ? ? RESERVED ?[15] > http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs > > > 014.13. > Overlapping IPv4 Address Support Wi-Fi Service Provider may segment the > network into regions. Two regions may use overlap IPv4 address space. This > is particularly important when the Internet is transitioning to IPv6. The > Wi-Fi SP may not have enough unique public IPv4 addresses to globally > address large number of Wi-Fi device. From jacob at juecker.net Tue Mar 6 15:55:44 2012 From: jacob at juecker.net (Jacob Uecker) Date: Tue, 06 Mar 2012 13:55:44 -0800 Subject: Centralized NOC Monitoring Solutions In-Reply-To: References: Message-ID: <4F5687E0.4020708@juecker.net> Hey Eric, Disclaimer: I work for LightSquare, LLC (http://lightsquare.us) and it's what we do. Look for high-touch, flexible people who work with you to meet your business goals. You don't want to outsource your network or security operations to a company who doesn't care about you or your business. Make sure they're not going to try to fit you into a box. I'd also look for a company who is going to adapt to your environment. They should have a plan and standard procedures for building institutional knowledge so they don't alert on the same thing over and over again. They should be trying to make your network better and look for ways to improve processes, technologies, etc. They should be able to show you an operations guide that describes exactly what they're going to do with different types of problems, who they are going to notify, what they're going to do, and when. You should have very clear expectations about what is going to happen and by when. You should get weekly, monthly, quarterly and annual reports that are meaningful, informative and customized. Let me know if you have more questions. Jacob On 3/6/12 1:39 PM, Eric Cables wrote: > I am evaluating outsourced NOC solutions, where all of the device > monitoring and pro-active response is handled by a centralized NOC > (NaaS? :-)). The goal is to reduce the day-to-day overhead of > calling carriers to troubleshoot circuit problems, basic network > troubleshooting when congestion occurs, pro-active response and > notification when critical systems go down during off hours, etc. > The focus is network related to start, but could branch out into > servers in the future. > > Any feedback on: companies used, what to look for, and general > thoughts on a centralized NOC approach would be appreciated. > > -- Eric Cables From jeroen at mompl.net Tue Mar 6 15:57:24 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 06 Mar 2012 13:57:24 -0800 Subject: WW: Colo Vending Machine In-Reply-To: References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com> Message-ID: <4F568844.1010602@mompl.net> Sven Olaf Kamphuis wrote: >> 7 - compressed air can to clean dust > > dust?!?!? sounds like time to find a whole new colo and move everything > out of there haha. > > i've -never- encountered one with dust in it. > > that stuff usually gets sucked out before it gets the idea to land on > anything should it even get in in the first place I'e seen a "state of the art" San Jose equinix data centre with a leaking roof, accompanied by buckets on the floor (so we're safe) and the occasional cricket like insect crawling through the racks (but hey, they do have traps for those :-) But... no dust. Regards, Jeroen -- Earthquake Magnitude: 4.6 Date: Tuesday, March 6, 2012 09:50:22 UTC Location: near the east coast of Honshu, Japan Latitude: 37.7614; Longitude: 141.6382 Depth: 46.10 km From merlyn at geeks.org Tue Mar 6 15:59:42 2012 From: merlyn at geeks.org (Doug McIntyre) Date: Tue, 6 Mar 2012 15:59:42 -0600 Subject: VLAN Troubles In-Reply-To: References: Message-ID: <20120306215942.GB24485@geeks.org> On Tue, Mar 06, 2012 at 09:32:33PM +0000, Jonathon Exley wrote: > If it's still not working, try capturing traffic from the Dell switches with Wireshark and then send traffic from the Cisco switch and also capture that. Compare the frames and check that the salient parts line up - e.g. Ethertype. He already posted his response of getting it working. But in general, Dell switches interop just fine with Cisco and Juniper switches for VLAN trunking. The CLI on the Dell switches is a royal PIA to use. Tries to be Cisco IOS, but not quite. Different enough to make you sware at it. And if you want to do something like setup many VLANs trunked to different port groups, and single ports, your config will be 1000's of lines long (depending on which switch you have. Since each of the different revs of each families seems to be made by a different OEM, or some new code base from a few OEMs). From swm at emanon.com Tue Mar 6 16:03:47 2012 From: swm at emanon.com (Scott Morris) Date: Tue, 06 Mar 2012 17:03:47 -0500 Subject: IETF - Overlapping IPv4 Address Support In-Reply-To: References: Message-ID: <4F5689C3.3020106@emanon.com> Hell, years ago, I only wanted to add three bits and give a set to each continent with one leftover for the United Federation of Planets (and Antarctica really didn't need one anyway)... I was told that would be geographically discriminating! :) Ah well, c'est la vie! Why be lazy when we can be more complicated? Scott On 3/6/12 4:22 PM, Justin M. Streiner wrote: > On Tue, 6 Mar 2012, Guru NANOG wrote: > >> Adding four more bits to the Left of the Source Address and setting >> those bits to 1111 (0xF) can help to start the migration to "Regions" >> and more IPv4 Addresses - Using and Re-Using legacy >> spectrum >> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt >> > > Drugs are bad, mmmmmkay? > > *plonk* > > jms > > > From peterehiwe at gmail.com Tue Mar 6 16:16:34 2012 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Tue, 6 Mar 2012 23:16:34 +0100 Subject: VLAN Troubles In-Reply-To: References: <4F564F93.2030607@thebaughers.com> Message-ID: cool! On Tue, Mar 6, 2012 at 7:10 PM, Alan Bryant wrote: > Just wanted to say a quick thank you to everyone who chimed in. Like I > thought, it turned out to be something very simple and routine. I had > not added the vlan to the Cisco switch. I had added it during testing, > but I removed all testing config from the switch before I went to > vlan's and did not add it back. > > On top of that, right before I saw the message to run sh vlan, I > attempted to upgrade the firmware on the Dell switch and followed > Dell's instructions to the T, but it appears that the switch is now > non-functional. It is in a continuous reboot cycle and I can't even > get anything over the console. > > Thankfully I had another switch ready and swapped it out and we are > running strong with vlans. > > Again, thank you so much for all of your help, and hopefully one day I > will be at the level to help someone else out on here. > > -- Warm Regards Peter(CCIE 23782). From jbates at brightok.net Tue Mar 6 16:28:08 2012 From: jbates at brightok.net (Jack Bates) Date: Tue, 06 Mar 2012 16:28:08 -0600 Subject: Huawei edge routers.. In-Reply-To: References: <20120306094939.GA311@pob.ytti.fi> <87ipiiujsd.fsf@nemi.mork.no> <20120306102003.GA3382@pob.ytti.fi> <4F56408C.8030905@brightok.net> Message-ID: <4F568F78.6000500@brightok.net> On 3/6/2012 3:41 PM, Jonathon Exley wrote: > I last played with Huawei routers about 10 years ago and it looked very much like IOS. Interesting that they have changed. > Also interesting that you don't like Alcatel's TiMOS - I prefer it to IOS, and find it comparable to Junos. > I suppose we all have our own tastes... > Huawei looks very much like IOS, except many of the commands were renamed. Someone mentioned a reason to me, but I don't know if it was true, so I won't repeat it. IOS at least supports | section, and I hear that IOS-XR and IOS-XE both have advanced configuration capabilities similar to Junos, but I don't own any of the hardware that supports those code bases. I've yet to find a router vendor I liked 100%, though. Limited feature sets, interoperability problems, bugs, and months to resolve issues and generally requiring upgrades to code that has new issues. :( But as you said, we all have our own tastes... Mine just happens to be for a non-existent company/product. Jack From bruns at 2mbit.com Tue Mar 6 17:15:27 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 06 Mar 2012 16:15:27 -0700 Subject: VLAN Troubles In-Reply-To: References: Message-ID: <4F569A8F.2020502@2mbit.com> On 3/6/12 9:07 AM, Alan Bryant wrote: > > We have two switches that do not seem to be passing VLAN traffic. The > two switches are a Dell Powerconnect 5324& a Cisco 3560G. The Cisco > switch appears to be functioning fine, but the Dell switch is only > passing traffic to the Cisco that is on the default untagged VLAN1. > Our second VLAN is not getting passed to the Cisco at all, I am not > seeing any packets tagged with the particular vlan in Wireshark. > > I have Port 1 on the Dell switch connected to port 29 on the Cisco > switch, and port 1 on the Cisco switch connected to the ASA. > > I have the following config on the relevant ports on the Cisco switch: > > Anyone have any ideas or pointers? Is there more information that I > need to provide? Vlan1 works just fine, of course. It is Vlan 12 that > is not working. Everything on the Dell switch is communicating with > each other just fine on the same subnet. > I can confirm similar issues between our older Dell Poweredge 1655 and a Cisco 3550. Took me a while to figure this one out, considering the aggro trunks weren't working right either. Switching it to etherchannel solved the trunking issue, but I still had some major issues with VLANs even after that. I have yet to move the 1655 (since we still use it for lab purposes) to the 6503. I hate to put it this way, but I'd love to know what crack Dell was doing when they decided to use the software/hardware switch stuff they did. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jgreco at ns.sol.net Tue Mar 6 17:33:01 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 6 Mar 2012 17:33:01 -0600 (CST) Subject: VLAN Troubles In-Reply-To: <4F569A8F.2020502@2mbit.com> Message-ID: <201203062333.q26NX1oK083656@aurora.sol.net> > I can confirm similar issues between our older Dell Poweredge 1655 and a > Cisco 3550. Took me a while to figure this one out, considering the > aggro trunks weren't working right either. Switching it to etherchannel > solved the trunking issue, but I still had some major issues with VLANs > even after that. > > I have yet to move the 1655 (since we still use it for lab purposes) to > the 6503. > > I hate to put it this way, but I'd love to know what crack Dell was > doing when they decided to use the software/hardware switch stuff they did. I don't think the 1655 and the 5324 share ancestry. Dell does what lots of companies do: they outsourced. The Dell 5_2_24 was a catastrophic device that was based on the same hardware platform as the Foundry Edgeiron 24G and the SMC 8624T, 3Com's 3824 ... the only difference in many cases being paint and firmware. All of these were actually made by Accton, who sold it as the ES4624, and the early revisions had a catastrophic failure mode that would result in the two halves of the switch losing communications with each other, or something like that, hopefully I'll be forgiven for the technical handwaving, and eventually firmware workarounds "fixed" the switch, but (I think?) Foundry led the pack on that, and so you'd come across Dell gear with Foundry firmware or stuff like that, done by people desperate to stop their switches from going wonky every few weeks. I don't think I ever did identify the source of the 5324 fully, I think I concluded that it was somewhat unique to Dell. It lacked most of the other quirks common to cheap switches like the Accton (broadcast domain issues, anyone?) and was, at the time, probably one of the best deals in managed switching. It only had a few goofs that I could complain about, including the lack of 64-bit interface counters and the Ciscoesque-but- not-quite syntax. For the most part, I've heard that their newer products are pretty good too, though usually there are tradeoffs. obDisclosure: We run a bunch of 5324's, and don't seem to have any issues with them. ... 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 malayter at gmail.com Tue Mar 6 17:46:24 2012 From: malayter at gmail.com (Ryan Malayter) Date: Tue, 6 Mar 2012 15:46:24 -0800 (PST) Subject: Fwd: VLAN Troubles In-Reply-To: References: Message-ID: <238971d2-e2b7-4fce-9e12-45dcba93774f@b1g2000yqb.googlegroups.com> On Mar 6, 11:53?am, david peahi wrote: > > Why don't you replace the Dell switches with Cisco 3560s, and that way you > are working with a single implementation of the IEEE 802.1q trunking > standard? I think the very existence of this email thread proves that much > time and effort is wasted in the attempt to seamlessly interoperate devices > from multiple vendors. In this email thread alone I counted 2 CLI's to be > learned, 2 tech support organizations to call, and 2 hardware types to > spare. > > David Funny, it's always the Cisco devices that seem to be the cause of interop problems in my network. They're the only vendor that seems to think defaulting proprietary protocols is reasonable. Cat 3ks default to proprietary Rapid-PVST+, proprietary VTP, proprietary DTP, proprietary HSRP, and proprietary ISL tagging. And Cisco documentation generally recommends these proprietary protocols or at least documents them *before* the standard equivalents (wonder why?). Cisco does of course generally support the IEEE or IETF protocols, but not without configuration that often requires downtime or at least a spanning-tree/ OSPF event if it was missed before deployment. We can lash together Dell/HP/other switches all day long with near- default configurations, but every time we have a new Cisco box to configure it's required to wade though IOS release notes to see what new proprietary protocol we have to disable. Cisco makes good gear with lots of features, but can be a royal pain if you use *anything* non-Cisco. It's not prudent to rely on a single vendor for anything, and it's not as though IOS is a magically bug- free bit of code. I've been told that in at least some high-frequency trading networks, the redundant switches/routers at each tier are intentionally from different vendors, so that a software issue in one won't take everything down. That seems like a good idea at first, but it wouldn't surprise me to have an interop issue or mis-configuration caused by unfamiliarity take down both devices. Does anybody out there do this? From bruns at 2mbit.com Tue Mar 6 17:48:44 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 06 Mar 2012 16:48:44 -0700 Subject: VLAN Troubles In-Reply-To: <201203062333.q26NX1oK083656@aurora.sol.net> References: <201203062333.q26NX1oK083656@aurora.sol.net> Message-ID: <4F56A25C.1050303@2mbit.com> On 3/6/12 4:33 PM, Joe Greco wrote: > I don't think the 1655 and the 5324 share ancestry. I'm pretty sure they don't either, but never know. > > Dell does what lots of companies do: they outsourced. The Dell 5_2_24 > was a catastrophic device that was based on the same hardware platform > as the Foundry Edgeiron 24G and the SMC 8624T, 3Com's 3824 ... the > only difference in many cases being paint and firmware. All of these > were actually made by Accton, who sold it as the ES4624, and the early > revisions had a catastrophic failure mode that would result in the two > halves of the switch losing communications with each other, or something > like that, hopefully I'll be forgiven for the technical handwaving, and > eventually firmware workarounds "fixed" the switch, but (I think?) > Foundry led the pack on that, and so you'd come across Dell gear with > Foundry firmware or stuff like that, done by people desperate to stop > their switches from going wonky every few weeks. Ah yes, the EIF24G. I have two of the -A models here and a pallet of them in a warehouse. I know exactly the failures you are talking about - in our case, we got the switches with QC tags stating "Dead ports". A firmware update and the ports magically came back and started working again. Originally figured an ASIC or similar had gone south and taken out a group of ports. I'm actually pretty happy with the switches, they're pretty durable and we've got the two at home acting as the 'edge' switches for things like the HTPC, NAS, DirecTV receivers, etc. Before we needed the extra ports, had the foundry 10GCF which has a similar less then stellar history. Mess of a witch, but it held up well for 2 years until the EIF24G-As came. I believe both the 10GCF and the EIF24G's are of the same vintage of Accton hardware. > > I don't think I ever did identify the source of the 5324 fully, I think > I concluded that it was somewhat unique to Dell. It lacked most of the > other quirks common to cheap switches like the Accton (broadcast domain > issues, anyone?) and was, at the time, probably one of the best deals in > managed switching. It only had a few goofs that I could complain about, > including the lack of 64-bit interface counters and the Ciscoesque-but- > not-quite syntax. For the most part, I've heard that their newer > products are pretty good too, though usually there are tradeoffs. > > obDisclosure: We run a bunch of 5324's, and don't seem to have any > issues with them. I got a bit... frustrated with the switch modules on the 1655 many times. CLI makes me want to puke. Would get into a wonky state, and I had to factory reset it via the web ui. Finally just gave up with the CLI and used the web ui to configure it. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From tom at ninjabadger.net Tue Mar 6 18:02:07 2012 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 07 Mar 2012 00:02:07 +0000 Subject: POLL: Network and Service Status Pages In-Reply-To: <31959529.3147.1330983602289.JavaMail.root@benjamin.baylink.com> References: <31959529.3147.1330983602289.JavaMail.root@benjamin.baylink.com> Message-ID: <4F56A57F.7000903@ninjabadger.net> On 05/03/12 21:40, Jay Ashworth wrote: > Every six months or so, I poll the mailing list for links to your > favorite status pages for carriers, web services, and the like, to > add to the Dashboard page at > > http://www.outages.org > > If you have any you like, which you know are still working, and are > publicly accessible, that you'd like posted there for everyone's > benefit, please mail them to me *off-list*, and I'll double-check > them, and post them ASAP. I especially like this page: http://www.outages.org/index.php/Anything_you_might_want_to_know_about_abs_exercises 0_o Tom From jmaslak at antelope.net Tue Mar 6 19:07:06 2012 From: jmaslak at antelope.net (Joel Maslak) Date: Tue, 6 Mar 2012 18:07:06 -0700 Subject: VLAN Troubles In-Reply-To: <4F56A25C.1050303@2mbit.com> References: <201203062333.q26NX1oK083656@aurora.sol.net> <4F56A25C.1050303@2mbit.com> Message-ID: I've never had problems setting up multiple VLANs on a link between Cisco, HP, Dell switches, IBM mainframes, VMWare servers, 3COM/Nortel, Polycom Phones, Linux servers, etc. If both ends supported 802.1q, it just worked, if the admin read the manual for both pieces of gear and knew how to troubleshoot problems. Sure, one vendor can be nice a lot of the time - even cheaper once support costs are factored in. But making VLANs work between different vendor's equipment is a pretty basic networking skill. So I'm kind of astonished at the "sell what you have and buy new from one vendor" responses. I've not used the specific Dell switches mentioned, but I've used others and have plenty of opinions on the management interface of them. But for a wiring closet or top of rack switch, I can't say that I would suggest to replace them with something new just because I wanted a different management interface (that said, I very well might write some scripts to manage the uglier interfaces). From mysidia at gmail.com Tue Mar 6 19:49:58 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 6 Mar 2012 19:49:58 -0600 Subject: IETF - Overlapping IPv4 Address Support In-Reply-To: References: Message-ID: On Tue, Mar 6, 2012 at 2:57 PM, Guru NANOG wrote: > Adding four more bits to the Left of the Source Address and setting [snip] Any address extension scheme or change to IP addressing has to be meaningfully interoperable for it to be useful; the method must be standardized and become an accepted standard, otherwise it would be utterly useless. I would encourage you to read up on draft-ietf-lisp-22. http://datatracker.ietf.org/doc/draft-ietf-lisp/writeup/ Regards, -- -JH From jackson.tim at gmail.com Tue Mar 6 19:54:11 2012 From: jackson.tim at gmail.com (Tim Jackson) Date: Tue, 6 Mar 2012 19:54:11 -0600 Subject: IETF - Overlapping IPv4 Address Support In-Reply-To: References: Message-ID: I thought you were gonna read up on the timecube. On Mar 6, 2012 2:57 PM, "Guru NANOG" wrote: > Adding four more bits to the Left of the Source Address and setting > those bits to 1111 (0xF) can help to start the migration to "Regions" > and more IPv4 Addresses - Using and Re-Using legacy > spectrumhttp:// > www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt > > 16 /8s for "Future use" - it looks like the "Future" has arrived > > 240/8 Future use 1981-09 > RESERVED [15] > 241/8 Future use 1981-09 > RESERVED [15] > 242/8 Future use > ... > 253/8 Future use 1981-09 > RESERVED [15] > 254/8 Future use 1981-09 > RESERVED [15] > 255/8 Future use 1981-09 > RESERVED [15] > > > http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs-014.13 > . > Overlapping IPv4 Address Support Wi-Fi Service Provider may segment the > network into regions. Two regions may use overlap IPv4 address space. This > is particularly important when the Internet is transitioning to IPv6. The > Wi-Fi SP may not have enough unique public IPv4 addresses to globally > address large number of Wi-Fi device. > From drc at virtualized.org Tue Mar 6 20:07:30 2012 From: drc at virtualized.org (David Conrad) Date: Tue, 6 Mar 2012 18:07:30 -0800 Subject: IETF - Overlapping IPv4 Address Support In-Reply-To: References: Message-ID: <55C03488-AC5D-47F8-BFA5-2D293F0881B8@virtualized.org> You all have encouraged me to filter 'nanog.guru' in both sender _and_ recipient fields. If you insist on engaging the loons, please I beg you, cc them directly. Regards, -drc On Mar 6, 2012, at 5:49 PM, Jimmy Hess wrote: > On Tue, Mar 6, 2012 at 2:57 PM, Guru NANOG wrote: >> Adding four more bits to the Left of the Source Address and setting > [snip] > Any address extension scheme or change to IP addressing has to be > meaningfully interoperable for it to be useful; the method must be > standardized and become an accepted standard, otherwise it would be > utterly useless. > > I would encourage you to read up on draft-ietf-lisp-22. > http://datatracker.ietf.org/doc/draft-ietf-lisp/writeup/ > > > Regards, > -- > -JH > From randy at psg.com Tue Mar 6 21:07:02 2012 From: randy at psg.com (Randy Bush) Date: Wed, 07 Mar 2012 12:07:02 +0900 Subject: IETF - Overlapping IPv4 Address Support In-Reply-To: <55C03488-AC5D-47F8-BFA5-2D293F0881B8@virtualized.org> References: <55C03488-AC5D-47F8-BFA5-2D293F0881B8@virtualized.org> Message-ID: David Conrad wrote: > > You all have encouraged me to filter 'nanog.guru' in both sender _and_ recipient fields. to keep this somewhat operational, what are you using? i am using :0 * ^(From:|TO_).*(nanog.guru|and more) $TRASH > If you insist on engaging the loons, please I beg you, cc them directly. please keep the med-deficient sicko's addy in ^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparently(-Resent)?)-To) randy From jbartin at WUSTL.EDU Tue Mar 6 22:58:36 2012 From: jbartin at WUSTL.EDU (Bartin, John) Date: Wed, 7 Mar 2012 04:58:36 +0000 Subject: FCoE/CNA Deployment w/ Nexus 5K, HP 580s, QLogic In-Reply-To: References: <20120228005014.GA20175@ref.nmedia.net> <4F4D575C.4000306@networktest.com> Message-ID: <3F90C3DB30CC7D42BB6758437130CD680CBDB6@citemb2b> Thanks for posting this. We are planning a similar design, and we've purchased QLogic adapters. Has anyone tried something like this with an Emulex CNA? http://www.emulex.com/products/oneconnect-ucnas/10gbe-fcoe-cnas/emulex-branded/oce11102-f/overview.html John -----Original Message----- From: David Swafford [mailto:david at davidswafford.com] Sent: Tuesday, February 28, 2012 7:19 PM To: David Newman; Nanog Subject: Re: FCoE/CNA Deployment w/ Nexus 5K, HP 580s, QLogic The full SKU of the original cards was QLE8242-CU-CK (dual port copper). The replacements were the same, but SR instead of CU. Here's a quick link of detail on these cards -- http://www.qlogic.com/Resources/Documents/DataSheets/Adapters/Datasheet_8200_Series_Adapters.pdf . The copper cables/SFPs were Cisco's SFP-H10GB-CU5M and SFP-H10GB-CU3M, which are listed on QLogic's list of approved cables: http://www.qlogic.com/Resources/Documents/LineCards/Copper_Cables_Support_Matrix_Line_Card.pdf . I had a comment regarding the TCO of a Nexus 5548 w/ full SR SFPs vs. copper and yes, this is a significant cost increase, so be aware of that! Hopefully you're not paying retail for them :-), even w/ our discount it was substantial. David. On Tue, Feb 28, 2012 at 5:38 PM, David Newman wrote: > On 2/28/12 2:55 AM, David Swafford wrote: > > > Yeah, our vendors epically failed here! > > Were these QLogic 2400s or 2500s by any chance? > > https://admin.fedoraproject.org/updates/F15/FEDORA-2012-1863 > > dn > > > > > The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail. From leigh.porter at ukbroadband.com Wed Mar 7 01:07:32 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 7 Mar 2012 07:07:32 +0000 Subject: L3 VPN Management Message-ID: <3F07E816-EFC6-4E01-8951-559FE7AF7AE9@ukbroadband.com> Folks, I have a number of L3 MPLS VPNs. For example, there is the WiFi management VPN (WiFi management interface). There is th systems VPN where things like RADIUS servers, Databases talk. There is a VPN for LTE OAM. There are alsomseparate VPNs for other LTE functions. All OK. Then are various sites I have a cluster of ops servers, syslogs, things that go ping, instances of cacti and our various vendors management systems. They all sit behind a firewall. What's the nicest way of allowing the ops servers all talk to each VPN instance? At the moment I just us pretty normal L3VPN techniques so that every VPN sees routes tagged with the ops VPN target community and so that the ops VPN sees all the other VPN routes but the division between VPNs is maintained. Or, would it be nicer to have the firewall have a foot in each VPN, advertise routes to ops systems to each VPN instance and receive routes from all the other VPNs? -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From jvanoppen at spectrumnet.us Wed Mar 7 01:23:04 2012 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Wed, 7 Mar 2012 07:23:04 +0000 Subject: did AS174 and AS4134 de-peer? Message-ID: All - I was noticing that it appears from our Seattle-based full route feed from cogent that they may have de-peered AS4134 (or vise-versa)... anyone know anything about this? We noticed this recently in a shift of traffic away from cogent for traffic to and from china telecom... Now cogent's path is _174_1239_4134_. In any case, was just wondering if anyone had noticed this. AS4134 is one that often generates NOC calls on our end due to their often saturated peers to any number of other upstreams and the cogent route had been remarkably uncongested previously so it is sad to see it disappear. Thanks, John @ AS11404. From igor at ergens.org Wed Mar 7 01:43:07 2012 From: igor at ergens.org (Igor Ybema) Date: Wed, 7 Mar 2012 08:43:07 +0100 Subject: facebook lost their A-record for www.facebook.com? Message-ID: [igor at vds ~]$ host -t A www.facebook.com ns1.facebook.com Using domain server: Name: ns1.facebook.com Address: 204.74.66.132#53 Aliases: www.facebook.com has no A record However: [igor at vds ~]$ dig A www.facebook.com @ns1.facebook.com ; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 <<>> A www.facebook.com @ns1.facebook.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55657 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.facebook.com. IN A ;; AUTHORITY SECTION: www.facebook.com. 86400 IN NS glb2.facebook.com. www.facebook.com. 86400 IN NS glb1.facebook.com. ;; ADDITIONAL SECTION: glb2.facebook.com. 3600 IN A 69.171.255.10 glb1.facebook.com. 3600 IN A 69.171.239.10 ;; Query time: 11 msec ;; SERVER: 204.74.66.132#53(204.74.66.132) ;; WHEN: Wed Mar 7 08:42:44 2012 ;; MSG SIZE rcvd: 104 Not sure what is going wrong here. People @ facebook? regards, Igor From alvarezp at alvarezp.ods.org Wed Mar 7 01:49:18 2012 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Tue, 06 Mar 2012 23:49:18 -0800 Subject: facebook lost their A-record for www.facebook.com? In-Reply-To: References: Message-ID: On Tue, 06 Mar 2012 23:43:07 -0800, Igor Ybema wrote: > [igor at vds ~]$ host -t A www.facebook.com ns1.facebook.com > Using domain server: > Name: ns1.facebook.com > Address: 204.74.66.132#53 > Aliases: > > www.facebook.com has no A record No, it's a subdomain with its A records in another server. $ host -t A www.facebook.com glb1.facebook.com. Using domain server: Name: glb1.facebook.com. Address: 69.171.239.10#53 Aliases: www.facebook.com has address 69.171.224.12 Try dig +trace www.facebook.com to see why. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp From jsw at inconcepts.biz Wed Mar 7 02:03:42 2012 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 7 Mar 2012 03:03:42 -0500 Subject: L3 VPN Management In-Reply-To: <3F07E816-EFC6-4E01-8951-559FE7AF7AE9@ukbroadband.com> References: <3F07E816-EFC6-4E01-8951-559FE7AF7AE9@ukbroadband.com> Message-ID: On Wed, Mar 7, 2012 at 2:07 AM, Leigh Porter wrote: > What's the nicest way of allowing the ops servers all talk to each VPN instance? At the moment I just us pretty normal L3VPN techniques so that every VPN sees routes tagged with the ops VPN target community and so that the ops VPN sees all the other VPN routes but the division between VPNs is maintained. > > Or, would it be nicer to have the firewall have a foot in each VPN, advertise routes to ops systems to each VPN instance and receive routes from all the other VPNs? I think you may pay more money for extra firewall zones and perhaps not receive any benefit from it. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From graham at apolix.co.za Wed Mar 7 02:10:25 2012 From: graham at apolix.co.za (graham at apolix.co.za) Date: Wed, 07 Mar 2012 10:10:25 +0200 Subject: facebook lost their A-record for =?UTF-8?Q?www=2Efacebook=2Ec?= =?UTF-8?Q?om=3F?= In-Reply-To: References: Message-ID: On 07.03.2012 09:43, Igor Ybema wrote: > [igor at vds ~]$ host -t A www.facebook.com ns1.facebook.com > Using domain server: > Name: ns1.facebook.com > Address: 204.74.66.132#53 > Aliases: > > www.facebook.com has no A record We also picked up problems with www.facebook.com from our monitoring systems. Starting from 04:00 UTC there were some latency spikes and then from 06:15 UTC thru 07:55 UTC the site was unreachable. www.v6.facebook.com had no issues though ;) -- Graham Beneke From me at anuragbhatia.com Wed Mar 7 02:51:54 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 7 Mar 2012 14:21:54 +0530 Subject: facebook lost their A-record for www.facebook.com? In-Reply-To: References: Message-ID: Good point Octavio . +trace with dig is always useful when getting weird results. (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Mar 7, 2012 1:19 PM, "Octavio Alvarez" wrote: > On Tue, 06 Mar 2012 23:43:07 -0800, Igor Ybema wrote: > > [igor at vds ~]$ host -t A www.facebook.com ns1.facebook.com >> Using domain server: >> Name: ns1.facebook.com >> Address: 204.74.66.132#53 >> Aliases: >> >> www.facebook.com has no A record >> > > No, it's a subdomain with its A records in another server. > > $ host -t A www.facebook.com glb1.facebook.com. > Using domain server: > Name: glb1.facebook.com. > Address: 69.171.239.10#53 > Aliases: > > www.facebook.com has address 69.171.224.12 > > > Try dig +trace www.facebook.com to see why. > > > > -- > Octavio. > > Twitter: @alvarezp2000 -- Identi.ca: @alvarezp > > From saku at ytti.fi Wed Mar 7 02:57:09 2012 From: saku at ytti.fi (Saku Ytti) Date: Wed, 7 Mar 2012 10:57:09 +0200 Subject: L3 VPN Management In-Reply-To: <3F07E816-EFC6-4E01-8951-559FE7AF7AE9@ukbroadband.com> References: <3F07E816-EFC6-4E01-8951-559FE7AF7AE9@ukbroadband.com> Message-ID: <20120307085709.GA2676@pob.ytti.fi> On (2012-03-07 07:07 +0000), Leigh Porter wrote: > What's the nicest way of allowing the ops servers all talk to each VPN instance? At the moment I just us pretty normal L3VPN techniques so that every VPN sees routes tagged with the ops VPN target community and so that the ops VPN sees all the other VPN routes but the division between VPNs is maintained. You might want to peek at MPLS VPN Security book by Behringer for some ideas[0]. But personally I'd do it by having RT for MGMT servers and different RT for addresses needing centralized MGMT. So two special-use RTs. The NMS network would export routes with this RT:Servers (only the servers actually poking the VPN network, not everything) And the customer VRFs would import this RT:Servers. The customer VRFs would export (only the nodes actually needing NSM, not whole network) routes with RT:CPEs. And the NMS network would import RT:CPEs. One way to do latter part is JunOS: set routing-instance FOO rib FOO.inet.0 static route CPE/32 qualified-next-hop CPE interface xe-4/2/0.42 tag 2000 IOS: ip route vrf FOO CPE 255.255.255.255 ten4/2/0.42 CPE tag 2000 And have policy which matches to 2000 and add RT:CPE. Annoyingly in JunOS you cannot easily import more than one RT, I hope they'll fix it so that you can do IOS style RT + policy imports. So in JunOS you almost certainly want chained import policy like 'vrf-import [ VRFOO-IMPORT VRF-MGMT-IMPORT ]' where VRFOO-IMPORT is just 'from community VRFFOO; then default-action accept' and VRF-MGMT-IMPORT is 'from community RT:Servers; then default-action accept' [0] http://www.amazon.co.uk/MPLS-VPN-Security-Cisco-Press/dp/8177586998/ref=sr_1_1?ie=UTF8&qid=1331110165&sr=8-1 > > Or, would it be nicer to have the firewall have a foot in each VPN, advertise routes to ops systems to each VPN instance and receive routes from all the other VPNs? > > -- > Leigh > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > -- ++ytti From bjorn at mork.no Wed Mar 7 03:30:37 2012 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 07 Mar 2012 10:30:37 +0100 Subject: IETF - Overlapping IPv4 Address Support In-Reply-To: (Guru NANOG's message of "Tue, 6 Mar 2012 14:57:00 -0600") References: Message-ID: <878vjcsqpu.fsf@nemi.mork.no> You seem to have skipped a calendar page. Bj?rn From tim at pelican.org Wed Mar 7 03:46:13 2012 From: tim at pelican.org (Tim Franklin) Date: Wed, 07 Mar 2012 09:46:13 -0000 (GMT) Subject: Huawei edge routers.. In-Reply-To: <4F56408C.8030905@brightok.net> Message-ID: > On the other hand, if you hop into other people's Huawei > routers via CLI you will curse and scream. As close as I > could tell, it handles most functionality of IOS, but > they tried to find a synonym for every word cisco used > in the cli. This does occasionally brighten up my day with gems like "rip no work" and "reset-recycle-bin", so it's not all bad :) Regards, Tim. From leigh.porter at ukbroadband.com Wed Mar 7 04:02:03 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 7 Mar 2012 10:02:03 +0000 Subject: Huawei edge routers.. In-Reply-To: References: <4F56408C.8030905@brightok.net>, Message-ID: On 7 Mar 2012, at 09:48, "Tim Franklin" wrote: >> On the other hand, if you hop into other people's Huawei >> routers via CLI you will curse and scream. As close as I >> could tell, it handles most functionality of IOS, but >> they tried to find a synonym for every word cisco used >> in the cli. > > This does occasionally brighten up my day with gems like "rip no work" and "reset-recycle-bin", so it's not Oh so you have to configure it in chinglish.. Well I'll certainly be looking forward to that ! Somebody set up us the BGP. -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From saku at ytti.fi Wed Mar 7 04:31:06 2012 From: saku at ytti.fi (Saku Ytti) Date: Wed, 7 Mar 2012 12:31:06 +0200 Subject: Huawei edge routers.. In-Reply-To: References: <4F56408C.8030905@brightok.net> Message-ID: <20120307103106.GA16901@pob.ytti.fi> On (2012-03-07 09:46 -0000), Tim Franklin wrote: > This does occasionally brighten up my day with gems like "rip no work" and "reset-recycle-bin", so it's not all bad :) I liked how ssh is secure-telnet, took bit head scratching to enable ssh. But again, I don't think crappy or good CLI is very important matter, when using systems. And it's not something your customers will notice, so you cannot charge premium. -- ++ytti From nick at foobar.org Wed Mar 7 04:55:16 2012 From: nick at foobar.org (Nick Hilliard) Date: Wed, 07 Mar 2012 10:55:16 +0000 Subject: Huawei edge routers.. In-Reply-To: <20120307103106.GA16901@pob.ytti.fi> References: <4F56408C.8030905@brightok.net> <20120307103106.GA16901@pob.ytti.fi> Message-ID: <4F573E94.9060806@foobar.org> On 07/03/2012 10:31, Saku Ytti wrote: > But again, I don't think crappy or good CLI is very important matter, when > using systems. it isn't - if you're large enough that you have an automated provisioning system. Most of us aren't in that category though, and for those who aren't, it's the L3 tech people who will be doing the product evaluation and who will end up loathing the kit because of the horrible cli, and who will then be less likely to make a recommendation to buy it, as they're the people who are going to end up using it the most. Nick From oscar.vives at gmail.com Wed Mar 7 06:06:44 2012 From: oscar.vives at gmail.com (Tei) Date: Wed, 7 Mar 2012 13:06:44 +0100 Subject: Programmers with network engineering skills In-Reply-To: <6088002.1109.1330381386271.JavaMail.root@benjamin.baylink.com> References: <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com> <6088002.1109.1330381386271.JavaMail.root@benjamin.baylink.com> Message-ID: On 27 February 2012 23:23, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> I think you're more likely to find a network engineer with (possibly >> limited) programming skills. >> >> That's certainly where I would categorize myself. > > And you're the first I've seen suggest, or even imply, that going that > direction instead might be more fruitful; seemed to me that the skills > necessary to make a decent network engineer would support learning > programming better than the other way round -- though in fact I personally > did it the other way. I agree. And I am just a programmer. Part of it, is that our job is to obscure implementation details to these in higuer levels. We think hard to build stuff, so other people don't have to. If theres a program that create a conexion, and that conexion can break, we silently repeat the re-conexion part, so these that use the program ignore these problems and can live happy. A bad programmer will show a message "Conexion break, please connect again". Having the human manually pressing the "connect" button again. I have no words for how lame is that. So we hide implementation details for us, and for others. Programmers that write compilers hide implementation details to others. Designers of CPU's microcode hide implementation details to mere assembler programmers. -- -- ?in del ?ensaje. From jbates at brightok.net Wed Mar 7 07:58:17 2012 From: jbates at brightok.net (Jack Bates) Date: Wed, 07 Mar 2012 07:58:17 -0600 Subject: Huawei edge routers.. In-Reply-To: <4F573E94.9060806@foobar.org> References: <4F56408C.8030905@brightok.net> <20120307103106.GA16901@pob.ytti.fi> <4F573E94.9060806@foobar.org> Message-ID: <4F576979.9090700@brightok.net> On 3/7/2012 4:55 AM, Nick Hilliard wrote: > it isn't - if you're large enough that you have an automated > provisioning system. Most of us aren't in that category though, and > for those who aren't, it's the L3 tech people who will be doing the > product evaluation and who will end up loathing the kit because of the > horrible cli, and who will then be less likely to make a > recommendation to buy it, as they're the people who are going to end > up using it the most. Nick Unless they get overruled. The project I saw Huawei go into was a mixed environment for cellular and IP routing. The company decided to stick to one manufacturer. They apparently had issues with other gear handling their mobile stuff and Huawei came in at a good price. Then I had to explain to their installers why they needed an area 0 (which is funny, since I barely know anything of OSPF as I almost exclusively use ISIS). :( Jack From tony at lavanauts.org Wed Mar 7 08:44:22 2012 From: tony at lavanauts.org (Antonio Querubin) Date: Wed, 7 Mar 2012 04:44:22 -1000 (HST) Subject: VLAN Troubles In-Reply-To: References: Message-ID: On Tue, 6 Mar 2012, Alan Bryant wrote: > We have two switches that do not seem to be passing VLAN traffic. The > two switches are a Dell Powerconnect 5324 & a Cisco 3560G. The Cisco > switch appears to be functioning fine, but the Dell switch is only > passing traffic to the Cisco that is on the default untagged VLAN1. > Our second VLAN is not getting passed to the Cisco at all, I am not > seeing any packets tagged with the particular vlan in Wireshark. > > I have Port 1 on the Dell switch connected to port 29 on the Cisco > switch, and port 1 on the Cisco switch connected to the ASA. > > I have the following config on the relevant ports on the Cisco switch: > > interface GigabitEthernet0/1 > description ASA 5505 > switchport trunk encapsulation dot1q > switchport mode trunk > > interface GigabitEthernet0/29 > description Radiology Switch > switchport trunk encapsulation dot1q > switchport mode trunk Have you verified VLANs 12 and 22 are actually defined on the Cisco? > vlan database > vlan 12,22 Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From tony at lavanauts.org Wed Mar 7 08:47:34 2012 From: tony at lavanauts.org (Antonio Querubin) Date: Wed, 7 Mar 2012 04:47:34 -1000 (HST) Subject: VLAN Troubles In-Reply-To: References: Message-ID: On Tue, 6 Mar 2012, Greg T. Grimes wrote: > pruned". If it's not there then it's being pruned. Also on your Dell uplink > add the following line to the uplink port: > > switchport access vlan add 12,22 Probably should be switchport trunk allowed vlan add xxx,xxx tagged if you're trying to limit which VLANs are passed. Also, you may want to try 'general' mode: switchport mode general switchport general allowed vlan add xxx,xxx tagged Antonio Querubin e-mail: tony at lavanauts.org xmpp: antonioquerubin at gmail.com From jra at baylink.com Wed Mar 7 09:17:58 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 7 Mar 2012 10:17:58 -0500 (EST) Subject: PLEASE don't feed the troll Message-ID: <15861941.3695.1331133478509.JavaMail.root@benjamin.baylink.com> Nuff said? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Wed Mar 7 09:25:27 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 7 Mar 2012 10:25:27 -0500 (EST) Subject: Huawei edge routers.. In-Reply-To: <20120307103106.GA16901@pob.ytti.fi> Message-ID: <19108836.3699.1331133927485.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Saku Ytti" > On (2012-03-07 09:46 -0000), Tim Franklin wrote: > > This does occasionally brighten up my day with gems like "rip no > > work" and "reset-recycle-bin", so it's not all bad :) > > I liked how ssh is secure-telnet, took bit head scratching to enable > ssh. That is, of course, incorrect; there is actually a "secure telnet"; ISTR it's telnet-over-ssl? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From isabeldias1 at yahoo.com Wed Mar 7 09:25:53 2012 From: isabeldias1 at yahoo.com (isabel dias) Date: Wed, 7 Mar 2012 07:25:53 -0800 (PST) Subject: PLEASE don't feed the troll In-Reply-To: <15861941.3695.1331133478509.JavaMail.root@benjamin.baylink.com> References: <15861941.3695.1331133478509.JavaMail.root@benjamin.baylink.com> Message-ID: <1331133953.65419.YahooMailNeo@web121606.mail.ne1.yahoo.com> are you a PhD? otherwise you are not making sence ________________________________ From: Jay Ashworth To: NANOG Sent: Wednesday, March 7, 2012 3:17 PM Subject: PLEASE don't feed the troll Nuff said? Cheers, -- jra -- Jay R. Ashworth? ? ? ? ? ? ? ? ? Baylink? ? ? ? ? ? ? ? ? ? ? jra at baylink.com Designer? ? ? ? ? ? ? ? ? ? The Things I Think? ? ? ? ? ? ? ? ? ? ? RFC 2100 Ashworth & Associates? ? http://baylink.pitas.com? ? ? ? 2000 Land Rover DII St Petersburg FL USA? ? ? http://photo.imageinc.us? ? ? ? ? ? +1 727 647 1274 From leigh.porter at ukbroadband.com Wed Mar 7 09:32:40 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 7 Mar 2012 15:32:40 +0000 Subject: Huawei edge routers.. In-Reply-To: <19108836.3699.1331133927485.JavaMail.root@benjamin.baylink.com> References: <20120307103106.GA16901@pob.ytti.fi> <19108836.3699.1331133927485.JavaMail.root@benjamin.baylink.com> Message-ID: > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: 07 March 2012 15:28 > To: NANOG > Subject: Re: Huawei edge routers.. > > ----- Original Message ----- > > From: "Saku Ytti" > > > On (2012-03-07 09:46 -0000), Tim Franklin wrote: > > > This does occasionally brighten up my day with gems like "rip no > > > work" and "reset-recycle-bin", so it's not all bad :) > > > > I liked how ssh is secure-telnet, took bit head scratching to enable > > ssh. > > That is, of course, incorrect; there is actually a "secure telnet"; > ISTR it's telnet-over-ssl? How do you enable SSH then? Do Huawei routers even have SSH? It'd slightly ironic that there is fuss around getting a Juniper domestic image with SSH enabled and yet a Chinese vendor likely just gives it away. So having said all that, has anybody here had good experiences of Huawei routers? Have they worked well in your networks and are you happy with them? I'm mainly looking for something small (1-2U) that will do Ethernet over MPLS, VPLS and L3VPN services. -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From aledm at qix.co.uk Wed Mar 7 09:40:05 2012 From: aledm at qix.co.uk (Aled Morris) Date: Wed, 7 Mar 2012 15:40:05 +0000 Subject: Huawei edge routers.. In-Reply-To: <19108836.3699.1331133927485.JavaMail.root@benjamin.baylink.com> References: <20120307103106.GA16901@pob.ytti.fi> <19108836.3699.1331133927485.JavaMail.root@benjamin.baylink.com> Message-ID: On 7 March 2012 15:25, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Saku Ytti" > > > On (2012-03-07 09:46 -0000), Tim Franklin wrote: > > > This does occasionally brighten up my day with gems like "rip no > > > work" and "reset-recycle-bin", so it's not all bad :) > > > > I liked how ssh is secure-telnet, took bit head scratching to enable > > ssh. > > That is, of course, incorrect; there is actually a "secure telnet"; ISTR > it's telnet-over-ssl? > > There's also RFC2942 for Kerberos authenticated TELNET which is "secure" in one sense and RFC2946 for encrypted sessions though I'm not sure if this is widely supported. They are listed in the TELNET client on the Mac (Snow Leopard) that I'm using so you never know... Aled From jbates at brightok.net Wed Mar 7 10:22:56 2012 From: jbates at brightok.net (Jack Bates) Date: Wed, 07 Mar 2012 10:22:56 -0600 Subject: Huawei edge routers.. In-Reply-To: References: <20120307103106.GA16901@pob.ytti.fi> <19108836.3699.1331133927485.JavaMail.root@benjamin.baylink.com> Message-ID: <4F578B60.1010609@brightok.net> On 3/7/2012 9:32 AM, Leigh Porter wrote: > >> I liked how ssh is secure-telnet, took bit head scratching to enable >> ssh. >> That is, of course, incorrect; there is actually a "secure telnet"; >> ISTR it's telnet-over-ssl? > How do you enable SSH then? It may be incorrect terminology, but it is actually ssh on the box. >sys ]rsa local-key-par create ]stelnet server enable ]undo ssh server compatible-ssh1x enable ]display ssh server status SSH version :2.0 SSH connection timeout :60 seconds SSH server key generating interval :0 hours SSH Authentication retries :3 times SFTP server :Disable Stelnet server :Enable ]quit >save all > > Do Huawei routers even have SSH? It'd slightly ironic that there is fuss around getting a Juniper domestic image with SSH enabled and yet a Chinese vendor likely just gives it away. See above. > So having said all that, has anybody here had good experiences of Huawei routers? Have they worked well in your networks and are you happy with them? I'm mainly looking for something small (1-2U) that will do Ethernet over MPLS, VPLS and L3VPN services. > > My experience is limited with just keeping it running and configuring what I must. I have 0 documentation and it requires a lot of "?" for me to find the appropriately named commands for what I want to do still. I haven't seen the physical box. I've heard them call it an X3 and an NE40E. A little googling, and I'm not sure if this router is even a homebrew for them. I suspect others have a lot more experience with their various platforms. Jack From jradke at canbytel.com Wed Mar 7 11:29:29 2012 From: jradke at canbytel.com (Radke, Justin) Date: Wed, 7 Mar 2012 09:29:29 -0800 Subject: AS Connectivity Lookup Message-ID: How can I easily view the current peering relationship of a particular AS? Assume the AS you are researching does not have a looking glass and you are not going to do lookups from the top 10 providers route servers to get some glimpse of their connectivity. In my particular search bgplay.routeviews.org does not have any information and as-rank.caida.org is out of date. In the past there was a great website called webtrace.info but it is no longer online. Any suggestions? From me at anuragbhatia.com Wed Mar 7 11:31:49 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 7 Mar 2012 23:01:49 +0530 Subject: AS Connectivity Lookup In-Reply-To: References: Message-ID: Hi Radke You can try http://bgp.he.net On Wed, Mar 7, 2012 at 10:59 PM, Radke, Justin wrote: > How can I easily view the current peering relationship of a particular AS? > Assume the AS you are researching does not have a looking glass and you are > not going to do lookups from the top 10 providers route servers to get some > glimpse of their connectivity. In my particular search > bgplay.routeviews.org does > not have any information and as-rank.caida.org is out of date. In the past > there was a great website called webtrace.info but it is no longer online. > > Any suggestions? > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From hank at efes.iucc.ac.il Wed Mar 7 11:39:04 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 07 Mar 2012 19:39:04 +0200 Subject: AS Connectivity Lookup In-Reply-To: Message-ID: <5.1.0.14.2.20120307193636.0379bb58@efes.iucc.ac.il> At 09:29 07/03/2012 -0800, Radke, Justin wrote: >How can I easily view the current peering relationship of a particular AS? >Assume the AS you are researching does not have a looking glass and you are >not going to do lookups from the top 10 providers route servers to get some >glimpse of their connectivity. In my particular search >bgplay.routeviews.org does >not have any information and as-rank.caida.org is out of date. In the past >there was a great website called webtrace.info but it is no longer online. > >Any suggestions? Try: http://www.fixedorbit.com/search.htm and do an ASN search. -Hank From cboyd at gizmopartners.com Wed Mar 7 12:08:04 2012 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 7 Mar 2012 12:08:04 -0600 Subject: AS Connectivity Lookup In-Reply-To: <5.1.0.14.2.20120307193636.0379bb58@efes.iucc.ac.il> References: <5.1.0.14.2.20120307193636.0379bb58@efes.iucc.ac.il> Message-ID: <44382886-041F-43DA-97EC-37B865FA40C3@gizmopartners.com> On Mar 7, 2012, at 11:39 AM, Hank Nussbacher wrote: > Try: http://www.fixedorbit.com/search.htm and do an ASN search. > > -Hank Is that info supposed to be current? It's wildly out of date for us (35970). bgp.he.net has all the correct information. --Chris From davidianwalker at gmail.com Wed Mar 7 12:35:14 2012 From: davidianwalker at gmail.com (David Walker) Date: Thu, 8 Mar 2012 05:05:14 +1030 Subject: AS Connectivity Lookup In-Reply-To: References: Message-ID: On 08/03/2012, Anurag Bhatia wrote: > Hi Radke > > You can try http://bgp.he.net Example: http://bgp.he.net/AS4739 Guest login here: http://peeringdb.com/ > > On Wed, Mar 7, 2012 at 10:59 PM, Radke, Justin wrote: > >> How can I easily view the current peering relationship of a particular AS? >> Assume the AS you are researching does not have a looking glass and you >> are >> not going to do lookups from the top 10 providers route servers to get >> some >> glimpse of their connectivity. In my particular search >> bgplay.routeviews.org does >> not have any information and as-rank.caida.org is out of date. In the past >> there was a great website called webtrace.info but it is no longer online. >> >> Any suggestions? >> > > > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com > From jradke at canbytel.com Wed Mar 7 13:06:09 2012 From: jradke at canbytel.com (Radke, Justin) Date: Wed, 7 Mar 2012 11:06:09 -0800 Subject: AS Connectivity Lookup In-Reply-To: References: Message-ID: All great answers! Thank you! -=JGR On Wed, Mar 7, 2012 at 10:35 AM, David Walker wrote: > On 08/03/2012, Anurag Bhatia wrote: > > Hi Radke > > > > You can try http://bgp.he.net > > Example: > http://bgp.he.net/AS4739 > > Guest login here: > http://peeringdb.com/ > > > > > On Wed, Mar 7, 2012 at 10:59 PM, Radke, Justin > wrote: > > > >> How can I easily view the current peering relationship of a particular > AS? > >> Assume the AS you are researching does not have a looking glass and you > >> are > >> not going to do lookups from the top 10 providers route servers to get > >> some > >> glimpse of their connectivity. In my particular search > >> bgplay.routeviews.org does > >> not have any information and as-rank.caida.org is out of date. In the > past > >> there was a great website called webtrace.info but it is no longer > online. > >> > >> Any suggestions? > >> > > > > > > > > -- > > > > Anurag Bhatia > > anuragbhatia.com > > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > > network! > > > > Twitter: @anurag_bhatia > > Linkedin: http://linkedin.anuragbhatia.com > > > From Valdis.Kletnieks at vt.edu Wed Mar 7 13:08:41 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 07 Mar 2012 14:08:41 -0500 Subject: Huawei edge routers.. In-Reply-To: Your message of "Wed, 07 Mar 2012 10:22:56 CST." <4F578B60.1010609@brightok.net> References: <20120307103106.GA16901@pob.ytti.fi> <19108836.3699.1331133927485.JavaMail.root@benjamin.baylink.com> <4F578B60.1010609@brightok.net> Message-ID: <5455.1331147321@turing-police.cc.vt.edu> On Wed, 07 Mar 2012 10:22:56 CST, Jack Bates said: > ]undo ssh server compatible-ssh1x enable Ouch. That's brutal. Is it true that setting isn't listed under 'display ssh server status'? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From nanog-post at rsuc.gweep.net Wed Mar 7 13:11:07 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 7 Mar 2012 14:11:07 -0500 Subject: AS Connectivity Lookup In-Reply-To: References: Message-ID: <20120307191107.GA10219@gweep.net> On Wed, Mar 07, 2012 at 09:29:29AM -0800, Radke, Justin wrote: > How can I easily view the current peering relationship of a particular AS? > Assume the AS you are researching does not have a looking glass and you are > not going to do lookups from the top 10 providers route servers to get some > glimpse of their connectivity. In my particular search > bgplay.routeviews.org does > not have any information and as-rank.caida.org is out of date. In the past > there was a great website called webtrace.info but it is no longer online. > > Any suggestions? Any site you reference outside/not downstream of the desired AS will only provide you a partial picture. Use many to try and create a holistic view. So far it seems RIPE RIS hasn't yet been mentioned: http://www.ripe.net/data-tools/stats/ris/routing-information-service -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From me at anuragbhatia.com Wed Mar 7 13:12:21 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 8 Mar 2012 00:42:21 +0530 Subject: AS Connectivity Lookup In-Reply-To: <20120307191107.GA10219@gweep.net> References: <20120307191107.GA10219@gweep.net> Message-ID: On Thu, Mar 8, 2012 at 12:41 AM, Joe Provo wrote: > On Wed, Mar 07, 2012 at 09:29:29AM -0800, Radke, Justin wrote: > > How can I easily view the current peering relationship of a particular > AS? > > Assume the AS you are researching does not have a looking glass and you > are > > not going to do lookups from the top 10 providers route servers to get > some > > glimpse of their connectivity. In my particular search > > bgplay.routeviews.org does > > not have any information and as-rank.caida.org is out of date. In the > past > > there was a great website called webtrace.info but it is no longer > online. > > > > Any suggestions? > > Any site you reference outside/not downstream of the desired > AS will only provide you a partial picture. Use many to try > and create a holistic view. So far it seems RIPE RIS hasn't > yet been mentioned: > http://www.ripe.net/data-tools/stats/ris/routing-information-service Yeah RIS is good but only minor issue with it is that its output is little slow. > > > > -- > RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From jbates at brightok.net Wed Mar 7 13:24:16 2012 From: jbates at brightok.net (Jack Bates) Date: Wed, 07 Mar 2012 13:24:16 -0600 Subject: Huawei edge routers.. In-Reply-To: <5455.1331147321@turing-police.cc.vt.edu> References: <20120307103106.GA16901@pob.ytti.fi> <19108836.3699.1331133927485.JavaMail.root@benjamin.baylink.com> <4F578B60.1010609@brightok.net> <5455.1331147321@turing-police.cc.vt.edu> Message-ID: <4F57B5E0.5000700@brightok.net> On 3/7/2012 1:08 PM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 07 Mar 2012 10:22:56 CST, Jack Bates said: > >> ]undo ssh server compatible-ssh1x enable > Ouch. That's brutal. Is it true that setting isn't listed under 'display ssh server status'? > ]ssh server compat enable ]display ssh server status SSH version :1.99 Appears to show it. Lists 2.0 if you turn it off. Jack From owen at delong.com Wed Mar 7 14:18:04 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 7 Mar 2012 12:18:04 -0800 Subject: Huawei edge routers.. In-Reply-To: <4F573E94.9060806@foobar.org> References: <4F56408C.8030905@brightok.net> <20120307103106.GA16901@pob.ytti.fi> <4F573E94.9060806@foobar.org> Message-ID: <0B9A9E4E-6543-4808-95D5-983BABE7C496@delong.com> On Mar 7, 2012, at 2:55 AM, Nick Hilliard wrote: > On 07/03/2012 10:31, Saku Ytti wrote: >> But again, I don't think crappy or good CLI is very important matter, when >> using systems. > > it isn't - if you're large enough that you have an automated provisioning > system. Most of us aren't in that category though, and for those who > aren't, it's the L3 tech people who will be doing the product evaluation > and who will end up loathing the kit because of the horrible cli, and who > will then be less likely to make a recommendation to buy it, as they're the > people who are going to end up using it the most. > > Nick > I disagree. A good CLI vs. a bad one can also make a difference in the interaction with an automated provisioning system. Sure, you can work around the bad CLI and mask it better with an APS, but, it still causes problems even with an APS. Owen From mhuff at ox.com Wed Mar 7 14:45:25 2012 From: mhuff at ox.com (Matthew Huff) Date: Wed, 7 Mar 2012 15:45:25 -0500 Subject: Increase of DOS attacks using TCP src and/or dst of 0 Message-ID: <483E6B0272B0284BA86D7596C40D29F901928959AA9D@PUR-EXCH07.ox.com> Anyone else see a massive increase of scanning/dos with TCP source and/or dst port of 0? We started seeing a massive increase today creating some issue with our firewalls. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5339 bytes Desc: not available URL: From ekim.ittag at gmail.com Wed Mar 7 15:21:38 2012 From: ekim.ittag at gmail.com (Mike Gatti) Date: Wed, 7 Mar 2012 13:21:38 -0800 Subject: Increase of DOS attacks using TCP src and/or dst of 0 In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901928959AA9D@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F901928959AA9D@PUR-EXCH07.ox.com> Message-ID: <211D05EF-4574-4B45-87F7-5ECDDA0FE399@gmail.com> I just scanned through the last 48 hours of logs and did not find anything. We are peering with Level3 (AS 3549) and Verizon (AS 11486). -- Michael Gatti main. 949.371.5474 (UTC -8) On Mar 7, 2012, at 12:45 PM, Matthew Huff wrote: > Anyone else see a massive increase of scanning/dos with TCP source and/or > dst port of 0? We started seeing a massive increase today creating some > issue with our firewalls. > > > > > > > > ---- > > Matthew Huff | 1 Manhattanville Rd > > Director of Operations | Purchase, NY 10577 > > OTA Management LLC | Phone: 914-460-4039 > > aim: matthewbhuff | Fax: 914-460-4139 > > > From morrowc.lists at gmail.com Wed Mar 7 15:29:46 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 7 Mar 2012 16:29:46 -0500 Subject: Increase of DOS attacks using TCP src and/or dst of 0 In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901928959AA9D@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F901928959AA9D@PUR-EXCH07.ox.com> Message-ID: On Wed, Mar 7, 2012 at 3:45 PM, Matthew Huff wrote: > Anyone else see a massive increase of scanning/dos with TCP source and/or > dst port of 0? We started seeing a massive increase today creating some > issue with our firewalls. srs/dst of 0 as measured how? (tcpdump? netflow? app logs?) From pete at altadena.net Wed Mar 7 16:13:34 2012 From: pete at altadena.net (Pete Carah) Date: Wed, 07 Mar 2012 14:13:34 -0800 Subject: Increase of DOS attacks using TCP src and/or dst of 0 In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F901928959AA9D@PUR-EXCH07.ox.com> Message-ID: <4F57DD8E.5060805@altadena.net> On 03/07/2012 01:29 PM, Christopher Morrow wrote: > On Wed, Mar 7, 2012 at 3:45 PM, Matthew Huff wrote: >> Anyone else see a massive increase of scanning/dos with TCP source and/or >> dst port of 0? We started seeing a massive increase today creating some >> issue with our firewalls. > srs/dst of 0 as measured how? (tcpdump? netflow? app logs?) No, however I am seeing an increase in unsolicited syn-ack packets with a wider variety of "from" ports (many 80 still, used to be almost all) but some 22, 113, 4000, 600x, and high "from" ports with "to" ports of 3072 and 1024, many to ip addrs that are not targets of A records, so appear to be indiscriminate scans... Source IP's all over the place as expected. Don't know if it is tcptraceroute in a strange mode, or OS fingerprinting attempts, or both. Also don't know if the sources are spoofs or not (rather hard to tell...) Sources don't seem to match up with syn-only packets either, at least on the same day. -- Pete > From cowie at renesys.com Wed Mar 7 16:34:44 2012 From: cowie at renesys.com (Jim Cowie) Date: Wed, 7 Mar 2012 17:34:44 -0500 Subject: did AS174 and AS4134 de-peer? In-Reply-To: References: Message-ID: On Wed, Mar 7, 2012 at 2:23 AM, John van Oppen wrote: > All - > > I was noticing that it appears from our Seattle-based full route feed from > cogent that they may have de-peered AS4134 (or vise-versa)... anyone know > anything about this? We noticed this recently in a shift of traffic away > from cogent for traffic to and from china telecom... Now cogent's path is > _174_1239_4134_. > > Indeed: http://www.renesys.com/blog/2012/03/cogent-depeers-china-telecom.shtml cheers, --jim From axisml at gmail.com Wed Mar 7 16:41:00 2012 From: axisml at gmail.com (Chris Stone) Date: Wed, 7 Mar 2012 15:41:00 -0700 Subject: Increase of DOS attacks using TCP src and/or dst of 0 In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901928959AA9D@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F901928959AA9D@PUR-EXCH07.ox.com> Message-ID: On Wed, Mar 7, 2012 at 1:45 PM, Matthew Huff wrote: > Anyone else see a massive increase of scanning/dos with TCP source and/or > dst port of 0? We started seeing a massive increase today creating some > issue with our firewalls. Not seeing a ton of them, but do see a few logged on most all of our server like: Mar 5 07:49:13 server kernel: Shorewall:logflags:DROP:IN=eth2 OUT= MAC=00:07:e9:0f:39:f1:00:03:31:a5:74:00:08:00 SRC=178.18.16.101 DST=x.x.x.x LEN=56 TOS=0x00 PREC=0x00 TTL=204 ID=49665 DF PROTO=TCP SPT=0 DPT=0 WINDOW=37009 RES=0x14 URG ACK RST SYN FIN URGP=37422 -- Chris Stone AxisInternet, Inc. www.axint.net From george.herbert at gmail.com Wed Mar 7 16:48:10 2012 From: george.herbert at gmail.com (George Herbert) Date: Wed, 7 Mar 2012 14:48:10 -0800 Subject: Increase of DOS attacks using TCP src and/or dst of 0 In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F901928959AA9D@PUR-EXCH07.ox.com> Message-ID: Out of curiosity - Is it possible it's a command and control network, rather than directly an attack? On Wed, Mar 7, 2012 at 2:41 PM, Chris Stone wrote: > On Wed, Mar 7, 2012 at 1:45 PM, Matthew Huff wrote: >> Anyone else see a massive increase of scanning/dos with TCP source and/or >> dst port of 0? We started seeing a massive increase today creating some >> issue with our firewalls. > > Not seeing a ton of them, but do see a few logged on most all of our > server like: > > Mar ?5 07:49:13 server kernel: Shorewall:logflags:DROP:IN=eth2 OUT= > MAC=00:07:e9:0f:39:f1:00:03:31:a5:74:00:08:00 SRC=178.18.16.101 > DST=x.x.x.x LEN=56 TOS=0x00 PREC=0x00 TTL=204 ID=49665 DF PROTO=TCP > SPT=0 DPT=0 WINDOW=37009 RES=0x14 URG ACK RST SYN FIN URGP=37422 > > > > > > -- > Chris Stone > AxisInternet, Inc. > www.axint.net > -- -george william herbert george.herbert at gmail.com From gchalmers at gmail.com Wed Mar 7 16:55:29 2012 From: gchalmers at gmail.com (Greg Chalmers) Date: Thu, 8 Mar 2012 09:55:29 +1100 Subject: did AS174 and AS4134 de-peer? In-Reply-To: References: Message-ID: On Thu, Mar 8, 2012 at 9:34 AM, Jim Cowie wrote: > On Wed, Mar 7, 2012 at 2:23 AM, John van Oppen >wrote: > > > All - > > > > I was noticing that it appears from our Seattle-based full route feed > from > > cogent that they may have de-peered AS4134 (or vise-versa)... anyone > know > > anything about this? We noticed this recently in a shift of traffic > away > > from cogent for traffic to and from china telecom... Now cogent's path > is > > _174_1239_4134_. > > > > > Indeed: > http://www.renesys.com/blog/2012/03/cogent-depeers-china-telecom.shtml > > cheers, --jim > Isn't this journalism a bit yellow? No facts / based on speculation.. - Greg From jasongurtz at npumail.com Wed Mar 7 17:06:25 2012 From: jasongurtz at npumail.com (Jason Gurtz) Date: Wed, 7 Mar 2012 18:06:25 -0500 Subject: POLL: Network and Service Status Pages In-Reply-To: <4F56A57F.7000903@ninjabadger.net> References: <31959529.3147.1330983602289.JavaMail.root@benjamin.baylink.com> <4F56A57F.7000903@ninjabadger.net> Message-ID: > http://www.outages.org/index.php/Anything_you_might_want_to_know_about_ab > s_exercises Mark V Shaney must have an account @ Outages ~JasonG From djahandarie at gmail.com Wed Mar 7 17:19:25 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Wed, 7 Mar 2012 18:19:25 -0500 Subject: did AS174 and AS4134 de-peer? In-Reply-To: References: Message-ID: On Wed, Mar 7, 2012 at 17:55, Greg Chalmers wrote: > On Thu, Mar 8, 2012 at 9:34 AM, Jim Cowie wrote: >> http://www.renesys.com/blog/2012/03/cogent-depeers-china-telecom.shtml >> >> cheers, ? --jim >> > > > Isn't this journalism a bit yellow? No facts / based on speculation.. > > - Greg Now all they need to do is link back to this NANOG thread as a source. -- Darius Jahandarie From nick at foobar.org Wed Mar 7 17:29:20 2012 From: nick at foobar.org (Nick Hilliard) Date: Wed, 7 Mar 2012 23:29:20 +0000 Subject: did AS174 and AS4134 de-peer? In-Reply-To: References: Message-ID: <20CA91EF-62E5-4282-97A2-3AE8C6B39938@foobar.org> On 7 Mar 2012, at 23:19, Darius Jahandarie wrote: > On Wed, Mar 7, 2012 at 17:55, Greg Chalmers wrote: >> >> Isn't this journalism a bit yellow? No facts / based on speculation.. >> >> - Greg > > Now all they need to do is link back to this NANOG thread as a source. That would be very irresponsible. Otoh, if someone updated the tier1 network page on Wikipedia first... Nick From patrick at ianai.net Wed Mar 7 17:33:21 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 7 Mar 2012 18:33:21 -0500 Subject: did AS174 and AS4134 de-peer? In-Reply-To: <20CA91EF-62E5-4282-97A2-3AE8C6B39938@foobar.org> References: <20CA91EF-62E5-4282-97A2-3AE8C6B39938@foobar.org> Message-ID: <1BBDC626-0835-495B-A3D1-0FB9C4BCBC0B@ianai.net> On Mar 7, 2012, at 18:29 , Nick Hilliard wrote: > On 7 Mar 2012, at 23:19, Darius Jahandarie wrote: >> On Wed, Mar 7, 2012 at 17:55, Greg Chalmers wrote: >>> >>> Isn't this journalism a bit yellow? No facts / based on speculation.. >>> >>> - Greg >> >> Now all they need to do is link back to this NANOG thread as a source. > > That would be very irresponsible. Otoh, if someone updated the tier1 network page on Wikipedia first... There is no change to the list. Cogent still does not have transit. Cogent sees CT through Sprint (a peer) because CT pays Sprint for transit. OTOH, Jim did say in his blog post: "This disconnection will increase China Telecom's transit costs...." This assumes facts not in evidence, namely that the CT <-> Sprint pipes were not full before the de-peering incident. -- TTFN, patrick From cowie at renesys.com Wed Mar 7 18:06:12 2012 From: cowie at renesys.com (Jim Cowie) Date: Wed, 7 Mar 2012 19:06:12 -0500 Subject: did AS174 and AS4134 de-peer? In-Reply-To: <1BBDC626-0835-495B-A3D1-0FB9C4BCBC0B@ianai.net> References: <20CA91EF-62E5-4282-97A2-3AE8C6B39938@foobar.org> <1BBDC626-0835-495B-A3D1-0FB9C4BCBC0B@ianai.net> Message-ID: On Wed, Mar 7, 2012 at 6:33 PM, Patrick W. Gilmore wrote: > On Mar 7, 2012, at 18:29 , Nick Hilliard wrote: > > On 7 Mar 2012, at 23:19, Darius Jahandarie > wrote: > >> On Wed, Mar 7, 2012 at 17:55, Greg Chalmers > wrote: > >>> > >>> Isn't this journalism a bit yellow? No facts / based on speculation.. > >>> > >>> - Greg > >> > >> Now all they need to do is link back to this NANOG thread as a source. > > > > That would be very irresponsible. Otoh, if someone updated the tier1 > network page on Wikipedia first... > > There is no change to the list. Cogent still does not have transit. > Cogent sees CT through Sprint (a peer) because CT pays Sprint for transit. > > OTOH, Jim did say in his blog post: "This disconnection will increase > China Telecom's transit costs...." This assumes facts not in evidence, > namely that the CT <-> Sprint pipes were not full before the de-peering > incident. > > Heh. I think Doug was pretty clear in his summary of the observed facts, at least. There was a healthy, longstanding routing adjacency, observed by all. Right sharp at the top of the hour (10:00pm in China, 9:00am Eastern time), that connection disappears from global view. Afterward, the percentage of the Renesys peer base that likes transit paths to CT through Sprint ticks up modestly. The real story there is hidden in that traceroute latency plot. Look how neatly it bifurcates post-event into paths through Sprint and paths through Level3. Notice that paths through Level3 tend to have slightly lower latencies and significantly less volatility. Infer what you will about the congestion on the Sprint-CT pipe. As a meta-comment: this "Quick Look" style of blog is an experiment we're trying, based on feedback that the community wanted to hear about more of these little events as they happen. In a Quick Look, we're giving the facts as they are known from initial measurement, and a very quick summary of our preliminary analysis of the incident. Then we throw the topic open to comments from those who might have the clues to the rest of the story ... cheers, --jim From patrick at ianai.net Wed Mar 7 18:10:50 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 7 Mar 2012 19:10:50 -0500 Subject: did AS174 and AS4134 de-peer? In-Reply-To: References: <20CA91EF-62E5-4282-97A2-3AE8C6B39938@foobar.org> <1BBDC626-0835-495B-A3D1-0FB9C4BCBC0B@ianai.net> Message-ID: On Mar 7, 2012, at 19:06 , Jim Cowie wrote: > As a meta-comment: this "Quick Look" style of blog is an experiment we're trying, based on feedback that the community wanted to hear about more of these little events as they happen. In a Quick Look, we're giving the facts as they are known from initial measurement, and a very quick summary of our preliminary analysis of the incident. Then we throw the topic open to comments from those who might have the clues to the rest of the story ... Well, this member of the community appreciates it. -- TTFN, patrick From michael at rancid.berkeley.edu Wed Mar 7 18:37:37 2012 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 07 Mar 2012 16:37:37 -0800 Subject: did AS174 and AS4134 de-peer? In-Reply-To: References: <20CA91EF-62E5-4282-97A2-3AE8C6B39938@foobar.org> <1BBDC626-0835-495B-A3D1-0FB9C4BCBC0B@ianai.net> Message-ID: <4F57FF51.6060205@rancid.berkeley.edu> On 03/07/12 16:10, Patrick W. Gilmore wrote: > On Mar 7, 2012, at 19:06 , Jim Cowie wrote: > >> As a meta-comment: this "Quick Look" style of blog is an experiment we're trying, based on feedback that the community wanted to hear about more of these little events as they happen. In a Quick Look, we're giving the facts as they are known from initial measurement, and a very quick summary of our preliminary analysis of the incident. Then we throw the topic open to comments from those who might have the clues to the rest of the story ... > > Well, this member of the community appreciates it. > +1 I find the combination of facts and inferences presented to be interesting and useful. michael From ml at kenweb.org Wed Mar 7 19:31:33 2012 From: ml at kenweb.org (ML) Date: Wed, 07 Mar 2012 20:31:33 -0500 Subject: Digi TS8 serial console server funkiness Message-ID: <4F580BF5.20303@kenweb.org> Hopefully someone here has wrestled with serial server oddities and can shed some light on this... I've got a serial console server made by Digi (TS8 PortServer) setup in a fairly vanilla mode: 9600-8-N-1....telnet to port 500X gets you to port X. Setup for a vt100 terminal type. Other VTs I tried didn't seem to make a difference. Problem is when attached to a Cisco switch I had laying around I get seemily random garble output when accessing the console of a remote Cisco device. (e.g. "show run" will get a few garbled lines halfway through, Holding down Enter will produce some garbled text every few lines). When attached to a Juniper device everything appears normal. The problem follows the port if I swap the Cisco device to the port the J-box was on. Other issues I've noticed..cannot use arrow keys to search command buffer. My Google-fu is failing me in coming up with the right name for the effect I'm seeing... Thanks From gbonser at seven.com Wed Mar 7 20:53:48 2012 From: gbonser at seven.com (George Bonser) Date: Thu, 8 Mar 2012 02:53:48 +0000 Subject: Digi TS8 serial console server funkiness In-Reply-To: <4F580BF5.20303@kenweb.org> References: <4F580BF5.20303@kenweb.org> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D0A25B@RWC-MBX1.corp.seven.com> > -----Original Message----- > From: ML [mailto:ml at kenweb.org] > Sent: Wednesday, March 07, 2012 5:32 PM > To: nanog at nanog.org > Subject: Digi TS8 serial console server funkiness > > Problem is when attached to a Cisco switch I had laying around I get > seemily random garble output when accessing the console of a remote > Cisco device. (e.g. "show run" will get a few garbled lines halfway > through, Holding down Enter will produce some garbled text every few > lines). > Can you configure the port (on the switch and the console server) for flow control? You might be experiencing an overflow issue if the CPU of the terminal server gets busy or a buffer gets full. Maybe RTS/CTS (if the cable has the pins) or even XON/XOFF (if it doesn't). From gbonser at seven.com Wed Mar 7 21:06:04 2012 From: gbonser at seven.com (George Bonser) Date: Thu, 8 Mar 2012 03:06:04 +0000 Subject: Digi TS8 serial console server funkiness In-Reply-To: <4F580BF5.20303@kenweb.org> References: <4F580BF5.20303@kenweb.org> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D0A276@RWC-MBX1.corp.seven.com> > > Other issues I've noticed..cannot use arrow keys to search command > buffer. This is going to be a tougher one. Might be a difference in character encoding. Here is the VT100 spec: http://www.handshake.de/infobase/dfue/prgrmmer/t322.htm * ESC D cursor down - at bottom of region, scroll up * ESC M cursor up - at top of region, scroll down ... Arrows Standard Applications IBM Keypad Up ESC [ A ESC O A Alt 9 Down ESC [ B ESC O B Alt 0 Right ESC [ C ESC O C Alt - Left ESC [ D ESC O D Alt = So you probably need to check your keyboard encoding. It likely differs from VT100 escape sequences. Also, if you have several devices connected to that terminal server, see if you have one that is spewing debug or other information out the console port. That one might be causing some buffer overrun situations or keeping the CPU busy so it loses characters. Line noise can cause garbled data, too. But I would try flow control first. One thing I have seen before also is ground loops causing issues. Some serial devices actually tie signal ground to chassis ground. If you have a cable connecting two such devices and there is some ground potential difference, you can create a ground loop and introduce noise (and things like sparks, fire, blown fuses, etc.) if the ground potential difference is great enough between the two devices. From george.herbert at gmail.com Wed Mar 7 23:36:41 2012 From: george.herbert at gmail.com (George Herbert) Date: Wed, 7 Mar 2012 21:36:41 -0800 Subject: PLEASE don't feed the troll In-Reply-To: <1331133953.65419.YahooMailNeo@web121606.mail.ne1.yahoo.com> References: <15861941.3695.1331133478509.JavaMail.root@benjamin.baylink.com> <1331133953.65419.YahooMailNeo@web121606.mail.ne1.yahoo.com> Message-ID: Isabel - It does not take a PhD in computer science to understand networks or network protocol design. It does not take a PhD to understand that the troll's particular proposal was not a competent well-founded contribution. On Wed, Mar 7, 2012 at 7:25 AM, isabel dias wrote: > are you a PhD? otherwise you are not making sence > > > > ________________________________ > ?From: Jay Ashworth > To: NANOG > Sent: Wednesday, March 7, 2012 3:17 PM > Subject: PLEASE don't feed the troll > > Nuff said? > > Cheers, > -- jra > -- > Jay R. Ashworth? ? ? ? ? ? ? ? ? Baylink? ? ? ? ? ? ? ? ? ? ? jra at baylink.com > Designer? ? ? ? ? ? ? ? ? ? ?The Things I Think? ? ? ? ? ? ? ? ? ? ? ?RFC 2100 > Ashworth & Associates? ? ?http://baylink.pitas.com? ? ? ? ?2000 Land Rover DII > St Petersburg FL USA? ? ? http://photo.imageinc.us? ? ? ? ? ? ?+1 727 647 1274 -- -george william herbert george.herbert at gmail.com From frnkblk at iname.com Thu Mar 8 00:20:07 2012 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 8 Mar 2012 00:20:07 -0600 Subject: facebook lost their A-record for www.facebook.com? In-Reply-To: References: Message-ID: <070d01ccfcf3$84629f10$8d27dd30$@iname.com> They had issues in Europe today: http://www.telegraph.co.uk/technology/facebook/9128716/Facebook-hit-by-two-h our-blackout.html http://www.washingtonpost.com/business/technology/facebook-back-up-after-eur ope-outage/2012/03/07/gIQAJnNuwR_story.html Frank -----Original Message----- From: Anurag Bhatia [mailto:me at anuragbhatia.com] Sent: Wednesday, March 07, 2012 2:52 AM To: Octavio Alvarez Cc: NANOG Mailing List Subject: Re: facebook lost their A-record for www.facebook.com? Good point Octavio . +trace with dig is always useful when getting weird results. (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Mar 7, 2012 1:19 PM, "Octavio Alvarez" wrote: > On Tue, 06 Mar 2012 23:43:07 -0800, Igor Ybema wrote: > > [igor at vds ~]$ host -t A www.facebook.com ns1.facebook.com >> Using domain server: >> Name: ns1.facebook.com >> Address: 204.74.66.132#53 >> Aliases: >> >> www.facebook.com has no A record >> > > No, it's a subdomain with its A records in another server. > > $ host -t A www.facebook.com glb1.facebook.com. > Using domain server: > Name: glb1.facebook.com. > Address: 69.171.239.10#53 > Aliases: > > www.facebook.com has address 69.171.224.12 > > > Try dig +trace www.facebook.com to see why. > > > > -- > Octavio. > > Twitter: @alvarezp2000 -- Identi.ca: @alvarezp > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6517 bytes Desc: not available URL: From joinajay1 at gmail.com Thu Mar 8 03:55:26 2012 From: joinajay1 at gmail.com (Ajay Kumar) Date: Thu, 8 Mar 2012 15:25:26 +0530 Subject: RANCID script for monitoring the routes received from peers. Message-ID: Hello, We are running IX in India.Has some one written script for monitoring the routes announcement from peers?If yes,would you like to share code with me.It can be done via one script under the framework of RANCID.I want to know difference of routes,which has been added or removed. Thanks in advance. Regards, Ajay Kumar From regnauld at nsrc.org Thu Mar 8 04:47:28 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 8 Mar 2012 11:47:28 +0100 Subject: RANCID script for monitoring the routes received from peers. In-Reply-To: References: Message-ID: <20120308104728.GB20871@macbook.bluepipe.net> Ajay Kumar (joinajay1) writes: > Hello, > > We are running IX in India.Has some one written script for monitoring the > routes announcement from peers?If yes,would you like to share code with > me.It can be done via one script under the framework of RANCID.I want to > know difference of routes,which has been added or removed. > Thanks in advance. > Regards, > Ajay Kumar Hi Ajay, Are you running IOS, JunOS, something else ? You could do it via Rancid, using *login scripts. But there are ways to do this using SNMP and BGP mibs: http://www.oidview.com/mibs/0/BGP4-MIB.html http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-BGP4-MIB Note that the network monitoring platform Observium has built-in support for tracking BGP sessions. Finally, another way to do this that could spare the CPU on on your routers if you run this often would be to setup a peer running Quagga (or BIRD) on a Linux/BSD host and run the monitoring there. Cheers, Phil From mtinka at globaltransit.net Thu Mar 8 05:34:03 2012 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 8 Mar 2012 19:34:03 +0800 Subject: [c-nsp] ASR opinions.. In-Reply-To: References: <201202011150.48562.mtinka@globaltransit.net> Message-ID: <201203081934.04261.mtinka@globaltransit.net> On Wednesday, February 08, 2012 11:28:24 PM Arie Vayner wrote: > Mark, Hello Arie. Sorry for the very late reply. > I made sure with the BU, and they confirmed that ASR1001 > with 8GB RAM can handle 1M routes per the data sheet. Are we talking 1,000,000 FIB entries, as I don't see how control plane RAM can influence FIB capacity in this particular case :-)? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From ariev at vayner.net Thu Mar 8 06:22:55 2012 From: ariev at vayner.net (Arie Vayner) Date: Thu, 8 Mar 2012 14:22:55 +0200 Subject: [c-nsp] ASR opinions.. In-Reply-To: <201203081934.04261.mtinka@globaltransit.net> References: <201202011150.48562.mtinka@globaltransit.net> <201203081934.04261.mtinka@globaltransit.net> Message-ID: Mark, I guess it has to do with the fact that every FIB entry also has a data structure on the RP, as control plane has to calculate the FIB (i.e. CEF...) and then copy the result into the forwarding plane (ESP). Arie On Thu, Mar 8, 2012 at 1:34 PM, Mark Tinka wrote: > On Wednesday, February 08, 2012 11:28:24 PM Arie Vayner > wrote: > > > Mark, > > Hello Arie. > > Sorry for the very late reply. > > > I made sure with the BU, and they confirmed that ASR1001 > > with 8GB RAM can handle 1M routes per the data sheet. > > Are we talking 1,000,000 FIB entries, as I don't see how > control plane RAM can influence FIB capacity in this > particular case :-)? > > Mark. > From nick at foobar.org Thu Mar 8 07:02:11 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 08 Mar 2012 13:02:11 +0000 Subject: RANCID script for monitoring the routes received from peers. In-Reply-To: <20120308104728.GB20871@macbook.bluepipe.net> References: <20120308104728.GB20871@macbook.bluepipe.net> Message-ID: <4F58ADD3.8050904@foobar.org> On 08/03/2012 10:47, Phil Regnauld wrote: > Finally, another way to do this that could spare the CPU on on > your routers if you run this often would be to setup a peer running > Quagga (or BIRD) on a Linux/BSD host and run the monitoring there. that will only provide the calculated prefix entries from the RIB, not the received-routes from each host. I.e. it's not necessarily going to be 100% accurate. Nick From eric at roxanne.org Thu Mar 8 07:02:48 2012 From: eric at roxanne.org (Eric) Date: Thu, 8 Mar 2012 08:02:48 -0500 Subject: did AS174 and AS4134 de-peer? In-Reply-To: <4F57FF51.6060205@rancid.berkeley.edu> References: <20CA91EF-62E5-4282-97A2-3AE8C6B39938@foobar.org> <1BBDC626-0835-495B-A3D1-0FB9C4BCBC0B@ianai.net> <4F57FF51.6060205@rancid.berkeley.edu> Message-ID: <8C995EB9-8344-43FB-9E9C-D764DA536224@roxanne.org> +1 - Eric On Mar 7, 2012, at 7:37 PM, Michael Sinatra wrote: > On 03/07/12 16:10, Patrick W. Gilmore wrote: >> On Mar 7, 2012, at 19:06 , Jim Cowie wrote: >> >>> As a meta-comment: this "Quick Look" style of blog is an experiment we're trying, based on feedback that the community wanted to hear about more of these little events as they happen. In a Quick Look, we're giving the facts as they are known from initial measurement, and a very quick summary of our preliminary analysis of the incident. Then we throw the topic open to comments from those who might have the clues to the rest of the story ... >> >> Well, this member of the community appreciates it. >> > > +1 > > I find the combination of facts and inferences presented to be interesting and useful. > > michael From mtinka at globaltransit.net Thu Mar 8 11:16:57 2012 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 9 Mar 2012 01:16:57 +0800 Subject: [c-nsp] ASR opinions.. In-Reply-To: References: <201203081934.04261.mtinka@globaltransit.net> Message-ID: <201203090117.01322.mtinka@globaltransit.net> On Thursday, March 08, 2012 08:22:55 PM Arie Vayner wrote: > Mark, > > I guess it has to do with the fact that every FIB entry > also has a data structure on the RP, as control plane > has to calculate the FIB (i.e. CEF...) and then copy the > result into the forwarding plane (ESP). So we're saying that the forwarding plane on the ASR1001 can handle 1,000,000 hardware entries out of the factory, but that you'll need to have the 8GB of control plane memory installed in the router to achieve that? Interesting. I'd have thought 4GB of control plane memory would be sufficient :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From paul4004 at gmail.com Thu Mar 8 11:25:11 2012 From: paul4004 at gmail.com (PC) Date: Thu, 8 Mar 2012 10:25:11 -0700 Subject: [c-nsp] ASR opinions.. In-Reply-To: References: <201109021756.56518.mtinka@globaltransit.net> <201202011150.48562.mtinka@globaltransit.net> Message-ID: The low end ASRs are poor boxes for full BGP table internet edge applications. They have many other great applications, but the reason they are bad here is simply route limits in the FIB. The asr1001 only supports 512,000 IPV4 routes in the FIB at any given point in time, and 128,000 IPV6 routes. The full IPV4 table will exceed that soon, and that will be well within the lifespan of the box. The 1 million figure is for route reflector applications only. On Wed, Feb 8, 2012 at 8:28 AM, Arie Vayner wrote: > Mark, > > I made sure with the BU, and they confirmed that ASR1001 with 8GB RAM can > handle 1M routes per the data sheet. > The difference between ASR1001 and ASR1002 with EFP5 is due to a more > powerful integrated RP on ASR1001 (Not really RP2, but closer to RP2 than > RP1) and more memory (4GB is max on RP1) > > Arie > > On Wed, Feb 1, 2012 at 5:50 AM, Mark Tinka > wrote: > > > On Tuesday, January 31, 2012 06:38:10 AM Christopher J. > > Pilkington wrote: > > > > > Does anyone have a link to a definitive document clearly > > > showing FIB numbers for the ASR1001? I've got an email > > > into our Cisco SE, but I don't think they're motivated > > > to sell us a lower-end box. :-) > > > > On that link, Tables 1 and 3 contradict each other re: the > > ASR1001. > > > > However, I confirmed with our SE, and he says no way the > > ASR1001 supports anything more than 512,000 v4 entries and > > 128,000 v6 entries (which is Table 3). > > > > Maybe someone on the list from Cisco can help fix the > > documentation. > > > > Mark. > > > From wiwi at progon.net Thu Mar 8 12:38:47 2012 From: wiwi at progon.net (Christian 'wiwi' Wittenhorst) Date: Thu, 08 Mar 2012 19:38:47 +0100 Subject: [c-nsp] ASR opinions.. In-Reply-To: References: <201109021756.56518.mtinka@globaltransit.net> <201202011150.48562.mtinka@globaltransit.net> Message-ID: <4F58FCB7.6060306@progon.net> On 2012-03-08 18:25, PC wrote: > The low end ASRs are poor boxes for full BGP table internet edge > applications. They have many other great applications, but the reason they > are bad here is simply route limits in the FIB. > > The asr1001 only supports 512,000 IPV4 routes in the FIB at any given point > in time, and 128,000 IPV6 routes. Current ASR1001 do NOT have that limitation: > Performance > * 1,000,000 IPv4 or 1,000,000 IPv6 routes > * BGP RR scalability to 2,000,000 IPv4/IPv6 routes > (using 4-GB memory) or 9,000,000 IPv4/IPv6 > routes (using 8-GB memory) From paul4004 at gmail.com Thu Mar 8 12:48:55 2012 From: paul4004 at gmail.com (PC) Date: Thu, 8 Mar 2012 11:48:55 -0700 Subject: [c-nsp] ASR opinions.. In-Reply-To: <4F58FCB7.6060306@progon.net> References: <201109021756.56518.mtinka@globaltransit.net> <201202011150.48562.mtinka@globaltransit.net> <4F58FCB7.6060306@progon.net> Message-ID: The numbers were based on when I spoke to our SE when considering purchasing one a couple years back. It sounds like they may have a revision 2 or new route processor out now which supports more under this model? In which case you should be ok, but I'd get it in writing from your rep to cover all your basis. On Thu, Mar 8, 2012 at 11:38 AM, Christian 'wiwi' Wittenhorst < wiwi at progon.net> wrote: > On 2012-03-08 18:25, PC wrote: > >> The low end ASRs are poor boxes for full BGP table internet edge >> applications. They have many other great applications, but the reason >> they >> are bad here is simply route limits in the FIB. >> >> The asr1001 only supports 512,000 IPV4 routes in the FIB at any given >> point >> in time, and 128,000 IPV6 routes. >> > > Current ASR1001 do NOT have that limitation: > > ps9343/data_sheet_c78-441072.**html > > > > > Performance > > * 1,000,000 IPv4 or 1,000,000 IPv6 routes > > * BGP RR scalability to 2,000,000 IPv4/IPv6 routes > > (using 4-GB memory) or 9,000,000 IPv4/IPv6 > > routes (using 8-GB memory) > From joesox at gmail.com Thu Mar 8 13:26:56 2012 From: joesox at gmail.com (JoeSox) Date: Thu, 8 Mar 2012 11:26:56 -0800 Subject: Juniper wlc8 vs HP ProCurve MSM710 Message-ID: Juniper WLC8 vs HP ProCurve MSM710 Any review to share? We are also looking at Cisco 5508 but spendy. Looking at 8 APs to start in one building then possible APs at 10 other locations. -- Thanks, Joe From hrlinneweh at sbcglobal.net Thu Mar 8 13:45:28 2012 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Thu, 8 Mar 2012 11:45:28 -0800 (PST) Subject: AS Connectivity Lookup In-Reply-To: <20120307191107.GA10219@gweep.net> References: <20120307191107.GA10219@gweep.net> Message-ID: <1331235928.9560.YahooMailNeo@web180303.mail.gq1.yahoo.com> I really miss completewhois, have not found a really good replacement -Henry ________________________________ From: Joe Provo To: "Radke, Justin" Cc: nanog at nanog.org Sent: Wednesday, March 7, 2012 11:11 AM Subject: Re: AS Connectivity Lookup On Wed, Mar 07, 2012 at 09:29:29AM -0800, Radke, Justin wrote: > How can I easily view the current peering relationship of a particular AS? > Assume the AS you are researching does not have a looking glass and you are > not going to do lookups from the top 10 providers route servers to get some > glimpse of their connectivity. In my particular search > bgplay.routeviews.org does > not have any information and as-rank.caida.org is out of date. In the past > there was a great website called webtrace.info but it is no longer online. > > Any suggestions? Any site you reference outside/not downstream of the desired AS will only provide you a partial picture.? Use many to try and create a holistic view.? So far it seems RIPE RIS hasn't yet been mentioned: http://www.ripe.net/data-tools/stats/ris/routing-information-service -- ? ? ? ? RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From betty at newnog.org Thu Mar 8 14:51:46 2012 From: betty at newnog.org (Betty Burke ) Date: Thu, 8 Mar 2012 15:51:46 -0500 Subject: [NANOG-announce] NANOG Meeting Updates Message-ID: Colleagues: I am pleased to report, NANOG 54 is archived, visit http://www.nanog.org/meetings/nanog54/index.php Now posted are the attendance stats http://www.nanog.org/meetings/nanog54/documents/NANOG54Statistics_web.pdf and survey results http://www.nanog.org/meetings/nanog54/surveys.html The NANOG presentations have been updated. We do have a few outstanding, and we will post those slides as soon as received. Lastly, the presentation video files are now linked to the agenda page http://www.nanog.org/meetings/nanog54/agenda.php A final thank you to our Host, Speakers, Sponsors, and attendees. You ALL are valuable contributors to the NANOG community and very much appreciated. I welcome everyone to visit our NANOG 55 website. Meeting planning is already underway! Do not wait, visit: http://www.nanog.org/meetings/nanog55/callforpresentations.html http://www.nanog.org/meetings/nanog55/nanog55_registration.html http://www.nanog.org/meetings/nanog55/hotel.html Lastly, we welcome all our sponsors to join us in Vancouver. If you have not yet sent in your request, please visit our website and let us know of your interest. http://www.nanog.org/sponsors/sponsorform/index.php See you in June! Sincerely, Betty -- Betty Burke NewNOG/NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 Office (810) 214-1218 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From lyndon at orthanc.ca Thu Mar 8 15:41:58 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 8 Mar 2012 13:41:58 -0800 Subject: cable markers for marine environments Message-ID: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> I have a couple of wiring projects coming up on salt water-going vessels and I'm curious as to people's experiences with different types of cable marking products in a high-humidity / salt air / bilge environment None of the markers will be directly exposed to the outside elements, but quite a bit will be running below decks and will have to put up with the bilge. Anyone have any horror stories to share? My preference is for a direct printing system rather than stock card markers. --lyndon From Justin.Dixon at BBandT.com Thu Mar 8 15:51:29 2012 From: Justin.Dixon at BBandT.com (Dixon, Justin) Date: Thu, 8 Mar 2012 21:51:29 +0000 Subject: AS Connectivity Lookup In-Reply-To: <1331235928.9560.YahooMailNeo@web180303.mail.gq1.yahoo.com> References: <20120307191107.GA10219@gweep.net> <1331235928.9560.YahooMailNeo@web180303.mail.gq1.yahoo.com> Message-ID: <52A4B7C174F4334C9C6D5BEE83775FD103786E@WIL-EXMBX11.bbtnet.com> > -----Original Message----- > From: Henry Linneweh [mailto:hrlinneweh at sbcglobal.net] > Sent: Thursday, March 08, 2012 14:45 > To: nanog at nanog.org > Subject: Re: AS Connectivity Lookup > > I really miss completewhois, have not found a really good replacement > > -Henry > > > > ________________________________ > From: Joe Provo > To: "Radke, Justin" > Cc: nanog at nanog.org > Sent: Wednesday, March 7, 2012 11:11 AM > Subject: Re: AS Connectivity Lookup > > On Wed, Mar 07, 2012 at 09:29:29AM -0800, Radke, Justin wrote: > > How can I easily view the current peering relationship of a particular > AS? > > Assume the AS you are researching does not have a looking glass and you > are > > not going to do lookups from the top 10 providers route servers to get > some > > glimpse of their connectivity. In my particular search > > bgplay.routeviews.org does > > not have any information and as-rank.caida.org is out of date. In the > past > > there was a great website called webtrace.info but it is no longer > online. > > > > Any suggestions? > > Any site you reference outside/not downstream of the desired > AS will only provide you a partial picture.? Use many to try > and create a holistic view.? So far it seems RIPE RIS hasn't > yet been mentioned: > http://www.ripe.net/data-tools/stats/ris/routing-information-service > > > -- > ? ? ? ? RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG http://cyclops.cs.ucla.edu/ From george.herbert at gmail.com Thu Mar 8 15:54:28 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 8 Mar 2012 13:54:28 -0800 Subject: cable markers for marine environments In-Reply-To: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> References: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> Message-ID: On Thu, Mar 8, 2012 at 1:41 PM, Lyndon Nerenberg wrote: > I have a couple of wiring projects coming up on salt water-going vessels and I'm curious as to people's experiences with different types of cable marking products in a high-humidity / salt air / bilge environment > > None of the markers will be directly exposed to the outside elements, but quite a bit will be running below decks and will have to put up with the bilge. ?Anyone have any horror stories to share? > > My preference is for a direct printing system rather than stock card markers. > > --lyndon Data wiring through the *bilge* ??? The naval architect in me is screaming and running in circles at the idea. Everything I've had to run through bilges, which involved power wiring (ugh) and various pipe systems, but not datacom cables, got messed up on the surface by the inevitable sludge of salt water and junk and oil in the bilges. Large painted stencils on pipes seem to survive, as to large printed plastic label tags. Most smaller printed tags like you'd use for circuit ID or wire ID in normal datacom/telco usage delaminated or melted eventually. Is this a temporary or permanent installation? If permanent, think about running anywhere else you can and conduiting and armored cables... -- -george william herbert george.herbert at gmail.com From mansaxel at besserwisser.org Thu Mar 8 15:57:55 2012 From: mansaxel at besserwisser.org (=?iso-8859-1?Q?M=E5ns?= Nilsson) Date: Thu, 8 Mar 2012 22:57:55 +0100 Subject: cable markers for marine environments In-Reply-To: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> References: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> Message-ID: <20120308215750.GF16111@besserwisser.org> On Thu, Mar 08, 2012 at 01:41:58PM -0800, Lyndon Nerenberg wrote: > I have a couple of wiring projects coming up on salt water-going vessels and I'm curious as to people's experiences with different types of cable marking products in a high-humidity / salt air / bilge environment > > None of the markers will be directly exposed to the outside elements, but quite a bit will be running below decks and will have to put up with the bilge. Anyone have any horror stories to share? > > My preference is for a direct printing system rather than stock card markers. Most durable is probably PVC cable markers of the type found in automation systems and similar; I've used them in live sound which is a very stressful environment. Several manufacturers make these; the resistor colourcode type is really great for quick ID of numeric identifiers. Typical offering: http://www.cablecraft.co.uk/file.php?filename=WebCat-0001002b00040003%2FEasi-Lok_Halogen_Free_Markers.pdf If you want to print, Brady has a number of different solutions, of which, at a quick glance, this one looks good: http://www.bradyid.com/bradyid/domino/contentView.do/B7643.html -- M?ns, the wannabe automation engineer. From weaselkeeper at gmail.com Thu Mar 8 16:01:36 2012 From: weaselkeeper at gmail.com (Jim Richardson) Date: Thu, 8 Mar 2012 14:01:36 -0800 Subject: cable markers for marine environments In-Reply-To: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> References: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> Message-ID: On Thu, Mar 8, 2012 at 1:41 PM, Lyndon Nerenberg wrote: > I have a couple of wiring projects coming up on salt water-going vessels and I'm curious as to people's experiences with different types of cable marking products in a high-humidity / salt air / bilge environment > > None of the markers will be directly exposed to the outside elements, but quite a bit will be running below decks and will have to put up with the bilge. ?Anyone have any horror stories to share? > > My preference is for a direct printing system rather than stock card markers. > > --lyndon > > I have had good results with printed labels covered in clear heatshrink. Awkward, time consuming, and generally annoying, but works, and lasts. Keep the label short, print big, and use marine (glue lined) heatshrink for best waterproofing. The regular stuff can allow seepage and mould growth under the heatshrink in extreme cases. -- http://neon-buddha.net From egon at egon.cc Thu Mar 8 16:02:16 2012 From: egon at egon.cc (James Downs) Date: Thu, 8 Mar 2012 14:02:16 -0800 Subject: cable markers for marine environments In-Reply-To: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> References: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> Message-ID: <98FF9FED-4E5A-4CF3-9F82-0716AD54B785@egon.cc> On Mar 8, 2012, at 1:41 PM, Lyndon Nerenberg wrote: > My preference is for a direct printing system rather than stock card markers. Don't bother. Unless something revolutionary has come out recently, attach-on-to products are the only way to go. In my experience all the labels have to be maintained along with everything else that's in contact with that environment/liquid. Use something plastic, larger is better, and plan to be able to replace them as necessary. Cheers, -j From lyndon at orthanc.ca Thu Mar 8 16:09:46 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 8 Mar 2012 14:09:46 -0800 Subject: cable markers for marine environments In-Reply-To: References: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> Message-ID: <00F0FAC4-394F-4493-A43F-E851440FE922@orthanc.ca> On 2012-03-08, at 2:01 PM, Jim Richardson wrote: > I have had good results with printed labels covered in clear > heatshrink. Awkward, time consuming, and generally annoying, but > works, and lasts. A bit more detail I should have included ... These are pleasure craft, so stuff goes under the deck whether we like it or not. I've been using markable heat shrink, but as Jim says, it's very time consuming and awkward, so I was hoping for something better. I have tried a few of the wrap-around plastic write-on types, but the glue doesn't hold very long in the damp environment. I'm hoping to find a printable plastic wrap-around with a glue that will stick in the damp, as it would let me pre-print everything before the job. --lyndon From lyndon at orthanc.ca Thu Mar 8 16:11:15 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 8 Mar 2012 14:11:15 -0800 Subject: cable markers for marine environments In-Reply-To: References: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> <61451BD4-5422-47DF-B724-E30F271FA9E7@orthanc.ca> Message-ID: <7717D3A0-B07A-4699-B2AC-84ED7E469DA6@orthanc.ca> On 2012-03-08, at 2:10 PM, George Herbert wrote: > Which fuel is present affects the label durability... Diesel. From george.herbert at gmail.com Thu Mar 8 16:13:17 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 8 Mar 2012 14:13:17 -0800 Subject: cable markers for marine environments In-Reply-To: <00F0FAC4-394F-4493-A43F-E851440FE922@orthanc.ca> References: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> <00F0FAC4-394F-4493-A43F-E851440FE922@orthanc.ca> Message-ID: Under the circumstances... I would tend to do a two-phase solution. 1. At both ends, above the bilge area, put the most durable printed labels you can find. 2. Both at the ends, and intermittently under the deck, use a coded ID number for each cable using those slip-on crimp-on types (the cablecraft ones someone pointed to a bit upthread). You won't have the full label in the middle, but you can look at any endpoint and get the description and the cable's individual ID tag, and then trace the tag numbers in the bilge. On Thu, Mar 8, 2012 at 2:09 PM, Lyndon Nerenberg wrote: > > On 2012-03-08, at 2:01 PM, Jim Richardson wrote: > >> I have had good results with printed labels covered in clear >> heatshrink. ?Awkward, time consuming, and generally annoying, but >> works, and lasts. > > A bit more detail I should have included ... > > These are pleasure craft, so stuff goes under the deck whether we like it or not. > > I've been using markable heat shrink, but as Jim says, it's very time consuming and awkward, so I was hoping for something better. ?I have tried a few of the wrap-around plastic write-on types, but the glue doesn't hold very long in the damp environment. > > I'm hoping to find a printable plastic wrap-around with a glue that will stick in the damp, as it would let me pre-print everything before the job. > > --lyndon > > -- -george william herbert george.herbert at gmail.com From lowen at pari.edu Thu Mar 8 16:24:05 2012 From: lowen at pari.edu (Lamar Owen) Date: Thu, 8 Mar 2012 17:24:05 -0500 Subject: Programmers with network engineering skills In-Reply-To: References: Message-ID: <201203081724.05236.lowen@pari.edu> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote: > > Other common, but misguided assumptions (even in 2012): > > 1. You will be using IPv4. We have no idea what this IPv6 nonsense is. > > Looks complicated and scary. > > 2. 255.255.255.0 is the only valid netmask. ... > (16) The default gateway's IP address is always 192.168.0.1 > (17) The user portion of E-mail addresses never contain special > characters like "-" "+" "$" "~" "." ",", "[", "]" Hilarious. Wish I'd seen this a few days ago, my whole week would have been brighter.... I'll add one from my 'I asked the programmer about a problem in the code, which the programmer proceeded to say wasn't a problem' list: (18) No, our control protocol doesn't have authentication, it's up to the network to keep undesired users out. (I won't say what this software is, but suffice to say the package in which it was a part cost over $250,000). From nick at foobar.org Thu Mar 8 16:31:25 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 08 Mar 2012 22:31:25 +0000 Subject: cable markers for marine environments In-Reply-To: <98FF9FED-4E5A-4CF3-9F82-0716AD54B785@egon.cc> References: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> <98FF9FED-4E5A-4CF3-9F82-0716AD54B785@egon.cc> Message-ID: <4F59333D.1080006@foobar.org> On 08/03/2012 22:02, James Downs wrote: > Don't bother. Unless something revolutionary has come out recently, > attach-on-to products are the only way to go. In my experience all the > labels have to be maintained along with everything else that's in > contact with that environment/liquid. Use something plastic, larger is > better, and plan to be able to replace them as necessary. yeah, srsly, marine bilges are horrendous environments, with their combination of persistent damp, salt and fuel oils. If it's of any interest, I got a bunch of consumer labels from www.goed-gemerkt.com a couple of years back for labelling baby milk bottles. They were interesting labels because the milk bottles were dumped into the dish-washer on average once every 1-2 days, but the the adhesive only began to detach from the first of them after about ~9 months. Some of them had the original labels 5 years later - I was pretty blown away by this, given what a hostile environment the inside of a dishwasher is. Anyway, they also do a line of printed stainless steel tags: https://www.goedgemerkt.nl/key-id-tags-detail.asp?productid=149 I haven't used these, but depending on the grade of stainless used here, and the type of chain used, they might be exactly what you're looking for. (There's an english translation of the web site too). a delighted previous customer of Goedgemerkt, Nick From mhuff at ox.com Thu Mar 8 17:40:40 2012 From: mhuff at ox.com (Matthew Huff) Date: Thu, 8 Mar 2012 18:40:40 -0500 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. Message-ID: <483E6B0272B0284BA86D7596C40D29F901928959AAB2@PUR-EXCH07.ox.com> Just got an email today to our account associated with our legacy ARIN address space. A firm "Precision Management of Texas" is interested in subleasing some of our IP space for "on-demand solutions for brand marketers and website promotion chiefly through email marketing". The one thing clear within the large amount of marketing-speach is they want "As is the nature of this business PM seeks to obtain as much diversity in the allocated IP space as possible, however the most important thing is the Subnets need to have no abuse history." Anyone else get solicited? They seem to be flexible "We can take the IPs via GRE or BGP or other such tunneling solution to where you have them announced. Alternatively we can advertise them ourselves on our network, saving you the back-haul. As a third solution we can take a server on your network with the following specs:..." ---- Matthew Huff? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 From ml-nanog090304q at elcsplace.com Thu Mar 8 18:25:09 2012 From: ml-nanog090304q at elcsplace.com (Ted Cooper) Date: Fri, 09 Mar 2012 10:25:09 +1000 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901928959AAB2@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F901928959AAB2@PUR-EXCH07.ox.com> Message-ID: <4F594DE5.6070107@elcsplace.com> On 09/03/12 09:40, Matthew Huff wrote: > Just got an email today to our account associated with our legacy > ARIN address space. A firm "Precision Management of Texas" is > interested in subleasing some of our IP space for "on-demand > solutions for brand marketers and website promotion chiefly through > email marketing". > > The one thing clear within the large amount of marketing-speach is > they want "As is the nature of this business PM seeks to obtain as > much diversity in the allocated IP space as possible, however the > most important thing is the Subnets need to have no abuse history." > > Anyone else get solicited? > > They seem to be flexible "We can take the IPs via GRE or BGP or other > such tunneling solution to where you have them announced. > Alternatively we can advertise them ourselves on our network, saving > you the back-haul. As a third solution we can take a server on your > network with the following specs:..." Translation of their request: "We'd like to use your IP address reputation to bypass spam filters by spreading our footprint out as much as possible and spam a few million people into the ground because we've ruined the reputation of every other IP address we've ever used. May we destroy your reputation?" From nenolod at systeminplace.net Thu Mar 8 18:42:49 2012 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 08 Mar 2012 18:42:49 -0600 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901928959AAB2@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F901928959AAB2@PUR-EXCH07.ox.com> Message-ID: <4F595209.2030202@systeminplace.net> Hi, On 3/8/2012 5:40 PM, Matthew Huff wrote: > Just got an email today to our account associated with our legacy ARIN address space. A firm "Precision Management of Texas" is interested in subleasing some of our IP space for "on-demand solutions for brand marketers and website promotion chiefly through email marketing". > > The one thing clear within the large amount of marketing-speach is they want "As is the nature of this business PM seeks to obtain as much diversity in the allocated IP space as possible, however the most important thing is the Subnets need to have no abuse history." > > Anyone else get solicited? > Yes, they have spammed me regarding some legacy space I control. > They seem to be flexible "We can take the IPs via GRE or BGP or other such tunneling solution to where you have them announced. Alternatively we can advertise them ourselves on our network, saving you the back-haul. As a third solution we can take a server on your network with the following specs:..." > To which my response was something along the lines of "no thanks." These guys just want your IPs so they can get around whatever IP reputation problem they have. It will most probably infect the rest of your netblock, as that is standard MO for any anti-abuse DNSBL. What is odd is -- they solicit anyone with legacy space, even if it's just a /24 worth, this is odd because they want you to provide them with more than one subnet, which probably means they want IPs on different /24 boundaries since some mail filtering systems use the /24 boundary. William From bill at herrin.us Thu Mar 8 18:47:09 2012 From: bill at herrin.us (William Herrin) Date: Thu, 8 Mar 2012 19:47:09 -0500 Subject: Programmers with network engineering skills In-Reply-To: <201203081724.05236.lowen@pari.edu> References: <201203081724.05236.lowen@pari.edu> Message-ID: On Thu, Mar 8, 2012 at 5:24 PM, Lamar Owen wrote: > (18) No, our control protocol doesn't have authentication, > it's up to the network to keep undesired users out. (I won't > say what this software is, but suffice to say the package > in which it was a part cost over $250,000). Ten years ago there was a database this was true of: Filemaker. It was designed to reside on a Windows network share but the files could be placed on a Linux server instead. If you chose option 2, you got a custom protocol presenting the database as an array of bytes consisting of the entire raw database file. Logging in meant that the Windows app read the the file header, jumped to the user/password section, read the users and passwords and compared with the one you supplied. The TCP-based protocol requested no authentication: it received only a byte offset and length in the raw file. A colleague and I were asked to install an ISP billing system (!!) built on top of this database. On objection, the ISP's owner insisted. I understood where he was coming from: he was a technical guy who built the then-existing system with scripting and an old DOS-based database which he alone could operate, requiring him to spend gobs of his time on the repetitive and thankless task of processing payments month after month after month after month. He damn well wanted a replacement and didn't much care what. Still... We ended up stuffing the billing app on to a Windows Terminal Server, rigging the server to run that app as the shell, and isolating the DB machine behind it. Office users connected to the virtual server rather than running the app locally. The web portal for the billing app was fun too: it had the standard stupidity where you change the sequential customer userid number in the URL and got the next user's data without having to authenticate as that user. We solved that one with a front end which handled auth and re-wrote the customer request to the heavily firewalled web portal. As I recall, we named the DB machine "HeartOfGold" because (A) it contained all the customers' financial data and (B) there was something improbable and more than a little crazy about how it came to house the billing system. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From surfer at mauigateway.com Thu Mar 8 18:56:00 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 8 Mar 2012 16:56:00 -0800 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. Message-ID: <20120308165600.A88561A2@m0005297.ppops.net> --- ml-nanog090304q at elcsplace.com wrote: From: Ted Cooper On 09/03/12 09:40, Matthew Huff wrote: > Just got an email today to our account associated with our legacy > ARIN address space. A firm "Precision Management of Texas" is > interested in subleasing some of our IP space for "on-demand > solutions for brand marketers and website promotion chiefly through > email marketing". "We'd like to use your IP address reputation to bypass spam filters by spreading our footprint out as much as possible and spam a few million people into the ground because we've ruined the reputation of every other IP address we've ever used. ---------------------------------------------------------- What Ted said. This is a dead giveaway: "on-demand solutions for brand marketers and website promotion chiefly through email marketing". There is no info regarding that company on search engines, either. That raises it to another level of suspicion. Don't help them. It sure would be nice to get names and look up who they really are, though... >;-) And, no I have not gotten one. scott From ggm at apnic.net Thu Mar 8 19:06:21 2012 From: ggm at apnic.net (George Michaelson) Date: Fri, 9 Mar 2012 11:06:21 +1000 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <20120308165600.A88561A2@m0005297.ppops.net> References: <20120308165600.A88561A2@m0005297.ppops.net> Message-ID: <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> no. you misunderstand. The value proposition is not spam: that works with unallocated space. The value proposition is gaming google page rank, by using widely spread and legitimately routed IPs to force your paying customers page rank high, by hits and references. This is a very high value business: one customer paying you big bucks, to have their web high in google pagerank. Not attacking a million mailboxes. In this model, the 'target' is google. The IPS need to come from classic, widespread IPs because google now count the source IP and can tell if you use a virtually hosted single IP to try and do this. I have a question: are we actually able to state this consumption of address is 'illegal' ? I personally judge it to be unethical, but that is not the same thing. -George PS since this goes to address policy, I need to declare that I work for an RIR but I am posting in a personal capacity and nothing I say is a reflection of any RIR address policy. I work in the research department, not in registry/allocations From johnl at iecc.com Thu Mar 8 19:20:41 2012 From: johnl at iecc.com (John Levine) Date: 9 Mar 2012 01:20:41 -0000 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> Message-ID: <20120309012041.89040.qmail@joyce.lan> >The value proposition is not spam: that works with unallocated space. You may well be right that their plan is to fake out page rank, but spammers also like address space that's been allocated for a long time. Spreading spam around to try to sneak under the radar is so common that it has a name, snowshoe spamming. R's, John From mhuff at ox.com Thu Mar 8 19:23:42 2012 From: mhuff at ox.com (Matthew Huff) Date: Thu, 8 Mar 2012 20:23:42 -0500 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> References: <20120308165600.A88561A2@m0005297.ppops.net> <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> Message-ID: Of course, we declined. I just thought it was worth posting so others might be alerted that this was going on. Hadn't known about the google page ranking SEO, but it makes sense On Mar 8, 2012, at 8:06 PM, "George Michaelson" wrote: > > no. you misunderstand. > > The value proposition is not spam: that works with unallocated space. > > The value proposition is gaming google page rank, by using widely spread and legitimately routed IPs to force your paying customers page rank high, by hits and references. This is a very high value business: one customer paying you big bucks, to have their web high in google pagerank. Not attacking a million mailboxes. > > In this model, the 'target' is google. The IPS need to come from classic, widespread IPs because google now count the source IP and can tell if you use a virtually hosted single IP to try and do this. > > I have a question: are we actually able to state this consumption of address is 'illegal' ? I personally judge it to be unethical, but that is not the same thing. > > -George > > PS since this goes to address policy, I need to declare that I work for an RIR but I am posting in a personal capacity and nothing I say is a reflection of any RIR address policy. I work in the research department, not in registry/allocations From tvhawaii at shaka.com Thu Mar 8 19:48:39 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 8 Mar 2012 15:48:39 -1000 Subject: cable markers for marine environments References: <196F580D-359A-4BFA-9EE9-C54FDE463F70@orthanc.ca> Message-ID: <6BDEEA4701D74C85837139C876C8FD80@owner59e1f1502> Lyndon Nerenberg wrote: > I have a couple of wiring projects coming up on salt water-going vessels and I'm curious as to people's experiences with > different types of cable marking products in a high-humidity / salt air / bilge environment > > None of the markers will be directly exposed to the outside elements, but quite a bit will be running below decks and > will have > to put up with the bilge. Anyone have any horror stories to share? > > My preference is for a direct printing system rather than stock card markers. > > --lyndon My Rhino labelmaker has printable, tubular, heat shrink cartridges in white and yellow w/black printing. --Michael From fred.clearwater at gmail.com Thu Mar 8 20:16:09 2012 From: fred.clearwater at gmail.com (Fred Clearwater) Date: Thu, 08 Mar 2012 19:16:09 -0700 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <20120308165600.A88561A2@m0005297.ppops.net> References: <20120308165600.A88561A2@m0005297.ppops.net> Message-ID: <4F5967E9.2070700@gmail.com> On 03/08/2012 05:56 PM, Scott Weeks wrote: > > --- ml-nanog090304q at elcsplace.com wrote: > From: Ted Cooper > > On 09/03/12 09:40, Matthew Huff wrote: >> Just got an email today to our account associated with our legacy >> ARIN address space. A firm "Precision Management of Texas" is >> interested in subleasing some of our IP space for "on-demand >> solutions for brand marketers and website promotion chiefly through >> email marketing". > "We'd like to use your IP address reputation to bypass spam filters by > spreading our footprint out as much as possible and spam a few million > people into the ground because we've ruined the reputation of every > other IP address we've ever used. > ---------------------------------------------------------- > > > What Ted said. This is a dead giveaway: > > "on-demand solutions for brand marketers and website promotion chiefly > through email marketing". > > There is no info regarding that company on search engines, either. > That raises it to another level of suspicion. Don't help them. It > sure would be nice to get names and look up who they really are, > though...>;-) > > And, no I have not gotten one. > > scott > > Seems this is not the first request for this "company" for space. http://lists.arin.net/pipermail/arin-ppml/2012-January/023891.html Fred From lyle at lcrcomputer.net Thu Mar 8 20:42:34 2012 From: lyle at lcrcomputer.net (Lyle Giese) Date: Thu, 08 Mar 2012 20:42:34 -0600 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901928959AAB2@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F901928959AAB2@PUR-EXCH07.ox.com> Message-ID: <4F596E1A.7000301@lcrcomputer.net> A quick Google search found: http://lists.arin.net/pipermail/arin-ppml/2012-January/023892.html Lyle Giese LCR Computer Services, Inc. On 03/08/12 17:40, Matthew Huff wrote: > Just got an email today to our account associated with our legacy ARIN address space. A firm "Precision Management of Texas" is interested in subleasing some of our IP space for "on-demand solutions for brand marketers and website promotion chiefly through email marketing". > > The one thing clear within the large amount of marketing-speach is they want "As is the nature of this business PM seeks to obtain as much diversity in the allocated IP space as possible, however the most important thing is the Subnets need to have no abuse history." > > Anyone else get solicited? > > They seem to be flexible "We can take the IPs via GRE or BGP or other such tunneling solution to where you have them announced. Alternatively we can advertise them ourselves on our network, saving you the back-haul. As a third solution we can take a server on your network with the following specs:..." > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > From jlewis at lewis.org Thu Mar 8 21:03:15 2012 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 8 Mar 2012 22:03:15 -0500 (EST) Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> References: <20120308165600.A88561A2@m0005297.ppops.net> <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> Message-ID: On Fri, 9 Mar 2012, George Michaelson wrote: > The value proposition is gaming google page rank, by using widely spread > and legitimately routed IPs to force your paying customers page rank > high, by hits and references. This is a very high value business: one > customer paying you big bucks, to have their web high in google > pagerank. Not attacking a million mailboxes. If that's all they want, why not get dedi/vp/cloud servers distributed all around the globe and use those for hosting the sites used to drive up page rank? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ggm at apnic.net Thu Mar 8 21:10:19 2012 From: ggm at apnic.net (George Michaelson) Date: Fri, 9 Mar 2012 13:10:19 +1000 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: References: <20120308165600.A88561A2@m0005297.ppops.net> <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> Message-ID: <14B85F94-1574-481A-BED6-4407DDABE51F@apnic.net> On 09/03/2012, at 1:03 PM, Jon Lewis wrote: > On Fri, 9 Mar 2012, George Michaelson wrote: > >> The value proposition is gaming google page rank, by using widely spread and legitimately routed IPs to force your paying customers page rank high, by hits and references. This is a very high value business: one customer paying you big bucks, to have their web high in google pagerank. Not attacking a million mailboxes. > > If that's all they want, why not get dedi/vp/cloud servers distributed all around the globe and use those for hosting the sites used to drive up page rank? > because by renting others space, they get the benefit of hiding in their otherwise normal traffic? plausible denyability? I don't know. I used over-pejorative language. this is probably not ALL they want to do, but I don't think the primary driver is spam, because spam generates a lower income stream, and has higher risks of being RBL or otherwise blocked, and can be achieved quickly by use of unrouted space. Also, what makes you think they aren't renting VPS? Or (for that matter) founding Virtual Hosting companies, and acquiring address for this purpose? Surely a wise strategy in this space is to have many strategies? -G PS same: since this goes to address policy, I need to declare that I work for an RIR but I am posting in a personal capacity and nothing I say is a reflection of any RIR address policy. I work in the research department, not in registry/allocations From george.herbert at gmail.com Thu Mar 8 21:35:04 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 8 Mar 2012 19:35:04 -0800 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <14B85F94-1574-481A-BED6-4407DDABE51F@apnic.net> References: <20120308165600.A88561A2@m0005297.ppops.net> <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> <14B85F94-1574-481A-BED6-4407DDABE51F@apnic.net> Message-ID: This tactic is extremely well known by spammers. Either sending from the blocks or hosting questionable client web (usually spammed URLs). There really isn't much else people try with this stuff. Yes, the space quickly goes on *BLs. They don't care; they get more and leave you holding the poop. Sent from my iPhone On Mar 8, 2012, at 19:10, George Michaelson wrote: > > On 09/03/2012, at 1:03 PM, Jon Lewis wrote: > >> On Fri, 9 Mar 2012, George Michaelson wrote: >> >>> The value proposition is gaming google page rank, by using widely spread and legitimately routed IPs to force your paying customers page rank high, by hits and references. This is a very high value business: one customer paying you big bucks, to have their web high in google pagerank. Not attacking a million mailboxes. >> >> If that's all they want, why not get dedi/vp/cloud servers distributed all around the globe and use those for hosting the sites used to drive up page rank? >> > > because by renting others space, they get the benefit of hiding in their otherwise normal traffic? plausible denyability? > > I don't know. I used over-pejorative language. this is probably not ALL they want to do, but I don't think the primary driver is spam, because spam generates a lower income stream, and has higher risks of being RBL or otherwise blocked, and can be achieved quickly by use of unrouted space. > > Also, what makes you think they aren't renting VPS? Or (for that matter) founding Virtual Hosting companies, and acquiring address for this purpose? > > Surely a wise strategy in this space is to have many strategies? > > -G > > PS same: since this goes to address policy, I need to declare that I work for an RIR but I am posting in a personal capacity and nothing I say is a reflection of any RIR address policy. I work in the research department, not in registry/allocations > > From johnl at iecc.com Thu Mar 8 21:56:31 2012 From: johnl at iecc.com (John Levine) Date: 9 Mar 2012 03:56:31 -0000 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <14B85F94-1574-481A-BED6-4407DDABE51F@apnic.net> Message-ID: <20120309035631.59078.qmail@joyce.lan> >do, but I don't think the primary driver is spam, because spam generates a lower >income stream, and has higher risks of being RBL or otherwise blocked, and can be >achieved quickly by use of unrouted space. I think you overestimate how technically sophisticated snowshoers are. I just don't see a lot of spam from hit and run route announcements. R's, John From ops.lists at gmail.com Thu Mar 8 22:14:30 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 9 Mar 2012 09:44:30 +0530 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> References: <20120308165600.A88561A2@m0005297.ppops.net> <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> Message-ID: The GRE tunnels part of it, together with email marketing, makes this likely to be a snowshoe spam operation. Sure it could be pagerank gaming, blog spamming etc. But on the balance it smells like snowshoe to me. --srs On Fri, Mar 9, 2012 at 6:36 AM, George Michaelson wrote: > > > The value proposition is not spam: that works with unallocated space. > > The value proposition is gaming google page rank, by using widely spread > and legitimately routed IPs to force your paying customers page rank high, > by hits and references. This is a very high value business: one customer > paying you big bucks, to have their web high in google pagerank. Not > attacking a million mailboxes. -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Thu Mar 8 22:16:37 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 9 Mar 2012 09:46:37 +0530 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <20120309035631.59078.qmail@joyce.lan> References: <14B85F94-1574-481A-BED6-4407DDABE51F@apnic.net> <20120309035631.59078.qmail@joyce.lan> Message-ID: On Fri, Mar 9, 2012 at 9:26 AM, John Levine wrote: > >do, but I don't think the primary driver is spam, because spam generates > a lower > >income stream, and has higher risks of being RBL or otherwise blocked, > and can be > >achieved quickly by use of unrouted space. > > I think you overestimate how technically sophisticated snowshoers are. > I just don't see a lot of spam from hit and run route announcements. > More like, they're as sophisticated as they need to be in their routing. All their sophistication goes into figuring out ISP spam filtering and bypassing it. Those phantom route incidents are more often than not associated with bot traffic, ddos etc rather than snowshoe spam. -- Suresh Ramasubramanian (ops.lists at gmail.com) From nanog2 at adns.net Thu Mar 8 23:08:41 2012 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Thu, 8 Mar 2012 23:08:41 -0600 Subject: RCN having DNS and Possibly other Issues nationwide Message-ID: RCN is having issues nationwide. So far reports are: Lehigh Valley, PA Chicago NYC Can't tell if its a routing problem or a DNS failure.... Hopefully not solar flares. From owen at delong.com Thu Mar 8 23:07:54 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Mar 2012 21:07:54 -0800 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: References: <20120308165600.A88561A2@m0005297.ppops.net> <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> Message-ID: <4899F603-44F0-48FC-B233-F8A6C4631946@delong.com> It's not as if those activities are mutually exclusive. Owen On Mar 8, 2012, at 8:14 PM, Suresh Ramasubramanian wrote: > The GRE tunnels part of it, together with email marketing, makes this > likely to be a snowshoe spam operation. > > Sure it could be pagerank gaming, blog spamming etc. But on the balance > it smells like snowshoe to me. > > --srs > > On Fri, Mar 9, 2012 at 6:36 AM, George Michaelson wrote: > >> >> >> The value proposition is not spam: that works with unallocated space. >> >> The value proposition is gaming google page rank, by using widely spread >> and legitimately routed IPs to force your paying customers page rank high, >> by hits and references. This is a very high value business: one customer >> paying you big bucks, to have their web high in google pagerank. Not >> attacking a million mailboxes. > > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Thu Mar 8 23:22:13 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 9 Mar 2012 10:52:13 +0530 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <4899F603-44F0-48FC-B233-F8A6C4631946@delong.com> References: <20120308165600.A88561A2@m0005297.ppops.net> <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> <4899F603-44F0-48FC-B233-F8A6C4631946@delong.com> Message-ID: No. And often you find "dirty" blocks reused by a few ISPs for other, non email purposes - like once they finally boot a snowshoer off, they take on a blog spammer or something of the sort. On Fri, Mar 9, 2012 at 10:37 AM, Owen DeLong wrote: > It's not as if those activities are mutually exclusive. > > > Owen > > On Mar 8, 2012, at 8:14 PM, Suresh Ramasubramanian wrote: > > > The GRE tunnels part of it, together with email marketing, makes this > > likely to be a snowshoe spam operation. > > > > Sure it could be pagerank gaming, blog spamming etc. But on the balance > > it smells like snowshoe to me. > -- Suresh Ramasubramanian (ops.lists at gmail.com) From me at anuragbhatia.com Thu Mar 8 23:51:16 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 9 Mar 2012 11:21:16 +0530 Subject: Questions about anycasting setup Message-ID: Hello everyone. I am working on creating a small anycasting based setup with 3-4 servers in US. Plan is to use this for DNS and later for CDN setups. I have few confusions in mind and was wondering if you guys here can put some light on them: 1. For anycasting does announcing a /24 from different ASNs (of different datacenters) makes sense or it will be an issue to have a block being announced from different ASNs and I should avoid and prefer having own router below datacenters network and eventually use one single ASN to announce the anycasting block? 2. We plan to use this anycasting based setup for DNS during initial few months. Assuming low traffic for DNS say ~10Mbps on average (on 100Mbps port) and transit from just single network (datacenter itself) - is this setup OK for simple software based BGP like Quagga or Bird? Certainly colocating routers will be slow & expensive. Does it offer any direct advantage in such simple setups? 3. IPv6! - I am looking at possibility of having support of IPv6 in anycast right from start. Can't really find a good prefix size for anycasting announcement. I can see Hurricane Electric as well as Google using whole /32 block for IPv6. So is /32 is standard? We have only one /32 allocation from ARIN and thus if using /32 seems like hard deal - we have to likely get another /32 just for anycasting? or we can use /48 without issues? Also, is /48 a good number for breaking /32 so that we can do /48 announcements from different datacenters in simple uni casting setup? I apologize for any wrong questions/logic - really new to this. Please correct me if I am wrong on any concept. Appreciate your help. Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From woody at pch.net Fri Mar 9 00:54:32 2012 From: woody at pch.net (Bill Woodcock) Date: Thu, 8 Mar 2012 22:54:32 -0800 Subject: Questions about anycasting setup In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, Anurag. On Mar 8, 2012, at 9:51 PM, Anurag Bhatia wrote: > 1. For anycasting does announcing a /24 from different ASNs (of > different datacenters) makes sense or it will be an issue to have a block > being announced from different ASNs? Keeping a consistent announcing ASN for your prefix is thought to be best-practice, and if you don't do so, eventually there will be people who will undoubtedly complain, but there is no technical difficulty with announcing your same prefix from multiple origin ASNs. Any difficulties you encounter will be because of people aggressively filtering what they choose to listen to. > 2. We plan to use this anycasting based setup for DNS during initial few > months. Assuming low traffic for DNS say ~10Mbps on average (on 100Mbps > port) and transit from just single network (datacenter itself) - is this > setup OK for simple software based BGP like Quagga or Bird? Yes, and in fact, that's how nearly all large production anycast networks are built? Each anycast instance contains its own BGP speaker, which announces its service prefix to adjacent BGP-speaking routers, whether those be your own, or your transit-provider's. Doing exactly as you describe is, in fact, best-practice. > 3. IPv6! - Is /32 is standard? We have only one /32 > allocation from ARIN and thus if using /32 seems like hard deal - we have > to likely get another /32 just for anycasting? or we can use /48 without > issues? Also, is /48 a good number for breaking /32 so that we can do /48 > announcements from different datacenters in simple uni casting setup? A /48 is quite reasonable. Announcing a whole /32 just for your anycast service would be wasteful. Good luck! -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPWakoAAoJEG+kcEsoi3+HQp8P+gORNJ9KCQ4kd303Nuu5TSo2 yqxU7U14hRNRLalPyARRN+up6iJIddiL9e/7BmJFkfWSiY2VacJvrZAx/JUBoVCt FNP32EpBO8Jci9ix3oLR2zm76c3yaG6du/SDfjyZQ2CZMvz43cjCuwoUbHVK74wt 8LXM6LuyfIIOkFYfRyKs1uSQRNX/+y9rRm8m+tYn35WoJGZ2ZM1A8+CFov00EWoP 5CZGJK9Q5Lw3aCArQFcXWE25WRGyi20K74bkNyd/PtO6BMVnKKlp/StgKNSPR4BN F4buwhLwxDE4/JH+PX6Xfm9Ol6ty9YFRpAU47iH2QqJmCZuriAGfkiMZEczHGT/w k6lfcH0e2aqwLY7U3otzPPvxT0qe0gNO87SH+Ej064i+aesECmvru4ZGyFr1jkkl Ai1zfAKBn0ZMGtsfAF2hFkDLsKVlEdia0HDAfaNIdSoOVMeoV7WA/xmBPdQbZ8pk n7SC3MPgVoVt4ZOT+6GSSv9So+oDhcA91N/IdmQ2S9tXX1LCk7b7561u/Nh9pJNV lYG8tlZ9xc3BqSxprA/r8XGgUS6k3y2QjufzoyS7JwfFdzGj7H1d4x/vTGXSVfun eAuC2BKwXtjIujxdl+7wIwE6RzuHUNeEg1gO/kKNvVVAH3FkU4IN0c8sIbdwKvHa Gq2Z1Gt9YBn7JkjcfNmB =4Yhn -----END PGP SIGNATURE----- From elmi at 4ever.de Fri Mar 9 02:11:31 2012 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 9 Mar 2012 09:11:31 +0100 Subject: Questions about anycasting setup In-Reply-To: References: Message-ID: <20120309081131.GC17726@h.detebe.org> Bill, woody at pch.net (Bill Woodcock) wrote: > > 2. We plan to use this anycasting based setup for DNS during initial few > > months. Assuming low traffic for DNS say ~10Mbps on average (on 100Mbps > > port) and transit from just single network (datacenter itself) - is this > > setup OK for simple software based BGP like Quagga or Bird? > > Yes, and in fact, that's how nearly all large production anycast networks are built??? Each anycast instance contains its own BGP speaker, which announces its service prefix to adjacent BGP-speaking routers, whether those be your own, or your transit-provider's. Doing exactly as you describe is, in fact, best-practice. Well, let's say, using Quagga/BIRD might not really be best practice for everybody... (e.g., *we* are using Cisco equipment for this) Using anycasting for DNS is, to my knowledge, best practice nowadays. > > 3. IPv6! - Is /32 is standard? We have only one /32 > > allocation from ARIN and thus if using /32 seems like hard deal - we have > > to likely get another /32 just for anycasting? or we can use /48 without > > issues? Also, is /48 a good number for breaking /32 so that we can do /48 > > announcements from different datacenters in simple uni casting setup? > > A /48 is quite reasonable. Announcing a whole /32 just for your anycast service would be wasteful. Why? It's simply another prefix, no matter how big. It might look wasteful, but if *that* is the allocation you *have*, it's the one you ought to use. One should be careful - people do filter on allocation lengths, so breaking out a /48 out of a /32 allocation and advertising it on its own can lead to it being filtered. Elmar. From mehmet at akcin.net Fri Mar 9 02:23:55 2012 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 9 Mar 2012 00:23:55 -0800 Subject: Questions about anycasting setup In-Reply-To: <20120309081131.GC17726@h.detebe.org> References: <20120309081131.GC17726@h.detebe.org> Message-ID: On Mar 9, 2012, at 12:11 AM, Elmar K. Bins wrote: >>> 3. IPv6! - Is /32 is standard? We have only one /32 >>> allocation from ARIN and thus if using /32 seems like hard deal - we have >>> to likely get another /32 just for anycasting? or we can use /48 without >>> issues? Also, is /48 a good number for breaking /32 so that we can do /48 >>> announcements from different datacenters in simple uni casting setup? >> >> A /48 is quite reasonable. Announcing a whole /32 just for your anycast service would be wasteful. > > Why? It's simply another prefix, no matter how big. It might look > wasteful, but if *that* is the allocation you *have*, it's the > one you ought to use. > > One should be careful - people do filter on allocation lengths, so > breaking out a /48 out of a /32 allocation and advertising it on its > own can lead to it being filtered. if you know anyone who is filtering /48 , you can start telling them to STOP doing so as a good citizen of internet6. I agree with Woody anything more than /48 for anycast is waste. mehmet From pete at altadena.net Fri Mar 9 03:01:53 2012 From: pete at altadena.net (Pete Carah) Date: Fri, 09 Mar 2012 01:01:53 -0800 Subject: Questions about anycasting setup In-Reply-To: <20120309081131.GC17726@h.detebe.org> References: <20120309081131.GC17726@h.detebe.org> Message-ID: <4F59C701.3090503@altadena.net> On 03/09/2012 12:11 AM, Elmar K. Bins wrote: > Bill, > > woody at pch.net (Bill Woodcock) wrote: > >>> 2. We plan to use this anycasting based setup for DNS during initial few >>> months. Assuming low traffic for DNS say ~10Mbps on average (on 100Mbps >>> port) and transit from just single network (datacenter itself) - is this >>> setup OK for simple software based BGP like Quagga or Bird? >> Yes, and in fact, that's how nearly all large production anycast networks are built??? Each anycast instance contains its own BGP speaker, which announces its service prefix to adjacent BGP-speaking routers, whether those be your own, or your transit-provider's. Doing exactly as you describe is, in fact, best-practice. > Well, let's say, using Quagga/BIRD might not really be best practice for > everybody... (e.g., *we* are using Cisco equipment for this) Actually there is a *very* good reason why many (most?) anycast instances use quagga/BIRD/gated/etc to speak bgp (or even ospf for internal anycast) which using a Cisco (or any separate router) usually won't accomplish. -- Pete > > Using anycasting for DNS is, to my knowledge, best practice nowadays. > > From jsw at inconcepts.biz Fri Mar 9 03:02:08 2012 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Fri, 9 Mar 2012 04:02:08 -0500 Subject: filtering /48 is going to be necessary Message-ID: On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin wrote: > if you know anyone who is filtering /48 , you can start telling them to STOP doing so as a good citizen of internet6. I had a bit of off-list discussion about this topic, and I was not going to bring it up today on-list, but since the other point of view is already there, I may as well. Unless you are going to pay the bill for my clients to upgrade their 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need to do two things before IPv6 up-take is really broad: 1) absolutely must drop /48 de-aggregates from ISP blocks 2) absolutely must make RIR policy so orgs can get /48s for anycasting, and whatever other purposes If we fail to adjust RIR policy to account for the huge amount of accidental de-aggregation that can (and will) happen with IPv6, we will eventually have to do #1 anyway, but a bunch of networks will have to renumber in order take advantage of #2 down the road. The way we are headed right now, it is likely that the IPv6 address space being issued today will look like "the swamp" in a few short years, and we will regret repeating this obvious mistake. We had this discussion on the list exactly a year ago. At that time, the average IPv6 origin ASN was announcing 1.43 routes. That figure today is 1.57 routes per origin ASN. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From woody at pch.net Fri Mar 9 03:08:48 2012 From: woody at pch.net (Bill Woodcock) Date: Fri, 9 Mar 2012 01:08:48 -0800 Subject: Questions about anycasting setup In-Reply-To: <20120309081131.GC17726@h.detebe.org> References: <20120309081131.GC17726@h.detebe.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mar 9, 2012, at 12:11 AM, Elmar K. Bins wrote: > Well, let's say, using Quagga/BIRD might not really be best practice for > everybody... (e.g., *we* are using Cisco equipment for this) How does your Cisco know whether an adjacent nameserver is heavily loaded, and adjust its BGP announcements accordingly? -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPWcigAAoJEG+kcEsoi3+HTy0QAJlt5Sy/uDKFL+JY8ebMReYC DA5bmtu/mPCzoi9dCQYmm5SeGaPAPE+1idmQE2iXJ8j/MeE+2W13jnna9aQQQuGi z1P9ZX98gSoJ1CcwOuNQ79wO+Uzi6vGnFMa1sjAP4ZhxsgOUXRqyWAv0VM0JFJCT yW8vfoK2DpTD2E9zTntRJ4139jSxNr6lQjo5AqwjWeqbKxT2CfHZmX040dAe/nJd LTWyXnPn7HxYbUVMitYZ4hYD99VVdT3Pq9ufOUGMHgDECxGlXoJ3Ynrif80Pk0iT QtyU7Rk6kufBT5sFYkjysyzfhWxNtPD34bjz5sj9tMQ4rwb+KgtEHWOiIkUs0ET3 ZqiZOy6n3ecLq+IkayO/37vol9LdLdev3nNBE3sOrFZITnR/39wAaT/7x5yusU+N NbEXAum4WJt8pIbpkyxCTBFMXxJ0MhNYvMRhqbm/1SCtvC5Dw6mPLIZnYG0UEn8j 0jyEVQ3jJz+l6ID0FBgXZVdCMMcafpCnm+A50xOd1Gsw+5ojqWqJ/Lqd7Rp4XcgD FJejwt4Qtu+L5q8LMu96R9ohGg8Uqx9CBz3qDAB9X7Xipx3bWYFlDJM5Pf832VH5 3W0GZKGCqWmtHWBmzZAJNTySKsHYfStqzVMnwXDsPBQGm2ScKS44t+v56FGcHu29 izRP8sni+zNBKsTB5x2h =Ltey -----END PGP SIGNATURE----- From jeroen at unfix.org Fri Mar 9 03:27:04 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 09 Mar 2012 10:27:04 +0100 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: <4F59CCE8.6010400@unfix.org> On 2012-03-09 10:02 , Jeff Wheeler wrote: > On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin wrote: >> if you know anyone who is filtering /48 , you can start telling them to STOP doing so as a good citizen of internet6. > > I had a bit of off-list discussion about this topic, and I was not > going to bring it up today on-list, but since the other point of view > is already there, I may as well. > > Unless you are going to pay the bill for my clients to upgrade their > 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need > to do two things before IPv6 up-take is really broad: > > 1) absolutely must drop /48 de-aggregates from ISP blocks See the strict filter at: http://www.space.net/~gert/RIPE/ipv6-filters.html which has been proposed for quite a long time already. Also note the existence of this awesome thing called RPSL. See also this great presentation by ras: http://www.nanog.org/meetings/nanog44/presentations/Tuesday/RAS_irrdata_N44.pdf and the very recent column by Geoff Huston: http://www.potaroo.net/ispcol/2012-03/leaks.html > 2) absolutely must make RIR policy so orgs can get /48s for > anycasting, and whatever other purposes One can already receive those easily, generally as a /48. Also, quite a few organizations are requesting disjunct /32's per country or at least a /32 per region.... Greets, Jeroen From elmi at 4ever.de Fri Mar 9 03:32:18 2012 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 9 Mar 2012 10:32:18 +0100 Subject: Questions about anycasting setup In-Reply-To: <4F59C701.3090503@altadena.net> References: <20120309081131.GC17726@h.detebe.org> <4F59C701.3090503@altadena.net> Message-ID: <20120309093218.GF17726@h.detebe.org> Re Bill, pete at altadena.net (Pete Carah) wrote: > > Well, let's say, using Quagga/BIRD might not really be best practice for > > everybody... (e.g., *we* are using Cisco equipment for this) > Actually there is a *very* good reason why many (most?) anycast > instances use quagga/BIRD/gated/etc > to speak bgp (or even ospf for internal anycast) which using a Cisco (or > any separate router) usually won't accomplish. Please enlighten me... Elmar. From elmi at 4ever.de Fri Mar 9 03:34:24 2012 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 9 Mar 2012 10:34:24 +0100 Subject: Questions about anycasting setup In-Reply-To: References: <20120309081131.GC17726@h.detebe.org> Message-ID: <20120309093423.GG17726@h.detebe.org> Re Bill, woody at pch.net (Bill Woodcock) wrote: > > Well, let's say, using Quagga/BIRD might not really be best practice for > > everybody... (e.g., *we* are using Cisco equipment for this) > How does your Cisco know whether an adjacent nameserver is heavily loaded, and adjust its BGP announcements accordingly? It doesn't have to. I don't know how you guys do it, but we take great care to keep min. 70% overhead capacity during standard operation. Elmar. From woody at pch.net Fri Mar 9 03:45:24 2012 From: woody at pch.net (Bill Woodcock) Date: Fri, 9 Mar 2012 01:45:24 -0800 Subject: Questions about anycasting setup In-Reply-To: <20120309093423.GG17726@h.detebe.org> References: <20120309081131.GC17726@h.detebe.org> <20120309093423.GG17726@h.detebe.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mar 9, 2012, at 1:34 AM, Elmar K. Bins wrote: > Re Bill, > > woody at pch.net (Bill Woodcock) wrote: > >>> Well, let's say, using Quagga/BIRD might not really be best practice for >>> everybody... (e.g., *we* are using Cisco equipment for this) >> How does your Cisco know whether an adjacent nameserver is heavily loaded, and adjust its BGP announcements accordingly? > > It doesn't have to. > > I don't know how you guys do it, but we take great care to > keep min. 70% overhead capacity during standard operation. RFC 2870 section 2.3 suggests 33%. How us guys do it is 2%-3%, since "standard operation" is only the case when nobody's getting DDoSed. And then we have a backup plan, which is to be able to redirect queries away from nodes that are overloaded. And we have backup plans for the backup plans. But then, we've been doing anycast DNS for twenty years now, so we've had some time to develop those plans. I think what you're hearing from other people, though, is that having a backup plan is, indeed, best practice. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPWdE1AAoJEG+kcEsoi3+H2ZsP/2pkKogGXo2THXS4sMPusDdn FdsnWZIk2KDfFdwko7o135Uiv6Lkr9SeuBsFtohbq05Odo6BU1U/KBXWcwiWB/2y umk390F0mgKDx0A0S5TPCwgKFQW+u2ynKCsXGMHIvbn+iTWvBrBaV2XGeF1ukU1H xWqJcXk42GQA7lnqH7vc8HN+SW8Ill9MZp6vqC9ZnWzQ6VyMzZsPWDWPIddgLIhr vvS5lLCGUdUzqkw/dKXBaQrj9UpjipfQrHx4rOd2M1ULVXngsU1MWxvKpSh3HZZz 68m7Z8J/120NrJ3kthQg/YQJTBG01CYP5pkBYVfB/X7TaYYvFEOtyO57VNEZXNyr Km1lkUd/iYrwx/+YCQf4TH7h3hfgvC21lwsp6RRhvGkQcBA8Fs8VPUbrschbcU8f FilndHewhX4zhCNTBhGoeZOAyACOYYib8JwaUOft2JEC40O3NvPjqWXjhK52gpX0 pAhprGo4oDnDGyM6PmO8b5qDdGRA4hyxZq3NwUj+4PI4Lylq34PUE9T2QQVBfRtT 8pKEOyRHgvrmmiYF8Lsvxc2iAze9SZouNqZ7gy1QJ7aikK6LKMp8GQrtgO52AkKm +wYpIaOKpbscjuBpKGNu331R0ula02TCy6eB75rnbcEd0oDQu14bKwyea6ORl/dh yRV2lOxCX4oCYYW1yNHd =Ushc -----END PGP SIGNATURE----- From pete at altadena.net Fri Mar 9 03:55:08 2012 From: pete at altadena.net (Pete Carah) Date: Fri, 09 Mar 2012 01:55:08 -0800 Subject: Questions about anycasting setup In-Reply-To: <20120309093423.GG17726@h.detebe.org> References: <20120309081131.GC17726@h.detebe.org> <20120309093423.GG17726@h.detebe.org> Message-ID: <4F59D37C.2090109@altadena.net> On 03/09/2012 01:34 AM, Elmar K. Bins wrote: > Re Bill, > > woody at pch.net (Bill Woodcock) wrote: > >>> Well, let's say, using Quagga/BIRD might not really be best practice for >>> everybody... (e.g., *we* are using Cisco equipment for this) >> How does your Cisco know whether an adjacent nameserver is heavily loaded, and adjust its BGP announcements accordingly? > It doesn't have to. > > I don't know how you guys do it, but we take great care to > keep min. 70% overhead capacity during standard operation. > My point had to do with resilience in the face of hardware/OS/software failures in the box providing the service. Bill's has more to do with resilience in the face of other network events (e.g. the upstream for one of the boxes has a DDOS; you cannot reasonably provide enough excess capacity to handle that...) Neither of these is addressed by using a separate router to announce the server's anycast route. (unless somehow the Cisco is providing the anycasted service, which would address my concern but still not Bill's.) Also, Bill is probably talking root (or bigger public) servers whose load comes from "off-site"; the average load characteristics for those are well known but there can be extremes that would be hard to plan for (hint - operating at 30% isn't really good enough, probably not 10% either. Bill (and the other Bill) have pretty good stats for this that I've only glanced at...) And it is easy to see where one of the extremes might hit only one or two of the anycast instances. He implies having the instances talking to each other in background to adjust bgp announcements to maybe help level things. Fortunately at least for the root servers, the redundancy is at two levels and anycast is only one of them. -- Pete From eugen at leitl.org Fri Mar 9 06:51:20 2012 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 9 Mar 2012 13:51:20 +0100 Subject: [NSG-d] Historian is trolling for memories about the early days of SF and ARPANet. Anybody? Message-ID: <20120309125120.GA9891@leitl.org> Sorry for nonoperational content, but this struck me as a good place to post this query. ----- Forwarded message from Fred Hapgood ----- From: Fred Hapgood Date: Thu, 08 Mar 2012 17:18:33 -0500 To: nsg-d at marshome.org Subject: [NSG-d] Historian is trolling for memories about the early days of SF and ARPANet. Anybody? X-Mailer: MessagingEngine.com Webmail Interface Reply-To: Nanotechnology Study Group - open discussion ----- Original message ----- From: "Christopher Leslie" <[1]cleslie at poly.edu> To: [2]hapgood at pobox.com Date: Thu, 8 Mar 2012 15:47:39 -0500 Subject: sf-lovers Dear Mr. Hapgood: Damien Broderick suggested that I contact you for a project I am working on. I have become intrigued by a connection between science fiction and the early days of the ARPAnet. As you may know, one of the first group distribution lists that was not directly related to defense research was the mailing list SF-lovers, which was created in Sept. 1979 at MIT by Richard Brodie. When Usenet became available, a connection was established, and the travails of the list after that point are fairly well documented by Saul Jaffe and others. Before the Usenet list, however, there is not so much information. I've been in contact with some researchers about this, but I am hoping that someone on the list might also remember the days of the sf-lovers list before Usenet. I've also heard that there were mailing groups on local computers and BBSs (bulletin board systems) before there were widely dispersed e-mail list, which if they were discussing science fiction, I would love to learn about. If you have any information to share, or can direct me to someone who does, I would greatly appreciate it. I am writing a book on science fiction and I think this list demonstrates an interesting synergy between science fiction and engineering. Chris Leslie Christopher S. Leslie, Ph.D. Instructor of Media and Technology Studies Polytechnic Institute of New York University 6 MetroTech Center, RH 213h Brooklyn, NY 11201 (718) 260-3130 References 1. mailto:cleslie at poly.edu 2. mailto:hapgood at pobox.com http://www.BostonScienceLectures.com http://www.pobox.com/~fhapgood ** The following attachments were removed: multipart/alternative text/html _______________________________________ Nanotechnology Study Group NSG-d open discussion group http://www.marshome.org/mailman/listinfo/nsg-d Send replies (no attachments) to: NSG-d___no-spam at marshome.org Questions for list admin: NSG-d-owner___no-spam at marshome.org Archive: http://MarsHome.org/mailman/private/NSG-d Unsubscribe: NSG-d-unsubscribe at marshome.org Password or Options or Unsubscribe: http://MarsHome.org/mailman/options/NSG-d Hosted by CyberTeams.com and Mars Foundation(tm), http://MarsHome.org ----- End forwarded message ----- -- 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 bill at herrin.us Fri Mar 9 07:48:45 2012 From: bill at herrin.us (William Herrin) Date: Fri, 9 Mar 2012 08:48:45 -0500 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: On Fri, Mar 9, 2012 at 4:02 AM, Jeff Wheeler wrote: > On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin wrote: >> if you know anyone who is filtering /48 , you can >> start telling them to STOP doing so as a good citizen of internet6. > > I had a bit of off-list discussion about this topic, and I was not > going to bring it up today on-list, but since the other point of view > is already there, I may as well. > > Unless you are going to pay the bill for my clients to upgrade their > 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need > to do two things before IPv6 up-take is really broad: > > 1) absolutely must drop /48 de-aggregates from ISP blocks > 2) absolutely must make RIR policy so orgs can get /48s for > anycasting, and whatever other purposes > > If we fail to adjust RIR policy to account for the huge amount of > accidental de-aggregation that can (and will) happen with IPv6, we > will eventually have to do #1 anyway, but a bunch of networks will > have to renumber in order take advantage of #2 down the road. Hi Jeff, We could use smarter prefix filtering than that. Which was proposed to ARIN a couple years ago. And failed. http://lists.arin.net/pipermail/arin-ppml/2009-November/015521.html Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From brunner at nic-naa.net Fri Mar 9 08:40:02 2012 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 09 Mar 2012 09:40:02 -0500 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> References: <20120308165600.A88561A2@m0005297.ppops.net> <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> Message-ID: <4F5A1642.6000602@nic-naa.net> Thank you George. Not SMTP but HTTP. I expect exact match string (as brand) marketers, and also partial match string (as brand typo-squatter) marketers, to exploit this asset class ("widely spread and legitimately routed IPs"). #include #include #include Eric From berni at birkenwald.de Fri Mar 9 08:50:56 2012 From: berni at birkenwald.de (Bernhard Schmidt) Date: Fri, 9 Mar 2012 14:50:56 +0000 (UTC) Subject: filtering /48 is going to be necessary References: Message-ID: Jeff Wheeler wrote: Hello Jeff, > On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin wrote: >> if you know anyone who is filtering /48 , you can start telling them >> to STOP doing so as a good citizen of internet6. > > I had a bit of off-list discussion about this topic, and I was not > going to bring it up today on-list, but since the other point of view > is already there, I may as well. > > Unless you are going to pay the bill for my clients to upgrade their > 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need > to do two things before IPv6 up-take is really broad: > > 1) absolutely must drop /48 de-aggregates from ISP blocks > 2) absolutely must make RIR policy so orgs can get /48s for > anycasting, and whatever other purposes I used to be (or still am) on the same page as you are. I was dropping everything smaller than a /36 from PA ranges at the edge. I recently had to relax this filter, because Cloudflare seems to insist on throwing tons of /48s from their 2400:cb00::/32 into the air without an aggregate. And guess what the popular cloud reverse proxy for IPv6 webpages is these days ... cloudflare. Yes, it sucks, yes, I wrote them, but no answer and no change. Best Regards, Bernhard From jim at impactbusiness.com Fri Mar 9 10:01:34 2012 From: jim at impactbusiness.com (Jim Gonzalez) Date: Fri, 9 Mar 2012 11:01:34 -0500 Subject: Request to lease IP space, or things that make you want to go hmmmmm.. In-Reply-To: <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> References: <20120308165600.A88561A2@m0005297.ppops.net> <4C14311B-271E-4E3F-B8A3-88646046FAA2@apnic.net> Message-ID: <00b501ccfe0d$effe4470$cffacd50$@impactbusiness.com> -----Original Message----- From: George Michaelson [mailto:ggm at apnic.net] Sent: Thursday, March 08, 2012 8:06 PM To: NANOG Subject: Re: Request to lease IP space, or things that make you want to go hmmmmm.. no. you misunderstand. The value proposition is not spam: that works with unallocated space. The value proposition is gaming google page rank, by using widely spread and legitimately routed IPs to force your paying customers page rank high, by hits and references. This is a very high value business: one customer paying you big bucks, to have their web high in google pagerank. Not attacking a million mailboxes. In this model, the 'target' is google. The IPS need to come from classic, widespread IPs because google now count the source IP and can tell if you use a virtually hosted single IP to try and do this. I have a question: are we actually able to state this consumption of address is 'illegal' ? I personally judge it to be unethical, but that is not the same thing. -George PS since this goes to address policy, I need to declare that I work for an RIR but I am posting in a personal capacity and nothing I say is a reflection of any RIR address policy. I work in the research department, not in registry/allocations George, I would figure Google would check AS path / BGP announcements ? If they are checking source address why not routing too ? -Jim From paul4004 at gmail.com Fri Mar 9 10:04:56 2012 From: paul4004 at gmail.com (PC) Date: Fri, 9 Mar 2012 09:04:56 -0700 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: I think ARIN issues /48s for Provider independent space as the minimum allocation size, so I'm guessing we shouldn't filter below that. At least, that's what's in their current policies. On Fri, Mar 9, 2012 at 7:50 AM, Bernhard Schmidt wrote: > Jeff Wheeler wrote: > > Hello Jeff, > > > On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin wrote: > >> if you know anyone who is filtering /48 , you can start telling them > >> to STOP doing so as a good citizen of internet6. > > > > I had a bit of off-list discussion about this topic, and I was not > > going to bring it up today on-list, but since the other point of view > > is already there, I may as well. > > > > Unless you are going to pay the bill for my clients to upgrade their > > 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need > > to do two things before IPv6 up-take is really broad: > > > > 1) absolutely must drop /48 de-aggregates from ISP blocks > > 2) absolutely must make RIR policy so orgs can get /48s for > > anycasting, and whatever other purposes > > I used to be (or still am) on the same page as you are. I was dropping > everything smaller than a /36 from PA ranges at the edge. > > I recently had to relax this filter, because Cloudflare seems to insist > on throwing tons of /48s from their 2400:cb00::/32 into the air without > an aggregate. And guess what the popular cloud reverse proxy for IPv6 > webpages is these days ... cloudflare. > > Yes, it sucks, yes, I wrote them, but no answer and no change. > > Best Regards, > Bernhard > > > From berni at birkenwald.de Fri Mar 9 10:08:03 2012 From: berni at birkenwald.de (Bernhard Schmidt) Date: Fri, 09 Mar 2012 17:08:03 +0100 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: <4F5A2AE3.4000508@birkenwald.de> On 09.03.2012 17:04, PC wrote: > I think ARIN issues /48s for Provider independent space as the > minimum allocation size, so I'm guessing we shouldn't filter below > that. At least, that's what's in their current policies. Note that I explicitly wrote: | I used to be (or still am) on the same page as you are. I was | dropping everything smaller than a /36 from PA ranges at the edge. ^^^^^^^ Of course I'm accepting /48 from PI range (in ARIN world 2001:500::/30 2001:504::/30 and 2620::/23), anything else would be quite brain-dead and stupid. Bernhard From asusag at ifncom.net Fri Mar 9 11:54:23 2012 From: asusag at ifncom.net (Andy Susag) Date: Fri, 9 Mar 2012 12:54:23 -0500 Subject: MEF-CECP training Message-ID: <01245B4ABF809743A84B2F16C6598FEAE85B9F@hydrogen> Hi All, It seems like here in the Americas we have a choice of either Tech 2000 or Perpetual Solutions for MEF certification training. Perpetual Solutions is about $1000 more per seat, but seems a little more robust. Has anyone gone through this training or used either of these companies? Thanks, Andy Susag Network Engineer IFN From davidpeahi at gmail.com Fri Mar 9 12:21:29 2012 From: davidpeahi at gmail.com (david peahi) Date: Fri, 9 Mar 2012 10:21:29 -0800 Subject: MEF-CECP training In-Reply-To: <01245B4ABF809743A84B2F16C6598FEAE85B9F@hydrogen> References: <01245B4ABF809743A84B2F16C6598FEAE85B9F@hydrogen> Message-ID: I also would be interested in any information. It looks like MEF recognizes 4 training companies: http://metroethernetforum.org/page_loader.php?p_id=1577 One company offers just 1 class then an exam for certification. On Fri, Mar 9, 2012 at 9:54 AM, Andy Susag wrote: > Hi All, > > > > It seems like here in the Americas we have a choice of either Tech 2000 > or Perpetual Solutions for MEF certification training. Perpetual > Solutions is about $1000 more per seat, but seems a little more robust. > Has anyone gone through this training or used either of these companies? > > > > Thanks, > > > > Andy Susag > > Network Engineer > > IFN > > > > From mike at smashing.net Fri Mar 9 12:37:38 2012 From: mike at smashing.net (Mike Hughes) Date: Fri, 9 Mar 2012 18:37:38 +0000 Subject: UKNOF 22 Call for Presentations Message-ID: UKNOF 22 - Call For Presentations The next UKNOF meeting will take place on Thursday 3rd May 2012 in the City of York, hosted by Bytemark, and the Programme Committee are seeking content from the community for this meeting. You may often hear it said that UKNOF's remit is "distribution of clue", so if the content of your talk fits with that ethos, we're actually pretty open minded about what the actual topic is - as long as it's relevant to our community's broad area of interest, and the quality is good. Talks are usually around 20 to 40 minutes in length, and common subject areas are: * Network operations * Network architecture and design * Networking hardware and software architecture * Peering and interconnect * Data centre design and operations * IPv6 deployment * Network monitoring and measurement * New innovations in networking technology * Open protocol standards * Domain Name System infrastructure * Network security and abuse prevention * Impact of public policy of network operations We are also looking for material relevant to the following topics for York: * Future Networking Technologies (e.g. 4G/LTE) * Open Networking Technologies But, we're always on the lookout for something different, so don't feel it has to fall into the areas above. We're also interested in hearing proposals for panel discussions, as these are a great way of presenting and discussing different views on the same subject. Please send your proposals to submissions at uknof.org.uk, including a short abstract of the subject, and draft slides if these are available. The closing date for submissions is the 5th April 2012, but don't worry if you miss the deadline and have something interesting to talk about, as we are often able to accept shorter (10 minute) "lightning talks" closer in to the meeting. Please also get in touch if you would like to suggest any topics, themes or speakers. Hope to see you in May at the UKNOF meeting. Mike Hughes on behalf of the UKNOF Programme Committee From cscora at apnic.net Fri Mar 9 12:56:26 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Mar 2012 04:56:26 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201203091856.q29IuQGC023354@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 10 Mar, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 400226 Prefixes after maximum aggregation: 170764 Deaggregation factor: 2.34 Unique aggregates announced to Internet: 194744 Total ASes present in the Internet Routing Table: 40315 Prefixes per ASN: 9.93 Origin-only ASes present in the Internet Routing Table: 32840 Origin ASes announcing only one prefix: 15490 Transit ASes present in the Internet Routing Table: 5414 Transit-only ASes present in the Internet Routing Table: 144 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 369 Unregistered ASNs in the Routing Table: 162 Number of 32-bit ASNs allocated by the RIRs: 2313 Number of 32-bit ASNs visible in the Routing Table: 2061 Prefixes from 32-bit ASNs in the Routing Table: 4921 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 561 Number of addresses announced to Internet: 2525381776 Equivalent to 150 /8s, 134 /16s and 68 /24s Percentage of available address space announced: 68.1 Percentage of allocated address space announced: 68.1 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 92.1 Total number of prefixes smaller than registry allocations: 170161 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 98128 Total APNIC prefixes after maximum aggregation: 31878 APNIC Deaggregation factor: 3.08 Prefixes being announced from the APNIC address blocks: 94515 Unique aggregates announced from the APNIC address blocks: 39432 APNIC Region origin ASes present in the Internet Routing Table: 4670 APNIC Prefixes per ASN: 20.24 APNIC Region origin ASes announcing only one prefix: 1237 APNIC Region transit ASes present in the Internet Routing Table: 735 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 164 Number of APNIC addresses announced to Internet: 640794208 Equivalent to 38 /8s, 49 /16s and 190 /24s Percentage of available APNIC address space announced: 81.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 149018 Total ARIN prefixes after maximum aggregation: 75689 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 120522 Unique aggregates announced from the ARIN address blocks: 49856 ARIN Region origin ASes present in the Internet Routing Table: 14928 ARIN Prefixes per ASN: 8.07 ARIN Region origin ASes announcing only one prefix: 5667 ARIN Region transit ASes present in the Internet Routing Table: 1571 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 15 Number of ARIN addresses announced to Internet: 806485760 Equivalent to 48 /8s, 17 /16s and 255 /24s Percentage of available ARIN address space announced: 64.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 100333 Total RIPE prefixes after maximum aggregation: 52819 RIPE Deaggregation factor: 1.90 Prefixes being announced from the RIPE address blocks: 91871 Unique aggregates announced from the RIPE address blocks: 56921 RIPE Region origin ASes present in the Internet Routing Table: 16335 RIPE Prefixes per ASN: 5.62 RIPE Region origin ASes announcing only one prefix: 7986 RIPE Region transit ASes present in the Internet Routing Table: 2623 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1406 Number of RIPE addresses announced to Internet: 501532936 Equivalent to 29 /8s, 228 /16s and 201 /24s Percentage of available RIPE address space announced: 80.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 38950 Total LACNIC prefixes after maximum aggregation: 8158 LACNIC Deaggregation factor: 4.77 Prefixes being announced from the LACNIC address blocks: 38648 Unique aggregates announced from the LACNIC address blocks: 19684 LACNIC Region origin ASes present in the Internet Routing Table: 1573 LACNIC Prefixes per ASN: 24.57 LACNIC Region origin ASes announcing only one prefix: 434 LACNIC Region transit ASes present in the Internet Routing Table: 285 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 472 Number of LACNIC addresses announced to Internet: 98090376 Equivalent to 5 /8s, 216 /16s and 189 /24s Percentage of available LACNIC address space announced: 65.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8653 Total AfriNIC prefixes after maximum aggregation: 2097 AfriNIC Deaggregation factor: 4.13 Prefixes being announced from the AfriNIC address blocks: 6739 Unique aggregates announced from the AfriNIC address blocks: 2164 AfriNIC Region origin ASes present in the Internet Routing Table: 518 AfriNIC Prefixes per ASN: 13.01 AfriNIC Region origin ASes announcing only one prefix: 166 AfriNIC Region transit ASes present in the Internet Routing Table: 116 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 31553792 Equivalent to 1 /8s, 225 /16s and 121 /24s Percentage of available AfriNIC address space announced: 47.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2494 11109 994 Korea Telecom (KIX) 17974 1735 503 37 PT TELEKOMUNIKASI INDONESIA 7545 1647 303 86 TPG Internet Pty Ltd 4755 1568 386 158 TATA Communications formerly 9583 1236 93 525 Sify Limited 9829 1187 1001 30 BSNL National Internet Backbo 7552 1160 1062 11 Vietel Corporation 4808 1093 2048 311 CNCGROUP IP network: China169 24560 1005 383 166 Bharti Airtel Ltd., Telemedia 18101 949 130 155 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3418 1014 159 Windstream Communications Inc 6389 3405 3807 198 bellsouth.net, inc. 18566 2091 382 177 Covad Communications 1785 1881 680 128 PaeTec Communications, Inc. 20115 1635 1555 634 Charter Communications 4323 1608 1059 383 Time Warner Telecom 22773 1544 2910 111 Cox Communications, Inc. 30036 1419 259 758 Mediacom Communications Corp 19262 1359 4701 399 Verizon Global Networks 7018 1281 9776 841 AT&T WorldNet Services Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1777 544 16 Corbina telecom 2118 1421 97 13 EUnet/RELCOM Autonomous Syste 15557 1087 2184 60 LDCOM NETWORKS 34984 658 188 171 BILISIM TELEKOM 20940 641 206 489 Akamai Technologies European 6830 640 1927 411 UPC Distribution Services 12479 640 648 54 Uni2 Autonomous System 8551 578 360 81 Bezeq International 31148 540 37 9 FreeNet ISP 3320 533 8442 399 Deutsche Telekom AG Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1761 326 160 TVCABLE BOGOTA 28573 1688 1092 57 NET Servicos de Comunicao S.A 8151 1487 3013 348 UniNet S.A. de C.V. 7303 1328 822 186 Telecom Argentina Stet-France 26615 899 676 30 Tim Brasil S.A. 27947 678 68 110 Telconet S.A 11172 634 91 72 Servicios Alestra S.A de C.V 22047 582 322 17 VTR PUNTO NET S.A. 6503 572 418 65 AVANTEL, S.A. 3816 558 240 89 Empresa Nacional de Telecomun Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1178 958 13 TEDATA 24863 801 274 37 LINKdotNET AS number 6713 489 649 18 Itissalat Al-MAGHRIB 3741 277 923 228 The Internet Solution 15706 227 32 6 Sudatel Internet Exchange Aut 12258 197 28 62 Vodacom Internet Company 24835 182 80 8 RAYA Telecom - Egypt 33776 161 12 16 Starcomms Nigeria Limited 36923 157 20 4 Swift Networks Limited 29571 156 15 16 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3418 1014 159 Windstream Communications Inc 6389 3405 3807 198 bellsouth.net, inc. 4766 2494 11109 994 Korea Telecom (KIX) 18566 2091 382 177 Covad Communications 1785 1881 680 128 PaeTec Communications, Inc. 8402 1777 544 16 Corbina telecom 10620 1761 326 160 TVCABLE BOGOTA 17974 1735 503 37 PT TELEKOMUNIKASI INDONESIA 28573 1688 1092 57 NET Servicos de Comunicao S.A 7545 1647 303 86 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3405 3207 bellsouth.net, inc. 18566 2091 1914 Covad Communications 8402 1777 1761 Corbina telecom 1785 1881 1753 PaeTec Communications, Inc. 17974 1735 1698 PT TELEKOMUNIKASI INDONESIA 28573 1688 1631 NET Servicos de Comunicao S.A 10620 1761 1601 TVCABLE BOGOTA 7545 1647 1561 TPG Internet Pty Ltd 4766 2494 1500 Korea Telecom (KIX) 22773 1544 1433 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 23.27.0.0/20 54500 EGIHosting 23.27.0.0/16 54500 EGIHosting Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:28 /11:81 /12:235 /13:458 /14:818 /15:1476 /16:12177 /17:6227 /18:10410 /19:20464 /20:28564 /21:29360 /22:39917 /23:37110 /24:209174 /25:1212 /26:1443 /27:782 /28:169 /29:57 /30:14 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 3073 3418 Windstream Communications Inc 6389 2103 3405 bellsouth.net, inc. 18566 2040 2091 Covad Communications 8402 1755 1777 Corbina telecom 10620 1658 1761 TVCABLE BOGOTA 30036 1368 1419 Mediacom Communications Corp 11492 1125 1162 Cable One 1785 1064 1881 PaeTec Communications, Inc. 7011 1042 1157 Citizens Utilities 15557 1034 1087 LDCOM NETWORKS Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:523 2:726 4:14 6:3 8:392 12:1961 13:1 14:603 15:12 16:3 17:7 20:8 23:142 24:1749 27:1231 31:961 32:62 33:2 34:2 36:9 37:237 38:778 40:117 41:2936 42:123 44:3 46:1403 47:3 49:339 50:512 52:13 54:5 55:12 56:3 57:38 58:953 59:497 60:283 61:1190 62:972 63:2011 64:4132 65:2281 66:4471 67:2031 68:1158 69:3168 70:917 71:423 72:1831 74:2635 75:469 76:320 77:977 78:963 79:485 80:1209 81:887 82:630 83:538 84:604 85:1185 86:726 87:907 88:334 89:1565 90:285 91:4549 92:515 93:1382 94:1369 95:1120 96:424 97:316 98:833 99:38 100:5 101:146 103:886 106:64 107:171 108:211 109:1532 110:726 111:861 112:437 113:536 114:609 115:774 116:870 117:712 118:910 119:1261 120:329 121:687 122:1621 123:1077 124:1341 125:1341 128:543 129:192 130:260 131:591 132:166 133:21 134:236 135:62 136:212 137:185 138:275 139:145 140:491 141:266 142:390 143:427 144:501 145:68 146:490 147:243 148:725 149:300 150:162 151:176 152:448 153:171 154:7 155:432 156:212 157:370 158:162 159:518 160:327 161:245 162:344 163:186 164:531 165:394 166:564 167:461 168:810 169:148 170:848 171:117 172:4 173:1716 174:608 175:421 176:547 177:537 178:1285 180:1196 181:66 182:769 183:285 184:442 185:1 186:2101 187:857 188:1052 189:1207 190:5471 192:5990 193:5573 194:4408 195:3611 196:1286 197:168 198:3636 199:4443 200:5739 201:1771 202:8389 203:8669 204:4361 205:2457 206:2753 207:2794 208:4045 209:3571 210:2754 211:1464 212:1956 213:1879 214:871 215:103 216:5041 217:1525 218:540 219:333 220:1229 221:555 222:324 223:326 End of report From mlarson at verisign.com Fri Mar 9 13:18:13 2012 From: mlarson at verisign.com (Matt Larson) Date: Fri, 9 Mar 2012 14:18:13 -0500 Subject: Whois operational message Message-ID: This message contains operational information that might be of interest to the Internet operational community. Verisign is enabling IPv6 transport for its .com/.net Whois service (which also contains information for .edu, .arpa, and the root zone). By March 31, 2012, Verisign will begin accepting queries to the aforementioned Whois service over IPv6 transport in addition to IPv4. Accordingly, DNS queries for the Whois server host names whois.verisign-grs.com, whois.verisign-grs.net, whois.crsnic.net, whois.nsiregistry.com, and whois.nsiregistry.net will return both A and AAAA records. If you have any questions or comments, please send email to info at verisign?grs.com or reply to this message. Matt Larson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: Message signed with OpenPGP using GPGMail URL: From owen at delong.com Fri Mar 9 13:27:38 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Mar 2012 11:27:38 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: On Mar 9, 2012, at 1:02 AM, Jeff Wheeler wrote: > On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin wrote: >> if you know anyone who is filtering /48 , you can start telling them to STOP doing so as a good citizen of internet6. > > I had a bit of off-list discussion about this topic, and I was not > going to bring it up today on-list, but since the other point of view > is already there, I may as well. > > Unless you are going to pay the bill for my clients to upgrade their > 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need > to do two things before IPv6 up-take is really broad: > > 1) absolutely must drop /48 de-aggregates from ISP blocks > 2) absolutely must make RIR policy so orgs can get /48s for > anycasting, and whatever other purposes > Item 1 will be interesting. Item 2 is already done in ARIN and I think RIPE and APNIC. I'm not sure about AfriNIC or LACNIC. > If we fail to adjust RIR policy to account for the huge amount of > accidental de-aggregation that can (and will) happen with IPv6, we > will eventually have to do #1 anyway, but a bunch of networks will > have to renumber in order take advantage of #2 down the road. > Can you point to specific RIR policies that you believe need adjustment? I'm willing to help (and somewhat adept at doing so), but I'm not seeing the problem you are reporting, so, I need more data. > The way we are headed right now, it is likely that the IPv6 address > space being issued today will look like "the swamp" in a few short > years, and we will regret repeating this obvious mistake. > I don't think so, actually. First, I don't think the swamp was a mistake so much as a temporary problem with resource limitation on routers. The problem in today's routing table is NOT the "swamp". (Where swamp is defined as the large number of /24s issued to organizations in a non- aggregable manner often as direct assignments from the InterNIC before CIDR and provider-assigned addressing existed). The total scope of the swamp is limited to about 65,000 prefixes. All of the growth beyond about 65,000 prefixes is, instead, attributable to a number of other factors, not the least of which are disaggregation for convenience (which could be an issue in IPv6), disaggregation due to ignorance (which will likely be an issue in IPv6), de-aggregation due to differences in routing policy and/or for traffic management strategies (which will also happen in IPv6), general growth of the internet (which will also happen in IPv6, but, at a lower prefix-growth rate), and finally, one of the biggest causes... slow start, growth constrained RIR policies handing out incremental (often 1 year worth or less) growth in address blocks due to scarcity (which should not be a problem in IPv6). In the ARIN region I think we have pretty well prevented this last issue with current policy. I tried to propose similar policy in the APNIC region, but it was not well accepted there. The folks in Asia seem t want to cling to their scarcity mentality in IPv6 for the time being. I believe RIPE is issuing reasonably generous IPv6 allocations/assignments. I don't know enough about the goings on in AfriNIC or LACNIC to comment with any certainty. > We had this discussion on the list exactly a year ago. At that time, > the average IPv6 origin ASN was announcing 1.43 routes. That figure > today is 1.57 routes per origin ASN. That represents a 10% growth in prefix/asn for IPv6. Compare to 9.3->9.96/ASN (7%) in IPv4 over that same time, While I would agree that this is a trend that merits watching, I think we're probably OK for quite some time. The higher growth rate in IPv6 can be largely attributed to the fact that IPv6 is still in its infancy and we probably haven't seen much IPv6 traffic engineering route manipulation yet. I don't think IPv6 is at all likely even with current policies and trends to reach 9:1. I expect it will most likely settle in somewhere around 2.5:1. Owen From owen at delong.com Fri Mar 9 13:31:45 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Mar 2012 11:31:45 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: Let us not forget that there is also the issue of PA /48s being advertised (quasi-legitimately) for some end-user organizations that are multi-homed but choose not to get PI space. It is not uncommon to obtain a PA /48 from provider A and also advertise it from Provider B. Owen From ml at kenweb.org Fri Mar 9 14:22:56 2012 From: ml at kenweb.org (ML) Date: Fri, 09 Mar 2012 15:22:56 -0500 Subject: IPv6 routing table incomplete! Message-ID: <4F5A66A0.60902@kenweb.org> Not so shocking for people on this list..However after playing around with a single-homed v6 connection to Cogent I was a little surprised to not be missing just HE routes. Apparently Google and Cogent aren't playing nice as I've been unable to reach a number of Google's AAAAs for ipv6.google.com a quick check for paths with _15169_ came up empty. I figured Cogent and Google would be playing nice by now but apparently there is still a rift between these two from May of last year. At least it appears that is when people started noticing weirdness. Has anyone been documenting who has holes in their BGP tables and to where? P.S Also don't seen OCCAID from Cogent...maybe Cogent doesn't like tunnel brokers?? From leo.vegoda at icann.org Fri Mar 9 14:45:18 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 9 Mar 2012 12:45:18 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176EF6@EXVPMBX100-1.exc.icann.org> Owen wrote: [...] > In the ARIN region I think we have pretty well prevented this last issue > with current policy. I tried to propose similar policy in the APNIC region, > but it was not well accepted there. The folks in Asia seem t want to cling > to their scarcity mentality in IPv6 for the time being. I believe RIPE is > issuing reasonably generous IPv6 allocations/assignments. I don't > know enough about the goings on in AfriNIC or LACNIC to comment > with any certainty. You can see the prefix distribution in charts that are updated daily on our stats web site: http://stats.research.icann.org/ HTH, Leo From berni at birkenwald.de Fri Mar 9 14:50:45 2012 From: berni at birkenwald.de (Bernhard Schmidt) Date: Fri, 09 Mar 2012 21:50:45 +0100 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: <4F5A6D25.6070907@birkenwald.de> On 09.03.2012 20:31, Owen DeLong wrote: Hi, > Let us not forget that there is also the issue of PA /48s being > advertised (quasi-legitimately) for some end-user organizations that > are multi-homed but choose not to get PI space. It is not uncommon to > obtain a PA /48 from provider A and also advertise it from Provider > B. While I agree it's not uncommon, I'm not a big fan of this setup. Also, provider A should still have his aggregate announced, which would allow strictly filtering ISPs to reach the destination anyway. Announcing /48s from a PA block without the covering aggregate calls for trouble. Bernhard From dmiller at tiggee.com Fri Mar 9 14:53:37 2012 From: dmiller at tiggee.com (David Miller) Date: Fri, 09 Mar 2012 15:53:37 -0500 Subject: IPv6 routing table incomplete! In-Reply-To: <4F5A66A0.60902@kenweb.org> References: <4F5A66A0.60902@kenweb.org> Message-ID: <4F5A6DD1.9080804@tiggee.com> On 3/9/2012 3:22 PM, ML wrote: > Not so shocking for people on this list..However after playing around > with a single-homed v6 connection to Cogent I was a little surprised > to not be missing just HE routes. > > Apparently Google and Cogent aren't playing nice as I've been unable > to reach a number of Google's AAAAs for ipv6.google.com a quick check > for paths with _15169_ came up empty. > > I figured Cogent and Google would be playing nice by now but > apparently there is still a rift between these two from May of last > year. At least it appears that is when people started noticing > weirdness. > > Has anyone been documenting who has holes in their BGP tables and to > where? > > P.S > > Also don't seen OCCAID from Cogent...maybe Cogent doesn't like tunnel > brokers?? > http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers -DMM From cidr-report at potaroo.net Fri Mar 9 16:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Mar 2012 22:00:00 GMT Subject: BGP Update Report Message-ID: <201203092200.q29M00AN047900@wattle.apnic.net> BGP Update Report Interval: 01-Mar-12 -to- 08-Mar-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS24863 97468 4.4% 116.9 -- LINKdotNET-AS 2 - AS8402 58804 2.6% 28.6 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 50756 2.3% 50.6 -- BSNL-NIB National Internet Backbone 4 - AS12479 27929 1.2% 52.2 -- UNI2-AS France Telecom Espana SA 5 - AS24560 25683 1.1% 25.4 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 6 - AS7552 25635 1.1% 22.0 -- VIETEL-AS-AP Vietel Corporation 7 - AS32528 22256 1.0% 2225.6 -- ABBOTT Abbot Labs 8 - AS5800 20192 0.9% 70.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 9 - AS55515 17671 0.8% 736.3 -- ONE-NET-HK INTERNET-SOLUTION -HK 10 - AS17974 14673 0.7% 9.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 11 - AS20115 14326 0.6% 8.8 -- CHARTER-NET-HKY-NC - Charter Communications 12 - AS2609 14067 0.6% 468.9 -- TN-BB-AS Tunisia BackBone AS 13 - AS28683 13119 0.6% 215.1 -- BENINTELECOM 14 - AS8452 12500 0.6% 9.9 -- TE-AS TE-AS 15 - AS6066 12328 0.6% 6164.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 16 - AS7029 11675 0.5% 4.3 -- WINDSTREAM - Windstream Communications Inc 17 - AS10620 11029 0.5% 6.2 -- Telmex Colombia S.A. 18 - AS18403 10096 0.5% 19.7 -- FPT-AS-AP The Corporation for Financing & Promoting Technology 19 - AS38040 9510 0.4% 452.9 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 20 - AS16960 9455 0.4% 90.0 -- Cablevision Red, S.A de C.V. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6066 12328 0.6% 6164.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 2 - AS32528 22256 1.0% 2225.6 -- ABBOTT Abbot Labs 3 - AS53461 1160 0.1% 1160.0 -- EBTC - Enterprise Bank and Trust Company 4 - AS29933 3255 0.1% 1085.0 -- OFF-CAMPUS-TELECOMMUNICATIONS - Off Campus Telecommunications 5 - AS53362 915 0.0% 915.0 -- MIXIT-AS - Mixit, Inc. 6 - AS55665 880 0.0% 880.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 7 - AS55515 17671 0.8% 736.3 -- ONE-NET-HK INTERNET-SOLUTION -HK 8 - AS13277 1458 0.1% 729.0 -- HP-MS HP-MS Autonomous System 9 - AS19341 3096 0.1% 619.2 -- CYENCE-02 - Cyence International 10 - AS36980 469 0.0% 469.0 -- JOHNHOLT-ASN 11 - AS2609 14067 0.6% 468.9 -- TN-BB-AS Tunisia BackBone AS 12 - AS4 929 0.0% 60.0 -- Maria Irma Salazar 13 - AS38040 9510 0.4% 452.9 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 14 - AS53243 1067 0.1% 355.7 -- 15 - AS51976 314 0.0% 314.0 -- JP-TELEKOM-AS JP-Telekom Sp. z o.o. 16 - AS10986 6157 0.3% 293.2 -- Intermedia Comunicaciones S.A. 17 - AS38528 284 0.0% 284.0 -- LANIC-AS-AP Lao National Internet Committee 18 - AS56886 274 0.0% 274.0 -- REDSTAR-AS OOO "Red Star" 19 - AS36938 264 0.0% 264.0 -- AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 20 - AS46904 262 0.0% 262.0 -- WEITZ-LUX - Weitz & Luxenberg P.C TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/24 11121 0.5% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/24 11119 0.5% AS32528 -- ABBOTT Abbot Labs 3 - 122.161.0.0/16 10382 0.4% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 4 - 182.64.0.0/16 10083 0.4% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 5 - 180.180.250.0/24 9507 0.4% AS23969 -- TOT-MPLS-VPN-AP TOT Public Company Limited AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 6 - 62.36.252.0/22 8378 0.4% AS12479 -- UNI2-AS France Telecom Espana SA 7 - 203.28.157.0/24 6449 0.3% AS4802 -- ASN-IINET iiNet Limited 8 - 62.36.249.0/24 6390 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 9 - 204.29.239.0/24 6166 0.3% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 10 - 150.225.0.0/16 6162 0.3% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 11 - 62.36.241.0/24 5826 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 12 - 62.36.210.0/24 5615 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 13 - 194.63.9.0/24 5382 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 14 - 202.153.174.0/24 3364 0.1% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 15 - 67.214.235.0/24 3243 0.1% AS29933 -- OFF-CAMPUS-TELECOMMUNICATIONS - Off Campus Telecommunications 16 - 109.124.113.0/24 3121 0.1% AS20632 -- PETERSTAR-AS OJSC MegaFon 17 - 204.234.0.0/17 3069 0.1% AS7029 -- WINDSTREAM - Windstream Communications Inc 18 - 217.15.120.0/22 2737 0.1% AS56696 -- ASLIQUID-MPLS Liquid Telecommunications Ltd 19 - 205.73.118.0/24 2727 0.1% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - 205.73.116.0/23 2686 0.1% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 9 16:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Mar 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201203092200.q29M00Mo047895@wattle.apnic.net> This report has been generated at Fri Mar 9 21:12:46 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 02-03-12 401923 232851 03-03-12 401957 232960 04-03-12 402003 232914 05-03-12 401959 232997 06-03-12 402059 233404 07-03-12 402370 233534 08-03-12 402564 233203 09-03-12 402647 233692 AS Summary 40420 Number of ASes in routing system 16913 Number of ASes announcing only one prefix 3459 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 111256096 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'). --- 09Mar12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 403047 233684 169363 42.0% All ASes AS6389 3404 201 3203 94.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3459 1842 1617 46.7% WINDSTREAM - Windstream Communications Inc AS4766 2498 1017 1481 59.3% KIXS-AS-KR Korea Telecom AS22773 1544 120 1424 92.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS2118 1421 14 1407 99.0% RELCOM-AS OOO "NPO Relcom" AS18566 2091 703 1388 66.4% COVAD - Covad Communications Co. AS4323 1609 385 1224 76.1% TWTC - tw telecom holdings, inc. AS28573 1688 466 1222 72.4% NET Servicos de Comunicao S.A. AS4755 1567 417 1150 73.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1884 802 1082 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 1761 768 993 56.4% Telmex Colombia S.A. AS7552 1160 203 957 82.5% VIETEL-AS-AP Vietel Corporation AS7303 1324 422 902 68.1% Telecom Argentina S.A. AS26615 900 30 870 96.7% Tim Celular S.A. AS8402 1714 854 860 50.2% CORBINA-AS OJSC "Vimpelcom" AS8151 1487 670 817 54.9% Uninet S.A. de C.V. AS18101 951 159 792 83.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1093 342 751 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9498 909 228 681 74.9% BBIL-AP BHARTI Airtel Ltd. AS9394 886 209 677 76.4% CRNET CHINA RAILWAY Internet(CRNET) AS7545 1648 988 660 40.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS17974 1735 1087 648 37.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS24560 1005 359 646 64.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1106 462 644 58.2% LEVEL3 Level 3 Communications AS30036 1419 775 644 45.4% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS17676 687 75 612 89.1% GIGAINFRA Softbank BB Corp. AS19262 997 401 596 59.8% VZGNI-TRANSIT - Verizon Online LLC AS15557 1087 499 588 54.1% LDCOMNET Societe Francaise du Radiotelephone S.A AS3549 995 431 564 56.7% GBLX Global Crossing Ltd. AS22561 951 396 555 58.4% DIGITAL-TELEPORT - Digital Teleport Inc. Total 44980 15325 29655 65.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 66.129.0.0/19 AS3901 ARRAKIS - Higher Technology Services 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS14208 74.91.49.0/24 AS14208 74.91.50.0/24 AS14208 74.91.51.0/24 AS14208 74.91.52.0/24 AS14208 74.91.53.0/24 AS14208 74.91.54.0/24 AS14208 74.91.55.0/24 AS14208 74.91.56.0/24 AS14208 74.91.57.0/24 AS14208 74.91.58.0/24 AS14208 74.91.59.0/24 AS14208 74.91.60.0/24 AS14208 74.91.61.0/24 AS14208 74.91.62.0/24 AS14208 74.91.63.0/24 AS14208 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.86.32.0/20 AS18255 BRISBANE-AP Brisbane City Council 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.133.224.0/19 AS4323 TWTC - tw telecom holdings, inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.222.240.0/22 AS19747 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From brandon at rd.bbc.co.uk Fri Mar 9 16:07:36 2012 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 9 Mar 2012 22:07:36 GMT Subject: filtering /48 is going to be necessary Message-ID: <201203092207.WAA09178@sunf10.rd.bbc.co.uk> > From: Owen DeLong > > We had this discussion on the list exactly a year ago. At that time, > > the average IPv6 origin ASN was announcing 1.43 routes. That figure > > today is 1.57 routes per origin ASN. > > That represents a 10% growth in prefix/asn for IPv6. > > Compare to 9.3->9.96/ASN (7%) in IPv4 over that same time, While > I would agree that this is a trend that merits watching, I think > we're probably OK for quite some time. By the time it's a problem it'll not be fixable. I've been a supporter of classful allocation of v6 such as Bill mentioned (http://lists.arin.net/pipermail/arin-ppml/2009-November/015521.html) there's enough space for it but people don't want to do classful again. If there isn't standard filtering of defined prefix/lengths by major carriers then we're just waiting for the problem to arrive. I don't think we'd get enough people to agree on this to avoid it. brandon From jayhanke at gmail.com Fri Mar 9 16:24:31 2012 From: jayhanke at gmail.com (Jay Hanke) Date: Fri, 9 Mar 2012 16:24:31 -0600 Subject: BGP MD5 at IXP Message-ID: How critical is BGP MD5 at Internet Exchange Points? Would lack of support for MD5 authentication on route servers prevent some peers from multilaterally connecting? Do most exchange operators support it? Thanks! Jay From patrick at ianai.net Fri Mar 9 16:27:44 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 9 Mar 2012 17:27:44 -0500 Subject: BGP MD5 at IXP In-Reply-To: References: Message-ID: <91E6D8C3-CA8C-4ED0-B710-673CB1EC20F8@ianai.net> On Mar 9, 2012, at 17:24 , Jay Hanke wrote: > How critical is BGP MD5 at Internet Exchange Points? Would lack of > support for MD5 authentication on route servers prevent some peers > from multilaterally connecting? Do most exchange operators support it? Search for MD5. Most IXP route servers support it, few require it. So even if you do it on your side, doesn't mean someone else did it on their side. I've never seen anyone refuse to connect to an IXP route server that did not, but that doesn't mean it hasn't happened. -- TTFN, patrick From owen at delong.com Fri Mar 9 17:02:13 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Mar 2012 15:02:13 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: <4F5A6D25.6070907@birkenwald.de> References: <4F5A6D25.6070907@birkenwald.de> Message-ID: <053DCC31-AE1D-417B-8A54-05E36923C759@delong.com> On Mar 9, 2012, at 12:50 PM, Bernhard Schmidt wrote: > On 09.03.2012 20:31, Owen DeLong wrote: > > Hi, > >> Let us not forget that there is also the issue of PA /48s being >> advertised (quasi-legitimately) for some end-user organizations that >> are multi-homed but choose not to get PI space. It is not uncommon to >> obtain a PA /48 from provider A and also advertise it from Provider >> B. > > While I agree it's not uncommon, I'm not a big fan of this setup. Also, provider A should still have his aggregate announced, which would allow strictly filtering ISPs to reach the destination anyway. > I'm not a big fan, either, but, I think that the concept of "be conservative in what you announce and liberal in what you accept" has to apply in this case. Since it is a common (quasi-)legitimate practice, arbitrarily filtering it is ill-advised IMHO. The statement about the covering aggregate assumes that there are no failures in the union of {site, loop, provider A}. In the event that there is such a failure, the aggregate may not help and may even be harmful. Since one of the key purposes of this kind of multihoming is to provide coverage in the event of such a failure, filtration of the more-specific seems to defeat the purpose. > Announcing /48s from a PA block without the covering aggregate calls for trouble. No question. However, the covering aggregate alone is also insufficient. Owen From owen at delong.com Fri Mar 9 17:05:13 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Mar 2012 15:05:13 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: <201203092207.WAA09178@sunf10.rd.bbc.co.uk> References: <201203092207.WAA09178@sunf10.rd.bbc.co.uk> Message-ID: <1586046E-CBDC-472B-9255-F4E5169AB932@delong.com> On Mar 9, 2012, at 2:07 PM, Brandon Butterworth wrote: >> From: Owen DeLong >>> We had this discussion on the list exactly a year ago. At that time, >>> the average IPv6 origin ASN was announcing 1.43 routes. That figure >>> today is 1.57 routes per origin ASN. >> >> That represents a 10% growth in prefix/asn for IPv6. >> >> Compare to 9.3->9.96/ASN (7%) in IPv4 over that same time, While >> I would agree that this is a trend that merits watching, I think >> we're probably OK for quite some time. > > By the time it's a problem it'll not be fixable. > > I've been a supporter of classful allocation of v6 such as Bill mentioned > (http://lists.arin.net/pipermail/arin-ppml/2009-November/015521.html) > there's enough space for it but people don't want to do classful again. > > If there isn't standard filtering of defined prefix/lengths by major > carriers then we're just waiting for the problem to arrive. I don't > think we'd get enough people to agree on this to avoid it. > > brandon My opposition to this ill-conceived idea has nothing to do with favor of nor opposition to classful addressing. My opposition comes from the fact that this could very easily become an additional tool used by larger players in the peering wars to disadvantage smaller players. Handing one side an RIR-sponsored tactical nuclear weapon is, IMHO, on the face of it a bad idea. The proposal for classful allocation that Bill floated in the thread above would constitute doing exactly that. If you will review the thread, you will find that is my stated reason for opposition at the time as well. Owen From mysidia at gmail.com Fri Mar 9 17:20:03 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 9 Mar 2012 17:20:03 -0600 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: On Fri, Mar 9, 2012 at 1:31 PM, Owen DeLong wrote: > Let us not forget that there is also the issue of PA /48s being advertised (quasi-legitimately) for some end-user organizations that are multi-homed but choose not to get PI space. It is not uncommon to obtain a PA /48 from provider A and also advertise it from Provider B. What should happen is this "quasi-legitimate" method of multi-homing should just be declared illegitimate for IPv6, to facilitate stricter filtering. Instead, what should happen is the multi-homing should be required to fit into one of 3 scenarios, so any announcement with an IPv6 prefix length other than the RIR-allocated/assigned PA or PI block size can be treated as TE and summarily discarded or prioritizes when table resources are scarce. Scenario (1) The end user org obtains PI address space from a RIR, and originates their assigned prefix. The end user org originates their RIR assigned exact prefix and announces to their upstreams, who filter and accept from the end user only routes containing a NLRI of their exact prefix, with the prefix length used by the RIR for the PI blocks from which their assignment(s) had been made. (2) Same as (1) but The RIR provides some expedited process for the ISP to obtain and transfer PI space and AS numbers for the purpose of their customers' multihoming - in one step, so the end user does not have to figure out the RIR application process -- E.g. some RIR process provides the ISP an option to create PI blocks on demand in addition to their PA block; the ISP will not know in advance what AS number or PI block will be allocated, the ISP must follow the RIR rules for the assignment of PI blocks, and educate their user as needed, obtain a signed RSA with the End user, obtain written proof the user has two ISPs, has provided a network design that includes multihoming, and a written sound justification for the multi-homing or the meeting of a criteria requiring multihoming, provide the End User's billing contact info to the RIR, the ISP having pre-payed registration fees to the RIR --- should the end user stop using the ISP that created the block, responsibility for the PI block and AS numbers reverts to the end user org. (3) The end user org who is multi-homed picks a 3rd party organization to assign to the end user from their PA block. The 3rd party org's overall PA block is multihomed with diverse connectivity, and the end user inherits the multihoming of the 3rd party's PA block. The 3rd party AS is the sole AS that originates the prefix in the form of the entire PA block into the DFZ and then routes the individually assigned end-user block to the End user through private arrangement or peering with the End user orgs' upstreams, (IOW: the multi-homed users block does not appear as a globally visible more-specific/deaggregate) (4) Any of the other methods of achieving multi-homing, such as originating an NLRI with a longer prefix than the RIR delegation, should be rejected by filters. > Owen -- -JH From sander at steffann.nl Fri Mar 9 17:32:59 2012 From: sander at steffann.nl (Sander Steffann) Date: Sat, 10 Mar 2012 00:32:59 +0100 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> Hi, > What should happen is this "quasi-legitimate" method of > multi-homing should just be declared illegitimate for IPv6, to > facilitate stricter filtering. Instead, what should happen is the > multi-homing should be required to fit into one of 3 scenarios, so > any announcement with an IPv6 prefix length other than the > RIR-allocated/assigned PA or PI block size can be treated as TE and > summarily discarded or prioritizes when table resources are scarce. Splitting the allocation can be done for many reasons. There are known cases where one LIR operates multiple separate networks, each with a separate routing policy. They cannot get multiple allocations from the RIR and they cannot announce the whole allocation as a whole because of the separate routing policies (who are sometimes required legally, for example when an NREN has both a commercial and an educational network). Deaggregating to /48's is not a good idea, but giving an LIR a few bits (something like 3 or 4) to deaggregate makes sense. - Sander From mysidia at gmail.com Fri Mar 9 17:38:19 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 9 Mar 2012 17:38:19 -0600 Subject: filtering /48 is going to be necessary In-Reply-To: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> Message-ID: On Fri, Mar 9, 2012 at 5:32 PM, Sander Steffann wrote: > Splitting the allocation can be done for many reasons. There are known cases where one LIR >operates multiple separate networks, each with a separate routing policy. They cannot get multiple >allocations from the RIR and they cannot announce the whole allocation as a whole because of the >separate routing policies (who are sometimes required legally, for example when an NREN has both a >commercial and an educational network). Deaggregating to /48's is not a good idea, but giving an LIR It does make sense to give the LIR a few bits. Note though I say what "should" happen. What will happen in actual fact, is probably going to be identical to IPv4. End users will go to other ISPs and demand they carry their individual /64s; resulting market pressure is more powerful than efficient design. -- -JH From george.herbert at gmail.com Fri Mar 9 17:40:34 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 9 Mar 2012 15:40:34 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> Message-ID: If the LIRs cannot get separate allocations from the RIR (and separate ASNs) for this usage, something is wrong. We want to make things as simple and efficient as possible, but no simpler or more efficient, because the curves go back up again at that point, and we all suffer. -george On Fri, Mar 9, 2012 at 3:32 PM, Sander Steffann wrote: > Hi, > >> What should happen is this ?"quasi-legitimate" ?method ?of >> multi-homing should just be declared illegitimate for IPv6, to >> facilitate stricter filtering. Instead, what should happen is the >> multi-homing should be required to fit into one of 3 scenarios, ?so >> any announcement with an IPv6 prefix length other than the >> RIR-allocated/assigned PA or PI block size can be ?treated as TE and >> summarily discarded or prioritizes when table resources are scarce. > > Splitting the allocation can be done for many reasons. There are known cases where one LIR operates multiple separate networks, each with a separate routing policy. They cannot get multiple allocations from the RIR and they cannot announce the whole allocation as a whole because of the separate routing policies (who are sometimes required legally, for example when an NREN has both a commercial and an educational network). Deaggregating to /48's is not a good idea, but giving an LIR a few bits (something like 3 or 4) to deaggregate makes sense. > > - Sander > > -- -george william herbert george.herbert at gmail.com From leo.vegoda at icann.org Fri Mar 9 17:45:41 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 9 Mar 2012 15:45:41 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> Hi, Sander wrote: > Splitting the allocation can be done for many reasons. There are known cases where one LIR operates multiple separate networks, each with a separate routing policy. They cannot get multiple allocations from the RIR and they cannot announce the whole allocation as a whole because of the separate routing policies (who are sometimes required legally, for example when an NREN has both a commercial and an educational network). If they have two different routing policies and need two different allocations, why not just have two different LIRs? It makes things a lot easier than spending untold weeks or time trying to work out which corner cases should be supported by policy and which should not. No? Leo From brandon at rd.bbc.co.uk Fri Mar 9 18:33:27 2012 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 10 Mar 2012 00:33:27 GMT Subject: filtering /48 is going to be necessary Message-ID: <201203100033.AAA23170@sunf10.rd.bbc.co.uk> > From: Owen DeLong > Handing one side an RIR-sponsored > tactical nuclear weapon is, IMHO, on the face of it a bad idea. The > proposal for classful allocation that Bill floated in the thread above > would constitute doing exactly that Certainly a risk but then we handed every nutter with BGP a dirty nuclear bomb instead. brandon From cmadams at hiwaay.net Fri Mar 9 20:40:04 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 9 Mar 2012 20:40:04 -0600 Subject: AT&T home DSL IPv6 configuration? Message-ID: <20120310024004.GA32680@hiwaay.net> I have some friends and family in various places that have AT&T DSL. At least one has been upgraded to IPv6 support (I connected my notebook to his wireless router and was suprised to see I logged into my server over IPv6). As they tend to ask me for help now and then, I was trying to see how AT&T configured IPv6 for their residential DSL customers, but I can't find anything on their site. They only talk about the routers they sell, and if you don't have one of those, they link to their store to buy one. Can anybody tell me how they are configuring their IPv6 setup? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From gbonser at seven.com Fri Mar 9 21:08:46 2012 From: gbonser at seven.com (George Bonser) Date: Sat, 10 Mar 2012 03:08:46 +0000 Subject: filtering /48 is going to be necessary In-Reply-To: <053DCC31-AE1D-417B-8A54-05E36923C759@delong.com> References: <4F5A6D25.6070907@birkenwald.de> <053DCC31-AE1D-417B-8A54-05E36923C759@delong.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D0C786@RWC-MBX1.corp.seven.com> > Owen said: > > I'm not a big fan, either, but, I think that the concept of "be > conservative in what you announce and liberal in what you accept" has > to apply in this case. Since it is a common (quasi-)legitimate > practice, arbitrarily filtering it is ill-advised IMHO. While I agree in principle, 16 bits of disaggregation has the potential for a lot of mayhem and 32 bits (accepting /64 from PA) would be catastrophic. This would seem to be a case where upstream providers can assist the end user in obtaining their own PI space if they wish to multihome. It would be in the provider's interest as it would reduce the number of potential complaints from customers concerning multihoming problems. I filter /32 from PA space and am currently filtering one route but since the aggregate it is from has the same next hop and since I don't see the route from anyone else, I'm not worried about it. From gbonser at seven.com Fri Mar 9 21:10:05 2012 From: gbonser at seven.com (George Bonser) Date: Sat, 10 Mar 2012 03:10:05 +0000 Subject: filtering /48 is going to be necessary In-Reply-To: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D0C797@RWC-MBX1.corp.seven.com> > Deaggregating to /48's is not a good idea, but giving an LIR a few bits > (something like 3 or 4) to deaggregate makes sense. > > - Sander > +1 I wouldn't have a problem with a few bits of disaggregation. That seems reasonable for a network that might be subject to partitioning or doesn't have a fully meshed internal net. From owen at delong.com Fri Mar 9 22:41:00 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Mar 2012 20:41:00 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> Message-ID: <778F4048-F40C-403E-9D84-DA5E55E75538@delong.com> This varies from RIR to RIR. In the ARIN region, you can get assignments or allocations for Multiple Discreet Networks, but, ARIN will often register them as an aggregate in the registration database, so... In the RIPE region (which is where I believe Sander is), only aggregates are available to the best of my knowledge. Owen On Mar 9, 2012, at 3:40 PM, George Herbert wrote: > If the LIRs cannot get separate allocations from the RIR (and separate > ASNs) for this usage, something is wrong. > > We want to make things as simple and efficient as possible, but no > simpler or more efficient, because the curves go back up again at that > point, and we all suffer. > > > -george > > On Fri, Mar 9, 2012 at 3:32 PM, Sander Steffann wrote: >> Hi, >> >>> What should happen is this "quasi-legitimate" method of >>> multi-homing should just be declared illegitimate for IPv6, to >>> facilitate stricter filtering. Instead, what should happen is the >>> multi-homing should be required to fit into one of 3 scenarios, so >>> any announcement with an IPv6 prefix length other than the >>> RIR-allocated/assigned PA or PI block size can be treated as TE and >>> summarily discarded or prioritizes when table resources are scarce. >> >> Splitting the allocation can be done for many reasons. There are known cases where one LIR operates multiple separate networks, each with a separate routing policy. They cannot get multiple allocations from the RIR and they cannot announce the whole allocation as a whole because of the separate routing policies (who are sometimes required legally, for example when an NREN has both a commercial and an educational network). Deaggregating to /48's is not a good idea, but giving an LIR a few bits (something like 3 or 4) to deaggregate makes sense. >> >> - Sander >> >> > > > > -- > -george william herbert > george.herbert at gmail.com From owen at delong.com Fri Mar 9 22:46:25 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Mar 2012 20:46:25 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: <201203100033.AAA23170@sunf10.rd.bbc.co.uk> References: <201203100033.AAA23170@sunf10.rd.bbc.co.uk> Message-ID: On Mar 9, 2012, at 4:33 PM, Brandon Butterworth wrote: >> From: Owen DeLong >> Handing one side an RIR-sponsored >> tactical nuclear weapon is, IMHO, on the face of it a bad idea. The >> proposal for classful allocation that Bill floated in the thread above >> would constitute doing exactly that > > Certainly a risk but then we handed every nutter with BGP a > dirty nuclear bomb instead. > > brandon More like a small grenade which can be easily defused by their upstream at will. Owen From owen at delong.com Fri Mar 9 22:45:40 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Mar 2012 20:45:40 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: > > (4) Any of the other methods of achieving multi-homing, such as > originating an NLRI with a longer prefix than the RIR delegation, > should be rejected by filters. > >> Owen > -- > -JH It is very rare that I will quote Randy Bush. Even more so when his original quote was utterly misplaced in the original context. However, in this case I will make an exception... "We don't need policy weenies telling us how to run our networks." --Randy Bush (from APNIC Policy SIG discussion of Prop-098) Owen From owen at delong.com Fri Mar 9 22:42:04 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Mar 2012 20:42:04 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> Message-ID: On Mar 9, 2012, at 3:45 PM, Leo Vegoda wrote: > Hi, > > Sander wrote: > >> Splitting the allocation can be done for many reasons. There are known cases where one LIR operates multiple separate networks, each with a separate routing policy. They cannot get multiple allocations from the RIR and they cannot announce the whole allocation as a whole because of the separate routing policies (who are sometimes required legally, for example when an NREN has both a commercial and an educational network). > > If they have two different routing policies and need two different allocations, why not just have two different LIRs? It makes things a lot easier than spending untold weeks or time trying to work out which corner cases should be supported by policy and which should not. No? > > Leo This may depend on where you are. Being two LIRs in the ARIN region requires setting up two complete legal entities which is a lot of overhead to carry for just that purpose. Owen From joelja at bogus.com Fri Mar 9 23:33:11 2012 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 09 Mar 2012 21:33:11 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> Message-ID: <4F5AE797.6010702@bogus.com> On 3/9/12 20:42 , Owen DeLong wrote: > > On Mar 9, 2012, at 3:45 PM, Leo Vegoda wrote: > >> Hi, >> >> Sander wrote: >> >>> Splitting the allocation can be done for many reasons. There are >>> known cases where one LIR operates multiple separate networks, >>> each with a separate routing policy. They cannot get multiple >>> allocations from the RIR and they cannot announce the whole >>> allocation as a whole because of the separate routing policies >>> (who are sometimes required legally, for example when an NREN >>> has both a commercial and an educational network). >> >> If they have two different routing policies and need two different >> allocations, why not just have two different LIRs? It makes things >> a lot easier than spending untold weeks or time trying to work out >> which corner cases should be supported by policy and which should >> not. No? >> >> Leo > > > This may depend on where you are. Being two LIRs in the ARIN region > requires setting up two complete legal entities which is a lot of > overhead to carry for just that purpose. > > Owen > I'll put this as bluntly and succinctly as I can because I find the LIR distriction arbitrary... I have an ipv6 direct assignment from ARIN. It is sized to meet the needs of my enterprise consistent with needs for future growth number of pops, prevailing ARIN policy etc. Because my network is discontiguous I must announce more specific routes than the assignment in order to reflect the topology I have both in IPV4 and in IPV6. I fully expect (and have no evidence to the contrary) that my transit providers will accept the deaggreated prefixes and that their upstreams and peers will by-in-large do likewise. I have no interest in the general sense of deaggregating beyond the level required by the topological considerations. Imposing arbitary political considerations on organizations that are simply trying to operate networks in order preserve maximal aggregation at a given level seems absurd on the face of it. I am reasonably certain that every wholesale transit provider on this list that offers ipv6 transit would be willing to accept by money and route my prefixes in their current form. From randy at psg.com Fri Mar 9 23:52:50 2012 From: randy at psg.com (Randy Bush) Date: Sat, 10 Mar 2012 14:52:50 +0900 Subject: filtering /48 is going to be necessary In-Reply-To: <4F5AE797.6010702@bogus.com> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> Message-ID: > Imposing arbitary political considerations on organizations that are > simply trying to operate networks in order preserve maximal > aggregation at a given level seems absurd on the face of it. arin policy weenies live for this! randy From gbonser at seven.com Sat Mar 10 00:02:00 2012 From: gbonser at seven.com (George Bonser) Date: Sat, 10 Mar 2012 06:02:00 +0000 Subject: filtering /48 is going to be necessary In-Reply-To: <4F5AE797.6010702@bogus.com> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> > I'll put this as bluntly and succinctly as I can because I find the LIR > distriction arbitrary... > > I have an ipv6 direct assignment from ARIN. I am assuming you are an enterprise in PI space and not an ISP in PA space? > It is sized to meet the needs of my enterprise consistent with needs > for future growth number of pops, prevailing ARIN policy etc. > > Because my network is discontiguous I must announce more specific > routes than the assignment in order to reflect the topology I have both > in IPV4 and in IPV6. > I fully expect (and have no evidence to the contrary) that my transit > providers will accept the deaggreated prefixes and that their upstreams > and peers will by-in-large do likewise. If you are in PI space, I believe most people take down to a /48 as a /48 is generally accepted to be a single "site". So let's say you were given a /40 and have several disconnected sites. Most people are going to accept a /48 from you in PI space. I would say pretty close to "everyone" is going to accept a /48 from PI space. An ISP that has been given a /32 or larger allocation from PA space and might have 10,000 customers each assigned their own /48 could instantly more than double the size of the IPv6 routing table if they disaggregated that /32. The problem here is that each /32 is 65536 /48 networks. An even larger net, say a /30 that disaggregates due to a router configuration goof means a potential of a huge number of networks suddenly flooding the Internet. From mysidia at gmail.com Sat Mar 10 00:14:32 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 10 Mar 2012 00:14:32 -0600 Subject: filtering /48 is going to be necessary In-Reply-To: <4F5AE797.6010702@bogus.com> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> Message-ID: On Fri, Mar 9, 2012 at 11:33 PM, Joel jaeggli wrote: > On 3/9/12 20:42 , Owen DeLong wrote: > Because my network is discontiguous I must announce more specific routes > than the assignment in order to reflect the topology I have both in IPV4 > and in IPV6. > > I fully expect (and have no evidence to the contrary) that my transit > providers will accept the deaggreated prefixes and that their upstreams > and peers will by-in-large do likewise. I have no doubt any transit provider would be happy to provide the transit for your discontiguous network, and accept your deaggregates within their network. The unreasonable expectation is that their upstreams or peers would carry all the deaggregates in the long run. Connectivity for your discontiguous networks are your problem to solve, and as long as router memory is at a premium, limiting what deaggregates are accepted will be important. The peers want best connectivity to you at least cost for them. > I have no interest in the general sense of deaggregating beyond the > level required by the topological considerations. You don't have such an interest, but sloppy practices prevail on average. As evidenced in IPv4 by large blocks with all the /24s showing up. > Imposing arbitary political considerations on organizations that are Not political considerations, technical restrictions, which are design constraints. There are already plenty such design constraints that are imposed by RFC; interconnecting networks doesn't have a reliable result without some technical ground rules that provide for interoperability, stability, and predictability. > simply trying to operate networks in order preserve maximal aggregation > at a given level seems absurd on the face of it. So for any network you provide transit to, in IPv4 you would be happy to allow them to announce their /12 as 13,1072 /29s, because they have 131072 subnets, and they could reasonably expect that all your peers would be happy to propagate the /29s, for the purpose of making sure the end user's design is not constrained (although at the peer's expense for increased equipment capacity) ? There's an unwritten rule somewhere, that you don't expect longer than a /24 to propagate far with high degree of certainty. With IPv6 instead of picking some arbitrary number liek /48 or /64, it should be based on the RIR allocation unit size and type of allocation, for best results. That's more rational than what we have with IPv4 -- -JH From me at anuragbhatia.com Sat Mar 10 00:16:25 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 10 Mar 2012 11:46:25 +0530 Subject: Questions about anycasting setup In-Reply-To: <4F59D37C.2090109@altadena.net> References: <20120309081131.GC17726@h.detebe.org> <20120309093423.GG17726@h.detebe.org> <4F59D37C.2090109@altadena.net> Message-ID: Thanks for guidance everyone! Appreciate it. And yes, I can see another thread running on discussion about /48 - I am listening silently about it. Multiple AS doing anycasting was little concern for me, but now seems good since I can see everyone's suggestion to use single own ASN for anycasting. On Fri, Mar 9, 2012 at 3:25 PM, Pete Carah wrote: > On 03/09/2012 01:34 AM, Elmar K. Bins wrote: > > Re Bill, > > > > woody at pch.net (Bill Woodcock) wrote: > > > >>> Well, let's say, using Quagga/BIRD might not really be best practice > for > >>> everybody... (e.g., *we* are using Cisco equipment for this) > >> How does your Cisco know whether an adjacent nameserver is heavily > loaded, and adjust its BGP announcements accordingly? > > It doesn't have to. > > > > I don't know how you guys do it, but we take great care to > > keep min. 70% overhead capacity during standard operation. > > > My point had to do with resilience in the face of hardware/OS/software > failures in the box providing the > service. Bill's has more to do with resilience in the face of other > network events (e.g. the upstream for one > of the boxes has a DDOS; you cannot reasonably provide enough excess > capacity to handle that...) Neither of these is addressed by using a > separate router to announce the server's anycast route. (unless somehow > the Cisco is providing the anycasted service, which would address my > concern but still not Bill's.) > > Also, Bill is probably talking root (or bigger public) servers whose > load comes from "off-site"; the average load characteristics for those > are well known but there can be extremes that would be hard to plan for > (hint - operating at 30% isn't really good enough, probably not 10% > either. Bill (and the other Bill) have pretty good stats for this that > I've only glanced at...) And it is easy to see where one of the > extremes might hit only one or two of the anycast instances. He implies > having the instances talking to each other in background to adjust bgp > announcements to maybe help level things. Fortunately at least for the > root servers, the redundancy is at two levels and anycast is only one of > them. > > -- Pete > > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From me at anuragbhatia.com Sat Mar 10 00:19:44 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 10 Mar 2012 11:49:44 +0530 Subject: Concern about gTLD servers in India Message-ID: Hello everyone, Greetings from India. I hope lot of you have enjoyed APRICOT event at New Delhi. I wanted to bring an important issue. It's about DNS root servers in India. So anurag at laptop:~$ dig . ns +short i.root-servers.net. e.root-servers.net. j.root-servers.net. l.root-servers.net. k.root-servers.net. d.root-servers.net. h.root-servers.net. f.root-servers.net. m.root-servers.net. c.root-servers.net. a.root-servers.net. g.root-servers.net. b.root-servers.net. I can see India has 3 root servers hosting root zone - i, j & k in India which is good. So we can resolve the root zone i.e dot within India. Next, looking gTLD servers used by popular TLDs like com/net/org: anurag at laptop:~$ dig com. ns +short g.gtld-servers.net. f.gtld-servers.net. a.gtld-servers.net. h.gtld-servers.net. e.gtld-servers.net. d.gtld-servers.net. j.gtld-servers.net. i.gtld-servers.net. c.gtld-servers.net. m.gtld-servers.net. l.gtld-servers.net. k.gtld-servers.net. b.gtld-servers.net. None of these gTLD root servers are in India. I have tested routes to each of them from BSNL (AS9829), Tata Comm (AS4755 & AS6453), Airtel (AS9498) - all land up outside India - most of them in Europe and US, and couple of them in Singapore, and one in Australia. Why so? Please correct me if I am wrong on this analysis but this seems not efficient setup to me. Any damage on outside connectivity (which is common with Earthquakes or ships hitting submarine fiber, and eventually opposite route getting chocked with traffic) - can cause huge issues on sites which are hosted within India. And so this is how google.com is resolved in India: anurag at laptop:~$ dig google.com +trace ; <<>> DiG 9.7.1-P2 <<>> google.com +trace ;; global options: +cmd . 11352 IN NS i.root-servers.net. . 11352 IN NS e.root-servers.net. . 11352 IN NS j.root-servers.net. . 11352 IN NS l.root-servers.net. . 11352 IN NS k.root-servers.net. . 11352 IN NS d.root-servers.net. . 11352 IN NS h.root-servers.net. . 11352 IN NS f.root-servers.net. . 11352 IN NS m.root-servers.net. . 11352 IN NS c.root-servers.net. . 11352 IN NS a.root-servers.net. . 11352 IN NS g.root-servers.net. . 11352 IN NS b.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 57 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. ;; Received 491 bytes from 128.63.2.53#53(h.root-servers.net) in 264 ms - Hitting outside root server, but anyways alternate i,j,k are up in India so good overall. google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. ;; Received 164 bytes from 192.5.6.30#53(a.gtld-servers.net) in 315 ms - Hitting outside server and it will always hit outside since no server here. Problem. google.com. 300 IN A 173.194.36.3 google.com. 300 IN A 173.194.36.4 google.com. 300 IN A 173.194.36.0 google.com. 300 IN A 173.194.36.2 google.com. 300 IN A 173.194.36.8 google.com. 300 IN A 173.194.36.1 google.com. 300 IN A 173.194.36.5 google.com. 300 IN A 173.194.36.7 google.com. 300 IN A 173.194.36.6 google.com. 300 IN A 173.194.36.14 google.com. 300 IN A 173.194.36.9 ;; Received 204 bytes from 216.239.32.10#53(ns1.google.com) in 305 ms Also, looking at reverse DNS root servers: anurag at laptop:~$ dig in-addr.arpa. ns +short a.in-addr-servers.arpa. b.in-addr-servers.arpa. c.in-addr-servers.arpa. d.in-addr-servers.arpa. e.in-addr-servers.arpa. f.in-addr-servers.arpa. Again, none of these hosted in India. So for each email sent within any domains across India - during smtp check, rDNS is resolved from outside world? (SMTP auth. being one of mail roles of rDNS besides few others). I have collected data about paths from popular Indian backbones to each of these servers. If anyone interested, please let me know. *Sidenote: I know NANOG is primarily for North America but I really appreciate good replies and was wondering if someone can tell me if my understanding is wrong.* Very much interested in hearing comments from community on this. Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From joelja at bogus.com Sat Mar 10 00:32:13 2012 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 09 Mar 2012 22:32:13 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> Message-ID: <4F5AF56D.4010902@bogus.com> On 3/9/12 22:02 , George Bonser wrote: > An ISP that has been given a /32 or larger allocation from PA space > and might have 10,000 customers each assigned their own /48 could > instantly more than double the size of the IPv6 routing table if they > disaggregated that /32. > > The problem here is that each /32 is 65536 /48 networks. An even > larger net, say a /30 that disaggregates due to a router > configuration goof means a potential of a huge number of networks > suddenly flooding the Internet. I'm well into my second decade of having a v6 prefix in the dfz and am passingly familiar with powers of two... From owen at delong.com Sat Mar 10 00:48:31 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 9 Mar 2012 22:48:31 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D0C786@RWC-MBX1.corp.seven.com> References: <4F5A6D25.6070907@birkenwald.de> <053DCC31-AE1D-417B-8A54-05E36923C759@delong.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C786@RWC-MBX1.corp.seven.com> Message-ID: <4A0A5B49-3E64-458C-B745-9A873A6A2DAA@delong.com> On Mar 9, 2012, at 7:08 PM, George Bonser wrote: >> Owen said: >> >> I'm not a big fan, either, but, I think that the concept of "be >> conservative in what you announce and liberal in what you accept" has >> to apply in this case. Since it is a common (quasi-)legitimate >> practice, arbitrarily filtering it is ill-advised IMHO. > > While I agree in principle, 16 bits of disaggregation has the potential for a lot of mayhem and 32 bits (accepting /64 from PA) would be catastrophic. This would seem to be a case where upstream providers can assist the end user in obtaining their own PI space if they wish to multihome. It would be in the provider's interest as it would reduce the number of potential complaints from customers concerning multihoming problems. > > I filter /32 from PA space and am currently filtering one route but since the aggregate it is from has the same next hop and since I don't see the route from anyone else, I'm not worried about it. I haven't heard anyone advocate accepting less than a /48. I think /48 is a reasonable "You must be this tall to ride" barrier. Beyond that, YMMV. Owen From gbonser at seven.com Sat Mar 10 00:52:50 2012 From: gbonser at seven.com (George Bonser) Date: Sat, 10 Mar 2012 06:52:50 +0000 Subject: filtering /48 is going to be necessary In-Reply-To: <4F5AF56D.4010902@bogus.com> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> > > I'm well into my second decade of having a v6 prefix in the dfz and am > passingly familiar with powers of two... > Point is that expecting people globally to take a /48 from PA space probably isn't a realistic expectation. From scg at gibbard.org Sat Mar 10 00:57:02 2012 From: scg at gibbard.org (Steve Gibbard) Date: Fri, 9 Mar 2012 22:57:02 -0800 Subject: Questions about anycasting setup In-Reply-To: <4F59C701.3090503@altadena.net> References: <20120309081131.GC17726@h.detebe.org> <4F59C701.3090503@altadena.net> Message-ID: <2763367C-26BA-4330-812E-C5898E154D14@gibbard.org> On Mar 9, 2012, at 1:01 AM, Pete Carah wrote: >> Well, let's say, using Quagga/BIRD might not really be best practice for >> everybody... (e.g., *we* are using Cisco equipment for this) > Actually there is a *very* good reason why many (most?) anycast > instances use quagga/BIRD/gated/etc > to speak bgp (or even ospf for internal anycast) which using a Cisco (or > any separate router) usually won't accomplish. I've done this two ways. I've used Quagga to announce routes directly from the anycast servers. This guarantees you that the route will go away if the server completely goes away, and that traffic will be directed elsewhere. It also allows you to run scripts on the servers that can withdraw the routes in other circumstances, such as if a script running on the server detects that the server is non-responsive (or overloaded). I've used load balancers in front of the name servers. Like Quagga running directly on the server, a load balancer can withdraw routes when all servers behind it stop responding. It has some advantages, in that it can withdraw routes to non-responsive servers even in cases where the server may be too confused to detect its own problems and send the appropriate messages to Quagga. It can spread load among a larger collection of servers than a router would be able to on its own, sit in front of the servers and do rate limiting, and things like that. It could help with the overload issue Bill mentions by selectively sending some queries to other sites without the all or nothing effect you get from a BGP route withdrawal. On the other hand, load balancers aren't cheap, and and once installed in the middle of a network they become one more device to fail. I have no idea what Cisco equipment Elmar is using, but I wouldn't jump to the conclusion that it can't withdraw routes when needed. -Steve From gbonser at seven.com Sat Mar 10 01:01:54 2012 From: gbonser at seven.com (George Bonser) Date: Sat, 10 Mar 2012 07:01:54 +0000 Subject: filtering /48 is going to be necessary In-Reply-To: <4A0A5B49-3E64-458C-B745-9A873A6A2DAA@delong.com> References: <4F5A6D25.6070907@birkenwald.de> <053DCC31-AE1D-417B-8A54-05E36923C759@delong.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C786@RWC-MBX1.corp.seven.com> <4A0A5B49-3E64-458C-B745-9A873A6A2DAA@delong.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D0C920@RWC-MBX1.corp.seven.com> > I haven't heard anyone advocate accepting less than a /48. I think /48 > is a reasonable "You must be this tall to ride" barrier. > > Beyond that, YMMV. > > Owen Apparently AS6939 has at various times :) I remember getting some /64 announcements from HE. I haven't seen one lately, though. I'm only filtering one /64 route these days announced by AS4651 From graham at apolix.co.za Sat Mar 10 01:05:12 2012 From: graham at apolix.co.za (Graham Beneke) Date: Sat, 10 Mar 2012 09:05:12 +0200 Subject: Concern about gTLD servers in India In-Reply-To: References: Message-ID: <4F5AFD28.9010103@apolix.co.za> On 10/03/2012 08:19, Anurag Bhatia wrote: > Next, looking gTLD servers used by popular TLDs like com/net/org: > > > None of these gTLD root servers are in India. I have tested routes to each > of them from BSNL (AS9829), Tata Comm (AS4755& AS6453), Airtel (AS9498) - > all land up outside India - most of them in Europe and US, and couple of > them in Singapore, and one in Australia. Why so? Please correct me if I am > wrong on this analysis but this seems not efficient setup to me. Any damage > on outside connectivity (which is common with Earthquakes or ships hitting > submarine fiber, and eventually opposite route getting chocked with > traffic) - can cause huge issues on sites which are hosted within India. This problem is unfortunately not unique to India. There appear to be no anycast instances of the gTLD servers in Africa either. I am 180-500ms away from the gTLD servers right now. > Also, looking at reverse DNS root servers: > > anurag at laptop:~$ dig in-addr.arpa. ns +short > a.in-addr-servers.arpa. > b.in-addr-servers.arpa. > c.in-addr-servers.arpa. > d.in-addr-servers.arpa. > e.in-addr-servers.arpa. > f.in-addr-servers.arpa. These servers are operated by the RIRs. Its probably worth contacting APNIC to find out how to get an anycast instance installed at you local internet exchange point. -- Graham Beneke From gbonser at seven.com Sat Mar 10 01:08:21 2012 From: gbonser at seven.com (George Bonser) Date: Sat, 10 Mar 2012 07:08:21 +0000 Subject: filtering /48 is going to be necessary In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D0C920@RWC-MBX1.corp.seven.com> References: <4F5A6D25.6070907@birkenwald.de> <053DCC31-AE1D-417B-8A54-05E36923C759@delong.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C786@RWC-MBX1.corp.seven.com> <4A0A5B49-3E64-458C-B745-9A873A6A2DAA@delong.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C920@RWC-MBX1.corp.seven.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D0C94C@RWC-MBX1.corp.seven.com> > I'm only > filtering one /64 route these days announced by AS4651 > > Actually AS4651 is announcing it to me but it is originating from AS23883 via AS4750 so there are some folks out there taking /64 routes. That one hit my filters, though. From randy at psg.com Sat Mar 10 01:12:40 2012 From: randy at psg.com (Randy Bush) Date: Sat, 10 Mar 2012 16:12:40 +0900 Subject: Concern about gTLD servers in India In-Reply-To: <4F5AFD28.9010103@apolix.co.za> References: <4F5AFD28.9010103@apolix.co.za> Message-ID: > This problem is unfortunately not unique to India. There appear to be no > anycast instances of the gTLD servers in Africa either. really!? From me at anuragbhatia.com Sat Mar 10 01:13:57 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 10 Mar 2012 12:43:57 +0530 Subject: Concern about gTLD servers in India In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> Message-ID: Hello Randy No idea about Africa but certainly none of gTLD servers in India. On Sat, Mar 10, 2012 at 12:42 PM, Randy Bush wrote: > > This problem is unfortunately not unique to India. There appear to be no > > anycast instances of the gTLD servers in Africa either. > > really!? > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From geier at geier.ne.tz Sat Mar 10 01:22:21 2012 From: geier at geier.ne.tz (Frank Habicht) Date: Sat, 10 Mar 2012 10:22:21 +0300 Subject: Concern about gTLD servers in India In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> Message-ID: <4F5B012D.9080703@geier.ne.tz> On 3/10/2012 10:12 AM, Randy Bush wrote: >> This problem is unfortunately not unique to India. There appear to be no >> anycast instances of the gTLD servers in Africa either. > > really!? There was one in KE but can't find or reach it: [a-m].gtld-servers.net. seem all to be in 192.0.0.0/8 route-views.kixp.routeviews.org> sh ip bgp 192.0.0.0/8 lo route-views.kixp.routeviews.org> Likely there is still (?) in EG ...? Frank From graham at apolix.co.za Sat Mar 10 01:22:40 2012 From: graham at apolix.co.za (Graham Beneke) Date: Sat, 10 Mar 2012 09:22:40 +0200 Subject: Concern about gTLD servers in India In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> Message-ID: <4F5B0140.8010300@apolix.co.za> On 10/03/2012 09:12, Randy Bush wrote: >> This problem is unfortunately not unique to India. There appear to be no >> anycast instances of the gTLD servers in Africa either. > > really!? Yes. I was also a little surprised. I'm sure that I read somewhere that at least one of the gTLD anycast prefixes was available at JINX (although I've never actually confirmed that). I've gone through every permutation of mtr [-4|-6] [a-m].gtld-servers.net. again just to be sure. I'm reaching nothing on this continent. -- Graham Beneke From me at anuragbhatia.com Sat Mar 10 01:28:48 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 10 Mar 2012 12:58:48 +0530 Subject: Concern about gTLD servers in India In-Reply-To: <4F5B0140.8010300@apolix.co.za> References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> Message-ID: I am sure few of people here have experience of running root servers. Can someone share if there's huge difference in . root servers Vs gTLD servers? I understand that root only hold all TLD's - cc and gTLD delegation that would be few hundred TLDs delegation while gTLDs hold lot of domain names but if one country has root, what prevents having gTLD also? Certainly bit more hardware, storage and processing power but such facilities are available mostly say in India & South Africa which have significant number of big telcos. On Sat, Mar 10, 2012 at 12:52 PM, Graham Beneke wrote: > On 10/03/2012 09:12, Randy Bush wrote: > >> This problem is unfortunately not unique to India. There appear to be no >>> anycast instances of the gTLD servers in Africa either. >>> >> >> really!? >> > > Yes. I was also a little surprised. > > I'm sure that I read somewhere that at least one of the gTLD anycast > prefixes was available at JINX (although I've never actually confirmed > that). > > I've gone through every permutation of > > mtr [-4|-6] [a-m].gtld-servers.net. > > again just to be sure. I'm reaching nothing on this continent. > > -- > Graham Beneke > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From randy at psg.com Sat Mar 10 01:30:07 2012 From: randy at psg.com (Randy Bush) Date: Sat, 10 Mar 2012 16:30:07 +0900 Subject: Concern about gTLD servers in India In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> Message-ID: > No idea about Africa then on what basis did you make the assertion? > but certainly none of gTLD servers in India. i am slightly suspicious of this. often, root servers are accompanied by gtld servers, and there are more than zero root servers in india. there is a fashion among root and gtld servers to attempt to limit the scope of their ancast routing announcements. this makes them hard to find from a (topologic) distance. randy From me at anuragbhatia.com Sat Mar 10 01:45:32 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 10 Mar 2012 13:15:32 +0530 Subject: Concern about gTLD servers in India In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> Message-ID: Please don't create confusions. I didn't made any assertion. I mentioned issue with India, but Graham came with point that issue is similar in Africa. Good point if he knows that. Certainly relevent to issue I mentioned for India. Again - I have not verified this. I don't know much about ISPs in Africa to find their looking glasses and test routing. On Sat, Mar 10, 2012 at 1:00 PM, Randy Bush wrote: > > No idea about Africa > > then on what basis did you make the assertion? > > > but certainly none of gTLD servers in India. > > i am slightly suspicious of this. often, root servers are accompanied > by gtld servers, and there are more than zero root servers in india. > > there is a fashion among root and gtld servers to attempt to limit the > scope of their ancast routing announcements. this makes them hard to > find from a (topologic) distance. > > randy > Ok, here's some data I collected couple of months back. I did consistant lookup for days to be sure that it's not temporary routing glitch giving such results. Traceroute to gTLDs from BSNL AS9829 - http://cdn.anuragbhatia.com/uploads/2012/03/gtld-traceroute-bsnl-as9829.txt Traceroute to gTLDs from Bharti Airtel AS9498 - http://cdn.anuragbhatia.com/uploads/2012/03/gtld-traceroute-airtel-as9498.txt Traceroutes to rDNS in-addr.arpa servers from BSNL - http://cdn.anuragbhatia.com/uploads/2012/03/rdns-bsnl-as9829.txt Traceroutes to rDNS in-addr.arpa servers from Airtel - http://cdn.anuragbhatia.com/uploads/2012/03/rdns-airtel-as9498.txt Thanks for your time & comments. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From slz at baycix.de Sat Mar 10 03:41:04 2012 From: slz at baycix.de (Sascha Lenz) Date: Sat, 10 Mar 2012 10:41:04 +0100 Subject: filtering /48 is going to be necessary In-Reply-To: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> Message-ID: <59AD1BEC-D2C5-43A2-9F96-18BC584B30EB@baycix.de> Hi all, > Hi, > >> What should happen is this "quasi-legitimate" method of >> multi-homing should just be declared illegitimate for IPv6, to >> facilitate stricter filtering. Instead, what should happen is the >> multi-homing should be required to fit into one of 3 scenarios, so >> any announcement with an IPv6 prefix length other than the >> RIR-allocated/assigned PA or PI block size can be treated as TE and >> summarily discarded or prioritizes when table resources are scarce. > > Splitting the allocation can be done for many reasons. There are known cases where one LIR operates multiple separate networks, each with a separate routing policy. They cannot get multiple allocations from the RIR and they cannot announce the whole allocation as a whole because of the separate routing policies (who are sometimes required legally, for example when an NREN has both a commercial and an educational network). Deaggregating to /48's is not a good idea, but giving an LIR a few bits (something like 3 or 4) to deaggregate makes sense. yes, that's my point for years now - probably filter /48s from allocations (because end-users CAN get IPv6 PI assignments now everywhere i think), but do allow some "sub-allocations" in the DFZ for such mentioned reasons. Because for the latter there are no real "nice" solutions atm. (or probably update the policies to be able to acquire multiples allocations without hassle in such cases, but OTOH it doesn't matter to the routing table, another prefix is another prefix) It's much nicer to have, say, one /40 in the table aggregating some (routing-)separated /48 customers than to have 200 /48 PI prefixes in that AS if each customer needs to get their own PI space if you cannot split the allocation. I thought that would be a good middle ground (combined with RIR RR based filters perhaps of course). ...but it seems like you even need to accept /48 from everywhere nowadays based on the initial postings *sigh* Not even I do like that, although i never was a big fan of strict filtering. But it all comes down to this most likely, the internet is a distributed being, and RIRs don't control routing. So /48 just will become the new /24 and some people will give us the good old "told you so!". -- Mit freundlichen Gr??en / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From andy at nosignal.org Sat Mar 10 03:42:10 2012 From: andy at nosignal.org (Andy Davidson) Date: Sat, 10 Mar 2012 09:42:10 +0000 Subject: BGP MD5 at IXP In-Reply-To: References: Message-ID: <4EDF1A71-7DBA-4097-BEDF-6EBB1C43089E@nosignal.org> On 9 Mar 2012, at 22:24, Jay Hanke wrote: > How critical is BGP MD5 at Internet Exchange Points? Would lack of > support for MD5 authentication on route servers prevent some peers > from multilaterally connecting? Do most exchange operators support it? At LONAP in London, the route-servers do not support TCP MD5 authentication for BGP. i don't think that this policy has led to anyone refusing to connect (about 80 of the 110 or so peers connected to the exchange use the Multilateral service - it is optional to connect to the MLP). We have no plans to enable TCP MD5 on this service. Because TCP MD5 packets touch a router's CPU, using MD5 introduces a new attack vector - see nanogii passim (e.g. http://www.nanog.org/meetings/nanog39/presentations/Scholl.pdf). Don't do it. :-) Andy From regnauld at nsrc.org Sat Mar 10 04:23:57 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Sat, 10 Mar 2012 11:23:57 +0100 Subject: Questions about anycasting setup In-Reply-To: <2763367C-26BA-4330-812E-C5898E154D14@gibbard.org> References: <20120309081131.GC17726@h.detebe.org> <4F59C701.3090503@altadena.net> <2763367C-26BA-4330-812E-C5898E154D14@gibbard.org> Message-ID: <20120310102357.GX33587@macbook.bluepipe.net> Steve Gibbard (scg) writes: > I have no idea what Cisco equipment Elmar is using, but I wouldn't jump to the conclusion that it can't withdraw routes when needed. Wouldn't the dns bit of ip sla do most of what's needed on IOS ? http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsdns.html some interesting examples at www.cisco.com/web/CA/events/pdfs/CNSF2011-Automations_for_Monitoring_and_Troubleshooting_your_Cisco_IOS_Network-Dan_Jerome.pdf (slide 29 and onwards) Note: this is more of a question than an assertion, I've used quagga/ospfd for DNS anycasting within ISPs, and a script to monitor the nameserver response, but I'd love to hear what people are doing that's not host based. From owen at delong.com Sat Mar 10 05:06:07 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 10 Mar 2012 03:06:07 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D0C920@RWC-MBX1.corp.seven.com> References: <4F5A6D25.6070907@birkenwald.de> <053DCC31-AE1D-417B-8A54-05E36923C759@delong.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C786@RWC-MBX1.corp.seven.com> <4A0A5B49-3E64-458C-B745-9A873A6A2DAA@delong.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C920@RWC-MBX1.corp.seven.com> Message-ID: <10B3F5C2-6613-40CD-8EEC-172DB7624DFF@delong.com> On Mar 9, 2012, at 11:01 PM, George Bonser wrote: >> I haven't heard anyone advocate accepting less than a /48. I think /48 >> is a reasonable "You must be this tall to ride" barrier. >> >> Beyond that, YMMV. >> >> Owen > > Apparently AS6939 has at various times :) I remember getting some /64 announcements from HE. I haven't seen one lately, though. I'm only filtering one /64 route these days announced by AS4651 > Like any other ISP, we're run by humans and humans occasionally make mistakes. If you saw anything longer than a /64 from 6939, it was the result of such an event. If you see anything longer than a /64 from 6939, please let us know and we will fix it. We have never advocated accepting longer than /48s to my knowledge. Owen From rs at seastrom.com Sat Mar 10 05:24:35 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 10 Mar 2012 06:24:35 -0500 Subject: BGP MD5 at IXP In-Reply-To: <4EDF1A71-7DBA-4097-BEDF-6EBB1C43089E@nosignal.org> (Andy Davidson's message of "Sat, 10 Mar 2012 09:42:10 +0000") References: <4EDF1A71-7DBA-4097-BEDF-6EBB1C43089E@nosignal.org> Message-ID: <86lin87l70.fsf@seastrom.com> Andy Davidson writes: > Because TCP MD5 packets touch a router's CPU, using MD5 introduces a > new attack vector - see nanogii passim > (e.g. http://www.nanog.org/meetings/nanog39/presentations/Scholl.pdf). > Don't do it. :-) Tom's slide deck is often misinterpreted - the salient parts are on pages 13 and 16. The big problem is that random packets can hit the control plane - AT ALL. One can kill it just as easily with a synflood on some other tcp port (perhaps ssh or even one that it isn't listening on?). Hopefully your modern exchange point router has some sort of control plane policing. Indeed, hopefully your backbone routers have some sort of control plane policing mechanism and you have turned it on and subjected your policy to some scrutiny. Blowing up un-password-protected BGP sessions by spoofing has not turned out to be a big problem in recent years. It probably helps that the dangers of highly predictable ISNs have become well-known (and hopefully acted upon by router vendors but history has shown that making blanket statements about that sort of thing on NANOG is unwise). A read of http://tools.ietf.org/html/rfc6528 may prove instructional. Turning on or off md5 makes minimal difference in CPU loading either during an attack or not, but it is another thing to get wrong - operational complexity without significant reward. I agree with Andy's conclusion. Don't do it unless whoever you're peering with demands it. It's not worth the complexity to set it up in the first place, and it's not worth your time to argue against it if someone is quite convinced that enabling md5 on your bgp session will save the world. -r From rs at seastrom.com Sat Mar 10 06:02:42 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 10 Mar 2012 07:02:42 -0500 Subject: Concern about gTLD servers in India In-Reply-To: (Anurag Bhatia's message of "Sat, 10 Mar 2012 12:58:48 +0530") References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> Message-ID: <86haxw7jfh.fsf@seastrom.com> Anurag Bhatia writes: > Can someone share if there's huge difference in . root servers Vs gTLD > servers? I understand that root only hold all TLD's - cc and gTLD > delegation that would be few hundred TLDs delegation while gTLDs hold lot > of domain names but if one country has root, what prevents having gTLD > also? Certainly bit more hardware, storage and processing power but such > facilities are available mostly say in India & South Africa which have > significant number of big telcos. There's a huge difference in operational complexity (and capex) between running root nameservers and gtld nameservers (to further confuse things, there are four gtlds, only two of which are run gtld-servers.net infrastructure, which means that Verisign is the operator). Root zone = a few thousand records with changes gated by people with a high degree of DNS clue, that come at a slow pace (once or twice a day typically). The roots eat a fair amount of bogus traffic (mitigated somewhat by things like the as112 project) due to poorly configured libraries and people's mistyping. It is trivial to run a shadow root locally by just secondarying "." on your cacheing nameservers. In fact, recent versions of FreeBSD have had a config like this to replace the named.root hints file - you just have to comment out the hints section and uncomment the secondary section in /etc/namedb/named.conf. You can do this on something as small as a wall-wart firewall device assuming it's running something like BIND. Obviously something that is exposed to the Internet as an anycast node will be built on much more capable hardware. A typical gtld zone will have anywhere from a few million to high tens of millions of records in it. Everyone and his brother has a vanity domain and together the update load and expectations of the customers are that changes will be committed instantaneously and visible across all nameservers for the gTLD within a few minutes at the outside. This update rate is a huge pain in operational practice and the sheer number of records eats a pretty decent sized memory footprint too. To answer your question, to get TLD anycast stacks in any given location, there will need to be a discussion with the TLD operator; in the case of the GTLDs that would be Verisign (.com and .net) and Afilias (.org and .info). In the case of sTLDs, GeoTLDs, and CCTLDs, the cast of actors expands considerably. No such thing a a one-stop shop. There is also an issue of cost/benefit. In the current economic climate assuming that organizations have unlimited resources to commit to the public good (regardles of how noble their intentions might be) is probably unwise. Does this help? -r (no longer an employee of a TLD op) From rdobbins at arbor.net Sat Mar 10 06:54:12 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 10 Mar 2012 12:54:12 +0000 Subject: Concern about gTLD servers in India In-Reply-To: <86haxw7jfh.fsf@seastrom.com> References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> <86haxw7jfh.fsf@seastrom.com> Message-ID: <95F7DF59-052D-43BA-869F-289DF915C62E@arbor.net> On Mar 10, 2012, at 7:02 PM, Robert E. Seastrom wrote: > there are four gtlds Aren't there actually seven? ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From graham at apolix.co.za Sat Mar 10 07:14:58 2012 From: graham at apolix.co.za (Graham Beneke) Date: Sat, 10 Mar 2012 15:14:58 +0200 Subject: Concern about gTLD servers in India In-Reply-To: <95F7DF59-052D-43BA-869F-289DF915C62E@arbor.net> References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> <86haxw7jfh.fsf@seastrom.com> <95F7DF59-052D-43BA-869F-289DF915C62E@arbor.net> Message-ID: <4F5B53D2.6030201@apolix.co.za> On 10/03/2012 14:54, Dobbins, Roland wrote: > > On Mar 10, 2012, at 7:02 PM, Robert E. Seastrom wrote: > >> there are four gtlds > > Aren't there actually seven? According to ICANN[1] there are "roughly two dozen gTLDs" [1] http://newgtlds.icann.org/en/about -- Graham Beneke From johnl at iecc.com Sat Mar 10 07:24:38 2012 From: johnl at iecc.com (John Levine) Date: 10 Mar 2012 13:24:38 -0000 Subject: Concern about gTLD servers in India In-Reply-To: <95F7DF59-052D-43BA-869F-289DF915C62E@arbor.net> Message-ID: <20120310132438.46440.qmail@joyce.lan> In article <95F7DF59-052D-43BA-869F-289DF915C62E at arbor.net> you write: > >On Mar 10, 2012, at 7:02 PM, Robert E. Seastrom wrote: > >> there are four gtlds > >Aren't there actually seven? Including the new IDN TLDs, there are now 60. R's, John aero. 172800 IN NS a0.aero.afilias-nst.info. asia. 172800 IN NS a0.asia.afilias-nst.info. biz. 172800 IN NS a.gtld.biz. cat. 172800 IN NS b.nic.ch. com. 172800 IN NS a.gtld-servers.net. coop. 172800 IN NS coop1.dyntld.net. info. 172800 IN NS a0.info.afilias-nst.info. int. 172800 IN NS ns.uu.net. jobs. 172800 IN NS a5.nstld.com. mobi. 172800 IN NS a0.mobi.afilias-nst.info. museum. 172800 IN NS ns.icann.org. name. 172800 IN NS a6.nstld.com. net. 172800 IN NS a.gtld-servers.net. org. 172800 IN NS a0.org.afilias-nst.info. pro. 172800 IN NS a.gtld.pro. tel. 172800 IN NS a.dns.nic.tel. travel. 172800 IN NS a.gtld.travel. xn--0zwm56d. 172800 IN NS a.iana-servers.net. xn--11b5bs3a9aj6g. 172800 IN NS a.iana-servers.net. xn--3e0b707e. 172800 IN NS b.dns.kr. xn--45brj9c. 172800 IN NS a0.cctld.afilias-nst.info. xn--80akhbyknj4f. 172800 IN NS a.iana-servers.net. xn--80ao21a. 172800 IN NS kz.cctld.authdns.ripe.net. xn--90a3ac. 172800 IN NS a.nic.rs. xn--9t4b11yi5a. 172800 IN NS a.iana-servers.net. xn--clchc0ea0b2g2a9gcd. 172800 IN NS ns2.cuhk.edu.hk. xn--deba0ad. 172800 IN NS a.iana-servers.net. xn--fiqs8s. 172800 IN NS h.dns.cn. xn--fiqz9s. 172800 IN NS h.dns.cn. xn--fpcrj9c3d. 172800 IN NS a0.cctld.afilias-nst.info. xn--fzc2c9e2c. 172800 IN NS lk.communitydns.net. xn--g6w251d. 172800 IN NS a.iana-servers.net. xn--gecrj9c. 172800 IN NS a0.cctld.afilias-nst.info. xn--h2brj9c. 172800 IN NS a0.cctld.afilias-nst.info. xn--hgbk6aj7f53bba. 172800 IN NS a.iana-servers.net. xn--hlcj6aya9esc7a. 172800 IN NS a.iana-servers.net. xn--j6w193g. 172800 IN NS b.dns.tw. xn--jxalpdlp. 172800 IN NS a.iana-servers.net. xn--kgbechtv. 172800 IN NS a.iana-servers.net. xn--kprw13d. 172800 IN NS d.dns.tw. xn--kpry57d. 172800 IN NS d.dns.tw. xn--lgbbat1ad8j. 172800 IN NS idn1.nic.dz. xn--mgbaam7a8h. 172800 IN NS ns1.aedns.ae. xn--mgbayh7gpa. 172800 IN NS jo.cctld.authdns.ripe.net. xn--mgbbh1a71e. 172800 IN NS a0.cctld.afilias-nst.info. xn--mgbc0a9azcg. 172800 IN NS ns2.nic.fr. xn--mgberp4a5d4ar. 172800 IN NS ns1.isu.net.sa. xn--o3cw4h. 172800 IN NS ns.thnic.net. xn--ogbpf8fl. 172800 IN NS sy.cctld.authdns.ripe.net. xn--p1ai. 172800 IN NS d.dns.ripn.net. xn--pgbs0dh. 172800 IN NS ns2.nic.fr. xn--s9brj9c. 172800 IN NS a0.cctld.afilias-nst.info. xn--wgbh1c. 172800 IN NS ns1.dotmasr.eg. xn--wgbl6a. 172800 IN NS qa.cctld.authdns.ripe.net. xn--xkc2al3hye2a. 172800 IN NS lk.communitydns.net. xn--xkc2dl3a5ee0h. 172800 IN NS a0.cctld.afilias-nst.info. xn--yfro4i67o. 172800 IN NS ns2.cuhk.edu.hk. xn--ygbi2ammx. 172800 IN NS idn.pnina.ps. xn--zckzah. 172800 IN NS a.iana-servers.net. xxx. 172800 IN NS a0.xxx.afilias-nst.info. From seth.mos at dds.nl Sat Mar 10 07:32:24 2012 From: seth.mos at dds.nl (Seth Mos) Date: Sat, 10 Mar 2012 14:32:24 +0100 Subject: AT&T home DSL IPv6 configuration? In-Reply-To: <20120310024004.GA32680@hiwaay.net> References: <20120310024004.GA32680@hiwaay.net> Message-ID: Op 10 mrt 2012, om 03:40 heeft Chris Adams het volgende geschreven: > > Can anybody tell me how they are configuring their IPv6 setup? They deploy using 6rd. In other words, they get to deploy IPv6 _again_ in about a few years time. Basically any router with 6rd support and the knobs in the ui to input their 6rd border relay and you should be good. It's nice that you can use their border relay from outside the US too. Regards, Seth From mysidia at gmail.com Sat Mar 10 08:08:15 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 10 Mar 2012 08:08:15 -0600 Subject: filtering /48 is going to be necessary In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> Message-ID: On Sat, Mar 10, 2012 at 12:52 AM, George Bonser wrote: >> I'm well into my second decade of having a v6 prefix in the dfz and am >> passingly familiar with powers of two... > Point is that expecting people globally to take a /48 from PA space probably isn't a realistic expectation. Exactly.... What's more realistic is you have to get a single /48 of PI space for people to carry that globally. And if you have 5 discontiguous networks, what the RIRs should do is carve a /44 out for your present and future PI allocations and issue you the 8 /48s; the PI /48 routing slots that you have justified need for -- arranged so that they fall within the same /45. -- -JH From kyle.creyts at gmail.com Sat Mar 10 08:48:02 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Sat, 10 Mar 2012 09:48:02 -0500 Subject: AS Connectivity Lookup In-Reply-To: References: Message-ID: bgptables.merit.edu On Mar 7, 2012 2:06 PM, "Radke, Justin" wrote: > All great answers! Thank you! > > -=JGR > > On Wed, Mar 7, 2012 at 10:35 AM, David Walker >wrote: > > > On 08/03/2012, Anurag Bhatia wrote: > > > Hi Radke > > > > > > You can try http://bgp.he.net > > > > Example: > > http://bgp.he.net/AS4739 > > > > Guest login here: > > http://peeringdb.com/ > > > > > > > > On Wed, Mar 7, 2012 at 10:59 PM, Radke, Justin > > wrote: > > > > > >> How can I easily view the current peering relationship of a particular > > AS? > > >> Assume the AS you are researching does not have a looking glass and > you > > >> are > > >> not going to do lookups from the top 10 providers route servers to get > > >> some > > >> glimpse of their connectivity. In my particular search > > >> bgplay.routeviews.org does > > >> not have any information and as-rank.caida.org is out of date. In the > > past > > >> there was a great website called webtrace.info but it is no longer > > online. > > >> > > >> Any suggestions? > > >> > > > > > > > > > > > > -- > > > > > > Anurag Bhatia > > > anuragbhatia.com > > > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > > > network! > > > > > > Twitter: @anurag_bhatia > > > Linkedin: http://linkedin.anuragbhatia.com > > > > > > From brunner at nic-naa.net Sat Mar 10 09:42:21 2012 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 10 Mar 2012 10:42:21 -0500 Subject: Concern about gTLD servers in India In-Reply-To: <20120310132438.46440.qmail@joyce.lan> References: <20120310132438.46440.qmail@joyce.lan> Message-ID: <4F5B765D.1050905@nic-naa.net> > In article <95F7DF59-052D-43BA-869F-289DF915C62E at arbor.net> you write: >> On Mar 10, 2012, at 7:02 PM, Robert E. Seastrom wrote: >> >>> there are four gtlds >> Aren't there actually seven? > Including the new IDN TLDs, there are now 60. well .... there are the legacy (pre-2000) set. there are the seven arising from the 7-10 proposal from WG-C*, aka the "2000 round**", of which three are "sponsored" (restrictions on registration policies) and four were "generic" (no such restrictions, price caps), all of which operate in some form or another at present. there are the set arising from the 2004 round***, all of which nominally are "sponsored", which now includes .xxx, but does not yet include .post (501(c)(3) (choice-of-contracting-or-memoing with a treaty organization problem), so about two dozen. there are the IDN (ascii encoded representations of unicode) delegations arising from the IDN ccTLD Fast-Track program, which share the no-or-significiantly-different-contract property of the delegations made for most iso3166 code points. to refer to these as "generic" is both reasonable, and misleading. the underlying issue is whether the operator has repurposed the original ASCII, or subsequent IDN delegations, as more similar to the CNOBI**** set of registries on a registration policy basis, making the delegation "generic", but without a CNOBI-like contract with ICANN, or not. examples of repurposed ccTLDs are nu, cc, me, us, ... the location of registries is quite distinct from the location of name server constellations, with the former being mono- or dual-sited, and operated by the delegee or single (there are exceptions) contractor, and the latter being multi-sited, and operated by multiple parties. a related issue, the subject of v6 evangelism, is the availability of redundant transit, which under the current ICANN DAG, appears to me to preclude registry siting in venues lacking redundant native v6 transit in Q12013, limiting data centers in Africa and South Asia. cheers, -e * member, WG-C. ** contributor to one or more successful 2000 registry inits. *** contributor to one or more successful 2004 registry inits. **** CNOBI == COM/NET/ORG/BIZ/INFO -- a single business model. From drc at virtualized.org Sat Mar 10 09:54:29 2012 From: drc at virtualized.org (David Conrad) Date: Sat, 10 Mar 2012 09:54:29 -0600 Subject: Concern about gTLD servers in India In-Reply-To: <20120310132438.46440.qmail@joyce.lan> References: <20120310132438.46440.qmail@joyce.lan> Message-ID: <876DBCE2-60E2-40D1-84BA-792C285A41B7@virtualized.org> On Mar 10, 2012, at 7:24 AM, John Levine wrote: > In article <95F7DF59-052D-43BA-869F-289DF915C62E at arbor.net> you write: >> >> On Mar 10, 2012, at 7:02 PM, Robert E. Seastrom wrote: >>> there are four gtlds >> Aren't there actually seven? > Including the new IDN TLDs, there are now 60. The IDN TLDs (to date, with the exception of the test IDN TLDs) are more properly considered ccTLDs as they are the localized version of country names. Also, one could make a distinction between sponsored TLDs and generic TLDs, but that's probably splitting hairs. Regards, -drc From drc at virtualized.org Sat Mar 10 10:00:44 2012 From: drc at virtualized.org (David Conrad) Date: Sat, 10 Mar 2012 10:00:44 -0600 Subject: [apnic-talk] Concern about gTLD servers in India In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> Message-ID: On Mar 10, 2012, at 1:28 AM, Anurag Bhatia wrote: > Can someone share if there's huge difference in . root servers Vs gTLD servers? Yes, there is a huge difference. For one thing (and ignoring the quantity of data), the operations of a gTLD's name servers is managed by a single entity (e.g., for .COM, VeriSign). The root servers are independently managed by 12 different organizations with no central management. > I understand that root only hold all TLD's - cc and gTLD delegation that would be few hundred TLDs delegation while gTLDs hold lot of domain names but if one country has root, what prevents having gTLD also? I'd imagine business/economic rationales. From the perspective of a gTLD operator, what's the business justification for deploying non-trivial opex/capex? Root server deployments are less driven by economics and are more political in nature. Regards, -drc From ops.lists at gmail.com Sat Mar 10 10:05:48 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 10 Mar 2012 21:35:48 +0530 Subject: Concern about gTLD servers in India In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> Message-ID: Sure, if you can find a datacenter that's capable of handling all the traffic, and has staff who are able to provide efficient remote hands for huge racks of extremely powerful servers .. and are possibly also open to cross subsidizing the costs that GTLD operators will incur to host instances of their servers in India .. etc etc. On Sat, Mar 10, 2012 at 1:15 PM, Anurag Bhatia wrote: > Please don't create confusions. > > I didn't made any assertion. I mentioned issue with India, but Graham came > with point that issue is similar in Africa. Good point if he knows that. > Certainly relevent to issue I mentioned for India. > -- Suresh Ramasubramanian (ops.lists at gmail.com) From johnl at iecc.com Sat Mar 10 11:01:18 2012 From: johnl at iecc.com (John R. Levine) Date: 10 Mar 2012 12:01:18 -0500 Subject: Concern about gTLD servers in India In-Reply-To: <876DBCE2-60E2-40D1-84BA-792C285A41B7@virtualized.org> References: <20120310132438.46440.qmail@joyce.lan> <876DBCE2-60E2-40D1-84BA-792C285A41B7@virtualized.org> Message-ID: > The IDN TLDs (to date, with the exception of the test IDN TLDs) are more properly considered ccTLDs as they are the localized version of country names. Good point. > Also, one could make a distinction between sponsored TLDs and generic TLDs, but that's probably splitting hairs. I suppose, but they all have similar registry and registrar agreements with ICANN, which is what makes them different from ccTLDs. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From joelja at bogus.com Sat Mar 10 12:00:36 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sat, 10 Mar 2012 10:00:36 -0800 Subject: Concern about gTLD servers in India In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> Message-ID: <4F5B96C4.9000206@bogus.com> On 3/10/12 08:05 , Suresh Ramasubramanian wrote: > Sure, if you can find a datacenter that's capable of handling all the > traffic, and has staff who are able to provide efficient remote hands for > huge racks of extremely powerful servers .. and are possibly also open to > cross subsidizing the costs that GTLD operators will incur to host > instances of their servers in India .. etc etc. DNS even at scale is not a particularly compute intensive service. That said whether it's worth it or not is in the eyes of operator. > On Sat, Mar 10, 2012 at 1:15 PM, Anurag Bhatia wrote: > >> Please don't create confusions. >> >> I didn't made any assertion. I mentioned issue with India, but Graham came >> with point that issue is similar in Africa. Good point if he knows that. >> Certainly relevent to issue I mentioned for India. >> > > > From woody at pch.net Sat Mar 10 12:34:10 2012 From: woody at pch.net (Bill Woodcock) Date: Sat, 10 Mar 2012 10:34:10 -0800 Subject: Concern about gTLD servers in India In-Reply-To: <4F5AFD28.9010103@apolix.co.za> References: <4F5AFD28.9010103@apolix.co.za> Message-ID: <44FF9176-4583-4881-A78B-7A33B34B0F65@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mar 9, 2012, at 11:05 PM, Graham Beneke wrote: > There appear to be no anycast instances of the gTLD servers in Africa either. That's not the case. .ORG, for example, is hosted in Cape Town and Cairo, and we host more than a hundred ccTLDs in those two locations as well as Maputo, Dar es Salaam, Johannesburg, and Nairobi. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPW56jAAoJEG+kcEsoi3+H3tsP+QFick6sCDyZUrfzMt80zNs6 GnPiH3bjqU/vTu9aGN/t+R2C01NjnOCOzVYkQE18EVsGA1jluEGaD6+gu05v83Cf qQby5W1EekwNuxdnP/avhmJwnz9+4Kgg6dNVePC6uwNmjKd85ppE5AErKq5RSj6X WjKoiN9ILV/P8SHtdFA8NcqaAC8AtTcB0JUUAw+rCBNsmRZv2S6zbQ+wnuExWaU9 gEeAYAOEsufb+xNydKPhCFsjwCKH5cCuG8VO8QYR50XvpErvFiemlEHcCqSi+3o3 v1jlL8tSQWp/x9MVDZWvy6h6s8GxOoOJkN5n+i1YHCw5ofTHR4zW4OuY9QWkrbKA hxSzXUzw8m0btKn4MMrMpV8yZecBqn1dIbhiCYud26G71azyFX+PkLKTT5GtMUdN y2MVmdHwnDIantJbKWOeXltw//8xB0GdB5S09jcKCOhgrWaqYW1fsytcieRi0/AK txDvob8fXHt6Fi30X4SHD2Q1NylM2mySgOYgx3aT2G9ZEimZE7xR3JwVVzLRfmXn d7InkGZEj2ziZD4QM4UHWW35FcYkvmzYcVugcBBoooD8UGwAwTxpXG07K9U5hdCG oA0F3JQweGqXp+C2ECKBSOjL7vSnrHoX9jPNAmMRsN91EuKIWcY3ReYl3e36ZJPX NCcBAxuXkxhgBG1VsSO3 =Um6m -----END PGP SIGNATURE----- From me at anuragbhatia.com Sat Mar 10 12:35:56 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 11 Mar 2012 00:05:56 +0530 Subject: [apnic-talk] Concern about gTLD servers in India In-Reply-To: <44FF9176-4583-4881-A78B-7A33B34B0F65@pch.net> References: <4F5AFD28.9010103@apolix.co.za> <44FF9176-4583-4881-A78B-7A33B34B0F65@pch.net> Message-ID: Thanks for info Mr Bill. What about India? Do you see any gTLD instances in India? On Sun, Mar 11, 2012 at 12:04 AM, Bill Woodcock wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > On Mar 9, 2012, at 11:05 PM, Graham Beneke wrote: > > There appear to be no anycast instances of the gTLD servers in Africa > either. > > That's not the case. .ORG, for example, is hosted in Cape Town and Cairo, > and we host more than a hundred ccTLDs in those two locations as well as > Maputo, Dar es Salaam, Johannesburg, and Nairobi. > > -Bill > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJPW56jAAoJEG+kcEsoi3+H3tsP+QFick6sCDyZUrfzMt80zNs6 > GnPiH3bjqU/vTu9aGN/t+R2C01NjnOCOzVYkQE18EVsGA1jluEGaD6+gu05v83Cf > qQby5W1EekwNuxdnP/avhmJwnz9+4Kgg6dNVePC6uwNmjKd85ppE5AErKq5RSj6X > WjKoiN9ILV/P8SHtdFA8NcqaAC8AtTcB0JUUAw+rCBNsmRZv2S6zbQ+wnuExWaU9 > gEeAYAOEsufb+xNydKPhCFsjwCKH5cCuG8VO8QYR50XvpErvFiemlEHcCqSi+3o3 > v1jlL8tSQWp/x9MVDZWvy6h6s8GxOoOJkN5n+i1YHCw5ofTHR4zW4OuY9QWkrbKA > hxSzXUzw8m0btKn4MMrMpV8yZecBqn1dIbhiCYud26G71azyFX+PkLKTT5GtMUdN > y2MVmdHwnDIantJbKWOeXltw//8xB0GdB5S09jcKCOhgrWaqYW1fsytcieRi0/AK > txDvob8fXHt6Fi30X4SHD2Q1NylM2mySgOYgx3aT2G9ZEimZE7xR3JwVVzLRfmXn > d7InkGZEj2ziZD4QM4UHWW35FcYkvmzYcVugcBBoooD8UGwAwTxpXG07K9U5hdCG > oA0F3JQweGqXp+C2ECKBSOjL7vSnrHoX9jPNAmMRsN91EuKIWcY3ReYl3e36ZJPX > NCcBAxuXkxhgBG1VsSO3 > =Um6m > -----END PGP SIGNATURE----- > > _______________________________________________ > apnic-talk mailing list > apnic-talk at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-talk > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From woody at pch.net Sat Mar 10 12:45:00 2012 From: woody at pch.net (Bill Woodcock) Date: Sat, 10 Mar 2012 10:45:00 -0800 Subject: Concern about gTLD servers in India In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> Message-ID: <79350CD0-0BFE-4590-9856-B85C34F89241@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mar 10, 2012, at 8:05 AM, Suresh Ramasubramanian wrote: > Sure, if you can find a datacenter that's capable of handling all the > traffic, and has staff who are able to provide efficient remote hands for > huge racks of extremely powerful servers . Honestly, we haven't even gotten that far when we've offered to deploy servers (for instance for domains like .IN) inside India. The bribes that were requested in exchange for giving us permission to deploy a free service were, uh, both prohibitive and ludicrous in their enormity. There are a lot of countries that have far less wealth than India, that manage to stand up more interesting infrastructure, because they have less friction caused by corruption. India: USD 3,703 GDP per capita (source: IMF) Bangladesh: USD 1,697 Tanzania: USD 1,505 Nepal: USD 1,328 -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPW6EsAAoJEG+kcEsoi3+HySgQAJ/td8kXhyxzMJ18J0Xrxpvj 36d6VJqfajgkeSJ9SFiWwam+Us7XBRnwKgz9ntX3wmavA0H4QTuWQyTl9T60Fac+ hvqu3VzV7U2dNh74WVRGmpRZrfY+4Of1fpxV2CG3y+xDAHa6wTbZ7AVey+L6xLoK dKp3oMyMxr9yX596BEI4xWmQnt7SpQA3hcoYTUgTHXTxSh0xdwd7ovD31J8vXg0C wVgTHZ2ibka99LPh3Oo2gNSHm6gqRTHeu8ZmiEpFZwbpMTk0y8XTnvbAHOjnlQcP oV/44591ybYkVhXlBs2f7Yuh7EtxF83g1cjq8QeNdb++7XJxrVEb3rTuFEmedIWx +51P0Sta39CbskG70mFehUjjvAFLsnX6U3epBJtDxcj0NT+jB6BMZM7MFPqeFESj GZ4qj7mCbOWcPoSnq+o4IEH92fk60nhVv7uOi/C3jnJXuJeT2/F6VrEueYK3EGKI PVn099CjvFpjF5u/hauayv+jqd7QBzilphR5swKERLZc4ftinHFJIsjllzK6bztv cFvubRZAsPyznRzk9HDL6zxd7E9zHuBgZnFmRlD6LxR5tTgVRrvtW5UhwvQcqXNe ceYIVcoc44uXdiDIgEaz/Hx9aLkZb+jXZh1+Dcvwb3xqCi5rvSpWsb0I7tfRYKGF G1/WRLex2Z093zxCl6po =O3IR -----END PGP SIGNATURE----- From ops.lists at gmail.com Sat Mar 10 12:52:33 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 11 Mar 2012 00:22:33 +0530 Subject: Concern about gTLD servers in India In-Reply-To: <4F5B96C4.9000206@bogus.com> References: <4F5AFD28.9010103@apolix.co.za> <4F5B96C4.9000206@bogus.com> Message-ID: Yes of course, if you don't count the multi gbps DDoS attacks and such .. On Sat, Mar 10, 2012 at 11:30 PM, Joel jaeggli wrote: > > DNS even at scale is not a particularly compute intensive service. > > That said whether it's worth it or not is in the eyes of operator. -- Suresh Ramasubramanian (ops.lists at gmail.com) From brunner at nic-naa.net Sat Mar 10 13:58:05 2012 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 10 Mar 2012 14:58:05 -0500 Subject: Concern about gTLD servers in India In-Reply-To: References: <20120310132438.46440.qmail@joyce.lan> <876DBCE2-60E2-40D1-84BA-792C285A41B7@virtualized.org> Message-ID: <4F5BB24D.1090204@nic-naa.net> >> Also, one could make a distinction between sponsored TLDs and >> generic TLDs, but that's probably splitting hairs. > > I suppose, but they all have similar registry and registrar agreements > with ICANN, which is what makes them different from ccTLDs. at present there are almost as many substantively distinct contracts as there are post-legacy, non-country-code (ASCII and IDN) registries. there are similarities, but there are also distinct differences in registration policy, price caps, and cross ownership. imo, the hair to split is the business models of the operators: there is one business model characterized by $6 FCFS as modified by the UDRP. this business model is common to the VGRS properties, the Afilias and the NeuStar properties. there is another business model characterized by greater restrictions on registrations. this business model is common to the CORE properties and the NCUA property. ppc density in the string space about {google, microsoft, walmart, ibm, vodafone, bank of america, general electric, apple, wells fargo, at&t}* common marks in a namespace is one distinguishing characteristic. another hair to split is the operational practice of ccTLD registries. many lack "nexus" requirements, and share the ppc density of the $6/FCFS/UDRP business model, and quite a few have few registrations other than foreign jurisdiction trademarks. -e * forbes top ten list of 6/15/11. From jof at thejof.com Sat Mar 10 14:23:20 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Sat, 10 Mar 2012 12:23:20 -0800 Subject: Concern about gTLD servers in India In-Reply-To: <79350CD0-0BFE-4590-9856-B85C34F89241@pch.net> References: <4F5AFD28.9010103@apolix.co.za> <79350CD0-0BFE-4590-9856-B85C34F89241@pch.net> Message-ID: On Sat, Mar 10, 2012 at 10:45 AM, Bill Woodcock wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > On Mar 10, 2012, at 8:05 AM, Suresh Ramasubramanian wrote: >> Sure, if you can find a datacenter that's capable of handling all the >> traffic, and has staff who are able to provide efficient remote hands for >> huge racks of extremely powerful servers . > > Honestly, we haven't even gotten that far when we've offered to deploy servers (for instance for domains like .IN) inside India. ?The bribes that were requested in exchange for giving us permission to deploy a free service were, uh, both prohibitive and ludicrous in their enormity. This. This and the import duties on hardware and the requirement for licensing to operate as an "ISP" makes placing even a modest deployment a lot more work compared to deploying in other neighboring countries. I would presume that Verisign decided that it just wasn't worth the effort to deploy into India. It obviously has a gigantic user base for which getting into local ISPs and IXPs would probably save on transit costs. Perhaps if some local root operators could donate some space/power/connectivity, Verisign-grs could colocate a gTLD cluster there? Cheers, jof From brunner at nic-naa.net Sat Mar 10 16:05:50 2012 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 10 Mar 2012 17:05:50 -0500 Subject: Concern about gTLD servers in India In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> <79350CD0-0BFE-4590-9856-B85C34F89241@pch.net> Message-ID: <4F5BD03E.6020004@nic-naa.net> On 3/10/12 3:23 PM, Jonathan Lassoff wrote: > I would presume that Verisign decided that it just wasn't worth the > effort to deploy into India. operational control of .in passed to a for-profit operator domiciled in one_of{us,ca,ie} other than VGRS. as india is a competitor's property, investment there by VGRS mby be difficult to justify. -e From sven at cb3rob.net Sat Mar 10 16:47:21 2012 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Sat, 10 Mar 2012 22:47:21 +0000 (UTC) Subject: filtering /48 is going to be necessary In-Reply-To: References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> Message-ID: well... we actually intend to just announce /64's and smaller as well. i don't see the problem with that. just get routers with enough memory... i'm rather for a "specification" of a minimum supported route-size (let's say something along the lines of 64GB in each border router, it's 2012 after all ;) than for putting limits on the prefix sized announced so "old junk" can still stay connected to the internet. let's say, there is 6 billion people in the world.. if they all have 1 route table entry (average ;) i see no technical limitations on anything produced AFTER 2008 actually. stop buying crap without sufficient ram, or just scrap it and get new stuff. (which you're going to have to do to efficiently route ipv6 -anyway- at some point, as your old stuff, simply doesn't even loadbalance trunked ethernet ports properly (layer 3 based) ;) we can't limit the expansion of the internet, and the independance of it's users, just because some people refuse to part from their cisco 7200 vxr. On Sat, 10 Mar 2012, Jimmy Hess wrote: > On Sat, Mar 10, 2012 at 12:52 AM, George Bonser wrote: >>> I'm well into my second decade of having a v6 prefix in the dfz and am >>> passingly familiar with powers of two... >> Point is that expecting people globally to take a /48 from PA space probably isn't a realistic expectation. > > Exactly.... > What's more realistic is you have to get a single /48 of PI space for > people to carry that globally. > > And if you have 5 discontiguous networks, what the RIRs should do is > carve a /44 out for your > present and future PI allocations and issue you the 8 /48s; > the PI /48 routing slots > that you have justified need for -- arranged so that they fall within > the same /45. > > > -- > -JH > From sven at cb3rob.net Sat Mar 10 16:50:35 2012 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Sat, 10 Mar 2012 22:50:35 +0000 (UTC) Subject: filtering /48 is going to be necessary In-Reply-To: References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> Message-ID: we also should have expanded the ASN to minimum 64 bits at the time it was expanded to 32 bit for exactly the same reason btw. there -are- some technical reasons why /64's would be practical as "end-site" stuff, and if we want to be able to make all those end site networks independant, we'd need 64 bit asn's to go along with that. but main thing: just get enough ram in your stuff, and stop imposing stupid limitations. (not my problem if your routers keep reloading the table or rebooting themselves because they're from 1993 ffs ;) you did buy a new iphone i bet.. why no modern routers. On Sat, 10 Mar 2012, Jimmy Hess wrote: > On Sat, Mar 10, 2012 at 12:52 AM, George Bonser wrote: >>> I'm well into my second decade of having a v6 prefix in the dfz and am >>> passingly familiar with powers of two... >> Point is that expecting people globally to take a /48 from PA space probably isn't a realistic expectation. > > Exactly.... > What's more realistic is you have to get a single /48 of PI space for > people to carry that globally. > > And if you have 5 discontiguous networks, what the RIRs should do is > carve a /44 out for your > present and future PI allocations and issue you the 8 /48s; > the PI /48 routing slots > that you have justified need for -- arranged so that they fall within > the same /45. > > > -- > -JH > From sven at cb3rob.net Sat Mar 10 16:56:14 2012 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Sat, 10 Mar 2012 22:56:14 +0000 (UTC) Subject: filtering /48 is going to be necessary In-Reply-To: References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> Message-ID: and anyway, the average visit to facebook is still more data than the entire ipv6 route table at the moment. we might also want to speed up bgp handling by routers a bit in the future, as some are DAMN SLOW in processing a few hundred thousand sets of data... (no people, it's NOT acceptable when a 200k box takes more than a few milliseconds to process whats basically just a few megabytes of data coming in over 10ge pipes and put it into a route table in ram ;) time to put all those suppliers a pepper in their **** and simply stop buying their stuff if they keep selling obsolete junk. end-to-end PI is the way to go. -- Greetings, Sven Olaf Kamphuis, CB3ROB LLTC. ========================================================================= Address: C/O German Embassy of the Republic CyberBunker Koloniestrasse 34 D-13359 Registration: #8 CBTR GERMANIA Phone: +31/(0)87-8747479 Das Gross Deutsche Reich RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net ========================================================================= http://www.facebook.com/cb3rob ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Sat, 10 Mar 2012, Jimmy Hess wrote: > On Sat, Mar 10, 2012 at 12:52 AM, George Bonser wrote: >>> I'm well into my second decade of having a v6 prefix in the dfz and am >>> passingly familiar with powers of two... >> Point is that expecting people globally to take a /48 from PA space probably isn't a realistic expectation. > > Exactly.... > What's more realistic is you have to get a single /48 of PI space for > people to carry that globally. > > And if you have 5 discontiguous networks, what the RIRs should do is > carve a /44 out for your > present and future PI allocations and issue you the 8 /48s; > the PI /48 routing slots > that you have justified need for -- arranged so that they fall within > the same /45. > > > -- > -JH > From bill at herrin.us Sat Mar 10 17:11:09 2012 From: bill at herrin.us (William Herrin) Date: Sat, 10 Mar 2012 18:11:09 -0500 Subject: filtering /48 is going to be necessary In-Reply-To: References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> Message-ID: On Sat, Mar 10, 2012 at 5:47 PM, Sven Olaf Kamphuis wrote: > just get routers with enough memory... > > i'm rather for a "specification" of a minimum supported route-size (let's > say something along the lines of 64GB in each border router, it's 2012 after > all ;) than for putting limits on the prefix sized announced so "old junk" > can still stay connected to the internet. > > let's say, there is 6 billion people in the world.. if they all have 1 route > table entry (average ;) i see no technical limitations on anything produced > AFTER 2008 actually. > > stop buying crap without sufficient ram, or just scrap it and get new stuff. > (which you're going to have to do to efficiently route ipv6 -anyway- at some > point, as your old stuff, simply doesn't even loadbalance trunked ethernet > ports properly (layer 3 based) ;) Sven, A) 7 billion people in the world, not 6. B) 7B IPv6 routes won't fit in a 64GB radix tree once, let alone the several times they'd need to in order to be useful in a router. For that matter, 6B routes won't fit either. (Hint: FIB plus at least one RIB for each peer) C) Big iron is either using massively parallel FIBs (many copies of the radix tree) or they're using TCAM instead of DRAM, a specialized tristate version of SRAM. In either case, you're talking 10 to 100 times the cost, ten times the power consumption and ten times the heat versus DRAM. D) No computer presently exists on which the BGP protocol could keep up with today's update rate per prefix with 7B prefixes. A router handling 10M routes is achievable today if we're willing to go back to $20k as the minimum cost BGP box. That's an order of magnitude more than we have now and three orders of magnitude short of where we need to be before we can stop sweating the prefix count. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dougb at dougbarton.us Sat Mar 10 17:13:51 2012 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 10 Mar 2012 15:13:51 -0800 Subject: root zone stats In-Reply-To: <86haxw7jfh.fsf@seastrom.com> References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> <86haxw7jfh.fsf@seastrom.com> Message-ID: <4F5BE02F.60901@dougbarton.us> Since there was a question about this, some numbers: Serial: 2012031001 Statistics ========== Number of root servers: 13 Roots with IPv6 glue: 9 Number of gTLDs: 22 Number of ccTLDs: 249 Number of IDN TLDs: 42 Total number of TLDs: 313 Number of IPv4 hosts: 1176 Number of IPv4 addresses: 1145 Number of IPv6 hosts: 427 Number of IPv6 addresses: 412 TLDs with IPv6 glue: 258 Total name server hosts: 1177 Total NS addresses: 1557 Number of DS records: 141 Number of TLDs with DS: 85 Enjoy, Doug -- If you're never wrong, you're not trying hard enough From sethm at rollernet.us Sat Mar 10 17:39:21 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 10 Mar 2012 15:39:21 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> Message-ID: <4F5BE629.1000808@rollernet.us> On 3/10/12 2:47 PM, Sven Olaf Kamphuis wrote: > well... we actually intend to just announce /64's and smaller as well. > > i don't see the problem with that. > > just get routers with enough memory... > > i'm rather for a "specification" of a minimum supported route-size > (let's say something along the lines of 64GB in each border router, it's > 2012 after all ;) than for putting limits on the prefix sized announced > so "old junk" can still stay connected to the internet. > > let's say, there is 6 billion people in the world.. if they all have 1 > route table entry (average ;) i see no technical limitations on anything > produced AFTER 2008 actually. > > stop buying crap without sufficient ram, or just scrap it and get new > stuff. (which you're going to have to do to efficiently route ipv6 > -anyway- at some point, as your old stuff, simply doesn't even > loadbalance trunked ethernet ports properly (layer 3 based) ;) > I'm under the impression from your messages in this thread that you're unaware or unfamiliar with TCAM. ~Seth From joelja at bogus.com Sat Mar 10 18:00:06 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sat, 10 Mar 2012 16:00:06 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> Message-ID: <4F5BEB06.3010805@bogus.com> On 3/10/12 14:47 , Sven Olaf Kamphuis wrote: > let's say, there is 6 billion people in the world.. if they all have 1 > route table entry (average ;) i see no technical limitations on anything > produced AFTER 2008 actually. Over in ipv4 land there are ~40k entities that appear in the dfz internet... Of those somewhat less than half (16k) announce just one prefix. The top 30 ASes by route count on the other hand are 10% of the table. I don't a see a problem with the small guys. I don't see the little guys as a source of fib scaling problem becuase oddly enough they aren't. The actors causing the most impact on the size of my fib are by in large on this mailing list... joel From owen at delong.com Sat Mar 10 18:38:18 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 10 Mar 2012 16:38:18 -0800 Subject: Concern about gTLD servers in India In-Reply-To: <4F5BD03E.6020004@nic-naa.net> References: <4F5AFD28.9010103@apolix.co.za> <79350CD0-0BFE-4590-9856-B85C34F89241@pch.net> <4F5BD03E.6020004@nic-naa.net> Message-ID: <5803165C-6981-43E3-9239-BF1F9D341720@delong.com> On Mar 10, 2012, at 2:05 PM, Eric Brunner-Williams wrote: > On 3/10/12 3:23 PM, Jonathan Lassoff wrote: >> I would presume that Verisign decided that it just wasn't worth the >> effort to deploy into India. > > operational control of .in passed to a for-profit operator domiciled > in one_of{us,ca,ie} other than VGRS. as india is a competitor's > property, investment there by VGRS mby be difficult to justify. > > -e The more telling fallacy here that really speaks to the heart of why I am dismayed and disappointed by ICANN's management of the whole TLD mess is the idea that a CCTLD is the property of a TLD operator to begin with. The .IN TLD is property of the Indian people or worst case, the government of India acting in their stead. (or at least it should be if ICANN and/or Verisign and their competitors haven't managed to completely usurp the public trust. Owen From owen at delong.com Sat Mar 10 18:42:37 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 10 Mar 2012 16:42:37 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> Message-ID: <19DFDC84-5F7C-49AD-A767-0DD4FAAFC98D@delong.com> On Mar 10, 2012, at 6:08 AM, Jimmy Hess wrote: > On Sat, Mar 10, 2012 at 12:52 AM, George Bonser wrote: >>> I'm well into my second decade of having a v6 prefix in the dfz and am >>> passingly familiar with powers of two... >> Point is that expecting people globally to take a /48 from PA space probably isn't a realistic expectation. > > Exactly.... > What's more realistic is you have to get a single /48 of PI space for > people to carry that globally. > I fail to understand what difference it makes to a router whether a /48 is from PA or PI. > And if you have 5 discontiguous networks, what the RIRs should do is > carve a /44 out for your > present and future PI allocations and issue you the 8 /48s; Well, they carve out a /44 and issue you the /44 in most cases that I am aware of. Is that a problem? If so, why? Seems rather silly. > the PI /48 routing slots > that you have justified need for -- arranged so that they fall within > the same /45. RIRs don't issue routing slots. They issue addressing blocks. Usually (though not always) these addressing blocks are aligned with prefixes. Sometimes those prefixes end up in one routing slot. Sometimes more. Occasionally, none at all. There is no definite relationship between network blocks issued by RIRs and prefixes and even less so between prefixes and routing slots. Owen From owen at delong.com Sat Mar 10 18:47:24 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 10 Mar 2012 16:47:24 -0800 Subject: filtering /48 is going to be necessary In-Reply-To: <4F5BEB06.3010805@bogus.com> References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> <4F5BEB06.3010805@bogus.com> Message-ID: <3A64BADF-8AB2-42CC-9EED-138DFDC4C8F2@delong.com> On Mar 10, 2012, at 4:00 PM, Joel jaeggli wrote: > On 3/10/12 14:47 , Sven Olaf Kamphuis wrote: >> let's say, there is 6 billion people in the world.. if they all have 1 >> route table entry (average ;) i see no technical limitations on anything >> produced AFTER 2008 actually. > > Over in ipv4 land there are ~40k entities that appear in the dfz > internet... Of those somewhat less than half (16k) announce just one > prefix. The top 30 ASes by route count on the other hand are 10% of the > table. > > I don't a see a problem with the small guys. I don't see the little guys > as a source of fib scaling problem becuase oddly enough they aren't. > > The actors causing the most impact on the size of my fib are by in large > on this mailing list... > > joel I expect that many of those are not nearly as likely to create as many routes in IPv6. Hence my belief that the problem is generally solved for some time to come once we can stop carrying the bloated obsolete IPv4 table for legacy support. Owen From dougb at dougbarton.us Sat Mar 10 19:00:01 2012 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 10 Mar 2012 17:00:01 -0800 Subject: Concern about gTLD servers in India In-Reply-To: <5803165C-6981-43E3-9239-BF1F9D341720@delong.com> References: <4F5AFD28.9010103@apolix.co.za> <79350CD0-0BFE-4590-9856-B85C34F89241@pch.net> <4F5BD03E.6020004@nic-naa.net> <5803165C-6981-43E3-9239-BF1F9D341720@delong.com> Message-ID: <4F5BF911.50108@dougbarton.us> On 03/10/2012 04:38 PM, Owen DeLong wrote: > > On Mar 10, 2012, at 2:05 PM, Eric Brunner-Williams wrote: > >> On 3/10/12 3:23 PM, Jonathan Lassoff wrote: >>> I would presume that Verisign decided that it just wasn't worth >>> the effort to deploy into India. >> >> operational control of .in passed to a for-profit operator >> domiciled in one_of{us,ca,ie} other than VGRS. as india is a >> competitor's property, investment there by VGRS mby be difficult to >> justify. >> >> -e > > The more telling fallacy here that really speaks to the heart of why > I am dismayed and disappointed by ICANN's management of the whole TLD > mess is the idea that a CCTLD is the property of a TLD operator to > begin with. I'm pretty sure that's not what Eric meant by "property," at least I hope it isn't. I think he meant given that Verisign is no longer responsible for the registry services operator backend that it doesn't make sense for them to be investing money in making that backend better. I can also tell you based on my experience with them that Afilias doesn't consider the TLDs that they provide RSO support for as their property either. > The .IN TLD is property of the Indian people or worst case, the > government of India acting in their stead. (or at least it should be > if ICANN and/or Verisign and their competitors haven't managed to > completely usurp the public trust. I can tell you with 100% certainty that when I was responsible for handling ccTLD delegation changes that we took the issue of ccTLDs being operated for the benefit of the Internet community in that country, and the global Internet community as a whole, very seriously. I have no reason to believe that things changed after I left. Doug -- If you're never wrong, you're not trying hard enough From rubensk at gmail.com Sat Mar 10 19:31:32 2012 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 10 Mar 2012 19:31:32 -0600 Subject: Concern about gTLD servers in India In-Reply-To: <4F5BF911.50108@dougbarton.us> References: <4F5AFD28.9010103@apolix.co.za> <79350CD0-0BFE-4590-9856-B85C34F89241@pch.net> <4F5BD03E.6020004@nic-naa.net> <5803165C-6981-43E3-9239-BF1F9D341720@delong.com> <4F5BF911.50108@dougbarton.us> Message-ID: > I can tell you with 100% certainty that when I was responsible for > handling ccTLD delegation changes that we took the issue of ccTLDs being > operated for the benefit of the Internet community in that country, and > the global Internet community as a whole, very seriously. I have no > reason to believe that things changed after I left. Starting with .tv that line got somewhat gray; ccTLD "repurposing" is commonplace nowadays. Initial ccTLD delegations, even the more recent ones, still seems to hold up to Postel's standard, though. Rubens From drc at virtualized.org Sat Mar 10 19:51:51 2012 From: drc at virtualized.org (David Conrad) Date: Sat, 10 Mar 2012 19:51:51 -0600 Subject: Concern about gTLD servers in India In-Reply-To: <5803165C-6981-43E3-9239-BF1F9D341720@delong.com> References: <4F5AFD28.9010103@apolix.co.za> <79350CD0-0BFE-4590-9856-B85C34F89241@pch.net> <4F5BD03E.6020004@nic-naa.net> <5803165C-6981-43E3-9239-BF1F9D341720@delong.com> Message-ID: <755972BD-E85D-4893-B5D3-3E405535AE1D@virtualized.org> On Mar 10, 2012, at 6:38 PM, Owen DeLong wrote: > The more telling fallacy here that really speaks to the heart of why I am dismayed and disappointed by ICANN's management of the whole TLD mess is the idea that a CCTLD is the property of a TLD operator to begin with. Your dismay and disappointment may be relieved by doing a bit of research. Management of country code top-level domains is treated by ICANN as national sovereignty issue. ICANN has limited say in who runs a ccTLD (it must be done according to the wishes of the "local Internet community") and technical matters related to how that ccTLD is managed (e.g., ICANN, through the IANA root management functions places certain (minimal) technical requirements on the operation of the TLD name servers). > The .IN TLD is property of the Indian people or worst case, the government of India acting in their stead. (or at least it should be if ICANN and/or Verisign and their competitors haven't managed to completely usurp the public trust. You might want to read RFC 1591, ICP-1, and/or the ICANN GAC principles before passing judgement. Regards, -drc From tknchris at gmail.com Sat Mar 10 20:02:51 2012 From: tknchris at gmail.com (chris) Date: Sat, 10 Mar 2012 21:02:51 -0500 Subject: BellSouth (att?) with a clue in Raleigh, NC Message-ID: Hi, I am trying to look into dsl in the RDU area and at&t customer service has been exceedingly unhelpful only telling me "no service available, we have no idea when services will become available, check back periodically". I would atleast like to get an answer that theres no available capacity, its over the 18k limit of dsl, or some other logical answer. Is there anyone at bellsouth/att or one of their clec's who can help me do some qual's and hopefully also help get this delivered? i did some lookups on known pots in the area and came up with: LATA426 NameR ALEIGH N CAROLINA Historical Region BellSouth Area Codes in LATA 919 Carrier Common Name AT&T Southeast OCN 9417 OCN Type RBOC Name Bellsouth Telecomm Inc dba Southern Bell Telephone & Telegraph Abbreviation BELLSOUTH SO BELL DBA Southern Bell Telephone & Telegraph FKA Southern Bell Telephone & Telegraph so im pretty sure im contacting the right telco just surprised that their customer service is offering pots but says no internet available, wtf? thanks for any info you can provide, chris From faisal at snappydsl.net Sat Mar 10 20:23:04 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sat, 10 Mar 2012 21:23:04 -0500 Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: References: Message-ID: Google for their Uverse site and check if u can get it... They will do Uverse (Internet only). Only if u order online.... Faisal Sent from my iPhone On Mar 10, 2012, at 9:02 PM, chris wrote: > Hi, > > I am trying to look into dsl in the RDU area and at&t customer service has > been exceedingly unhelpful only telling me "no service available, we have > no idea when services will become available, check back periodically". > I would atleast like to get an answer that theres no available capacity, > its over the 18k limit of dsl, or some other logical answer. Is there > anyone at bellsouth/att or one of their clec's who can help me do some > qual's and hopefully also help get this delivered? > > i did some lookups on known pots in the area and came up with: > LATA426 > NameR ALEIGH N CAROLINA > Historical Region BellSouth > Area Codes in LATA 919 > Carrier > Common Name AT&T Southeast > OCN 9417 > OCN Type RBOC > Name Bellsouth Telecomm Inc dba Southern Bell Telephone & Telegraph > Abbreviation BELLSOUTH SO BELL > DBA Southern Bell Telephone & Telegraph > FKA Southern Bell Telephone & Telegraph > > > so im pretty sure im contacting the right telco just surprised that their > customer service is offering pots but says no internet available, wtf? > > thanks for any info you can provide, > chris > From tknchris at gmail.com Sat Mar 10 20:34:24 2012 From: tknchris at gmail.com (chris) Date: Sat, 10 Mar 2012 21:34:24 -0500 Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: References: Message-ID: Looks like no dice on uverse, says its not available. i thought uverse was fios though atleast that was my understanding. now im even more confused, how can att/bellsouth be the ILEC and have zero internet options at all but be offering pots? Only logical thing I can think of is distance from the CO making dsl a no-go but i cant get an actual qual to atleast confirm that :( On Sat, Mar 10, 2012 at 9:23 PM, Faisal Imtiaz wrote: > Google for their Uverse site and check if u can get it... They will do > Uverse (Internet only). Only if u order online.... > > Faisal > > Sent from my iPhone > > On Mar 10, 2012, at 9:02 PM, chris wrote: > > > Hi, > > > > I am trying to look into dsl in the RDU area and at&t customer service > has > > been exceedingly unhelpful only telling me "no service available, we have > > no idea when services will become available, check back periodically". > > I would atleast like to get an answer that theres no available capacity, > > its over the 18k limit of dsl, or some other logical answer. Is there > > anyone at bellsouth/att or one of their clec's who can help me do some > > qual's and hopefully also help get this delivered? > > > > i did some lookups on known pots in the area and came up with: > > LATA426 > > NameR ALEIGH N CAROLINA > > Historical Region BellSouth > > Area Codes in LATA 919 > > Carrier > > Common Name AT&T Southeast > > OCN 9417 > > OCN Type RBOC > > Name Bellsouth Telecomm Inc dba Southern Bell Telephone & Telegraph > > Abbreviation BELLSOUTH SO BELL > > DBA Southern Bell Telephone & Telegraph > > FKA Southern Bell Telephone & Telegraph > > > > > > so im pretty sure im contacting the right telco just surprised that their > > customer service is offering pots but says no internet available, wtf? > > > > thanks for any info you can provide, > > chris > > > From chipps at chipps.com Sat Mar 10 20:53:05 2012 From: chipps at chipps.com (Kenneth M. Chipps Ph.D.) Date: Sat, 10 Mar 2012 20:53:05 -0600 Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: References: Message-ID: <000601ccff32$1550b440$3ff21cc0$@chipps.com> Generally speaking these services are available anywhere AT&T has wires: Analog ISDN T1 due to these being the old tariffed services. If you call about ISDN, they will likely say, huh what is that? The easiest way to get T1 in service is to use a reseller. They will be deal with the ILEC for you. The cost will also be lower. This is what I did when I needed a T1 to the house out here in the country. I am 34,000 wire feet from the central office. My options were those above. I cycled through each one as I needed more and more speed. Kenneth M. Chipps Ph.D. -----Original Message----- From: chris [mailto:tknchris at gmail.com] Sent: Saturday, March 10, 2012 8:34 PM To: Faisal Imtiaz Cc: NANOG list Subject: Re: BellSouth (att?) with a clue in Raleigh, NC Looks like no dice on uverse, says its not available. i thought uverse was fios though atleast that was my understanding. now im even more confused, how can att/bellsouth be the ILEC and have zero internet options at all but be offering pots? Only logical thing I can think of is distance from the CO making dsl a no-go but i cant get an actual qual to atleast confirm that :( On Sat, Mar 10, 2012 at 9:23 PM, Faisal Imtiaz wrote: > Google for their Uverse site and check if u can get it... They will do > Uverse (Internet only). Only if u order online.... > > Faisal > > Sent from my iPhone > > On Mar 10, 2012, at 9:02 PM, chris wrote: > > > Hi, > > > > I am trying to look into dsl in the RDU area and at&t customer > > service > has > > been exceedingly unhelpful only telling me "no service available, we > > have no idea when services will become available, check back periodically". > > I would atleast like to get an answer that theres no available > > capacity, its over the 18k limit of dsl, or some other logical > > answer. Is there anyone at bellsouth/att or one of their clec's who > > can help me do some qual's and hopefully also help get this delivered? > > > > i did some lookups on known pots in the area and came up with: > > LATA426 > > NameR ALEIGH N CAROLINA > > Historical Region BellSouth > > Area Codes in LATA 919 > > Carrier > > Common Name AT&T Southeast > > OCN 9417 > > OCN Type RBOC > > Name Bellsouth Telecomm Inc dba Southern Bell Telephone & Telegraph > > Abbreviation BELLSOUTH SO BELL DBA Southern Bell Telephone & > > Telegraph FKA Southern Bell Telephone & Telegraph > > > > > > so im pretty sure im contacting the right telco just surprised that > > their customer service is offering pots but says no internet available, wtf? > > > > thanks for any info you can provide, chris > > > From ops.lists at gmail.com Sat Mar 10 21:53:17 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 11 Mar 2012 09:23:17 +0530 Subject: Concern about gTLD servers in India In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> <79350CD0-0BFE-4590-9856-B85C34F89241@pch.net> Message-ID: You mean you haven't then immediately heard the "we are a developing country, please provide it free" story? On 3/11/12, Jonathan Lassoff wrote: > On Sat, Mar 10, 2012 at 10:45 AM, Bill Woodcock wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> >> On Mar 10, 2012, at 8:05 AM, Suresh Ramasubramanian wrote: >>> Sure, if you can find a datacenter that's capable of handling all the >>> traffic, and has staff who are able to provide efficient remote hands for >>> huge racks of extremely powerful servers . >> >> Honestly, we haven't even gotten that far when we've offered to deploy >> servers (for instance for domains like .IN) inside India. ?The bribes that >> were requested in exchange for giving us permission to deploy a free >> service were, uh, both prohibitive and ludicrous in their enormity. > > This. > > This and the import duties on hardware and the requirement for > licensing to operate as an "ISP" makes placing even a modest > deployment a lot more work compared to deploying in other neighboring > countries. > > I would presume that Verisign decided that it just wasn't worth the > effort to deploy into India. > It obviously has a gigantic user base for which getting into local > ISPs and IXPs would probably save on transit costs. > > Perhaps if some local root operators could donate some > space/power/connectivity, Verisign-grs could colocate a gTLD cluster > there? > > Cheers, > jof > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From asr at latency.net Sat Mar 10 22:03:52 2012 From: asr at latency.net (Adam Rothschild) Date: Sat, 10 Mar 2012 23:03:52 -0500 Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: References: Message-ID: On Sat, Mar 10, 2012 at 9:02 PM, chris wrote: > I am trying to look into dsl in the RDU area and at&t customer service has > been exceedingly unhelpful only telling me "no service available, we have > no idea when services will become available, check back periodically". > I would atleast like to get an answer that theres no available capacity, > its over the 18k limit of dsl, or some other logical answer. Is there > anyone at bellsouth/att or one of their clec's who can help me do some > qual's and hopefully also help get this delivered? A number of folk on this list have access to their loop qualification database, myself included. Your street address is an important factor in determining eligibility, and unfortunately lacking from your post. HTH, -a From sethm at rollernet.us Sun Mar 11 01:26:27 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 10 Mar 2012 23:26:27 -0800 Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: References: Message-ID: <4F5C53A3.7050409@rollernet.us> On 3/10/12 6:34 PM, chris wrote: > Looks like no dice on uverse, says its not available. i thought uverse was > fios though atleast that was my understanding. now im even more confused, > how can att/bellsouth be the ILEC and have zero internet options at all but > be offering pots? Only logical thing I can think of is distance from the CO > making dsl a no-go but i cant get an actual qual to atleast confirm that :( > U-verse is VDSL2 with a practical workable distance of 3k wire feet depending on quality of the copper. ~Seth From plosher at isc.org Sun Mar 11 05:57:14 2012 From: plosher at isc.org (Peter Losher) Date: Sun, 11 Mar 2012 03:57:14 -0700 Subject: Concern about gTLD servers in India In-Reply-To: References: Message-ID: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> On Mar 9, 2012, at 10:19 PM, Anurag Bhatia wrote: > I can see India has 3 root servers hosting root zone - i, j & k in India > which is good. So we can resolve the root zone i.e dot within India. One correction to that; F has been operating in India from NIXI Chennai's PoP since 2005. The reason you may not see it from your location in India is that it's a local node, so we advertise F's prefixes with the NO_EXPORT community string to limit it's reach to networks directly connected to the local IX/routeserver @NIXI Chennai. And even with that restriction as noted at APNIC 33 in Dehli, the node is one of our (F's) busiest in Asia... -Peter -- [ plosher at isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] From me at anuragbhatia.com Sun Mar 11 06:01:35 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 11 Mar 2012 16:31:35 +0530 Subject: Concern about gTLD servers in India In-Reply-To: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> References: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> Message-ID: Thanks for info Peter I missed that because firstly no routes from major Indian backbones and second it is not even mentioned on official site of root servers - http://www.root-servers.org under F root. On Sun, Mar 11, 2012 at 4:27 PM, Peter Losher wrote: > On Mar 9, 2012, at 10:19 PM, Anurag Bhatia wrote: > > > I can see India has 3 root servers hosting root zone - i, j & k in India > > which is good. So we can resolve the root zone i.e dot within India. > > > One correction to that; F has been operating in India from NIXI Chennai's > PoP since 2005. The reason you may not see it from your location in India > is that it's a local node, so we advertise F's prefixes with the NO_EXPORT > community string to limit it's reach to networks directly connected to the > local IX/routeserver @NIXI Chennai. > > And even with that restriction as noted at APNIC 33 in Dehli, the node is > one of our (F's) busiest in Asia... > > -Peter > -- > [ plosher at isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From plosher at isc.org Sun Mar 11 06:07:46 2012 From: plosher at isc.org (Peter Losher) Date: Sun, 11 Mar 2012 04:07:46 -0700 Subject: Concern about gTLD servers in India In-Reply-To: References: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> Message-ID: <72442ECD-AD48-4CD3-8DC6-947C9007EB65@isc.org> On Mar 11, 2012, at 4:01 AM, Anurag Bhatia wrote: > Thanks for info Peter > > > I missed that because firstly no routes from major Indian backbones I can assure you that we get a good chunk of traffic from at least one of the "major Indian Backbones". The Chennai PoP is smaller than NIXI's other locations in Mumbai/Dehli/Kolkata, but it has a couple of the major players... > and second it is not even mentioned on official site of root servers - http://www.root-servers.org under F root. Umm, but it is... search for "Chennai, IN" and also look the "F" bubble on Chennai on the Google Map that is on the page. Best Wishes - Peter -- [ plosher at isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] From me at anuragbhatia.com Sun Mar 11 06:11:58 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 11 Mar 2012 16:41:58 +0530 Subject: Concern about gTLD servers in India In-Reply-To: <72442ECD-AD48-4CD3-8DC6-947C9007EB65@isc.org> References: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> <72442ECD-AD48-4CD3-8DC6-947C9007EB65@isc.org> Message-ID: Oops Almost missed that. Sorry about that. Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily. On Sun, Mar 11, 2012 at 4:37 PM, Peter Losher wrote: > On Mar 11, 2012, at 4:01 AM, Anurag Bhatia wrote: > > > Thanks for info Peter > > > > > > I missed that because firstly no routes from major Indian backbones > > I can assure you that we get a good chunk of traffic from at least one of > the "major Indian Backbones". The Chennai PoP is smaller than NIXI's other > locations in Mumbai/Dehli/Kolkata, but it has a couple of the major > players... > > > and second it is not even mentioned on official site of root servers - > http://www.root-servers.org under F root. > > Umm, but it is... search for "Chennai, IN" and also look the "F" bubble on > Chennai on the Google Map that is on the page. > > Best Wishes - Peter > -- > [ plosher at isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From plosher at isc.org Sun Mar 11 06:27:56 2012 From: plosher at isc.org (Peter Losher) Date: Sun, 11 Mar 2012 04:27:56 -0700 Subject: Concern about gTLD servers in India In-Reply-To: References: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> <72442ECD-AD48-4CD3-8DC6-947C9007EB65@isc.org> Message-ID: <1FEB0783-9C97-4C7E-A3FC-274BDEAEB31B@isc.org> On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote: > Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily. You would have to ask Verisign as operators of the com/net gTLD servers and Afilias for .org about their DNS deployments. I can only speak for ISC as we operate F.ROOT-SERVERS.NET. Best Wishes - Peter -- [ plosher at isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] From chcheng at ieee.org Sun Mar 11 08:32:53 2012 From: chcheng at ieee.org (Che-Hoo CHENG) Date: Sun, 11 Mar 2012 21:32:53 +0800 Subject: Concern about gTLD servers in India In-Reply-To: <1FEB0783-9C97-4C7E-A3FC-274BDEAEB31B@isc.org> References: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> <72442ECD-AD48-4CD3-8DC6-947C9007EB65@isc.org> <1FEB0783-9C97-4C7E-A3FC-274BDEAEB31B@isc.org> Message-ID: <1A4BF63C-649A-43CC-9CE3-397793ADAF92@ieee.org> As J is already there in India which is operated by Verisign, I don't think it's difficult to add .com & .net by Verisign. Just talk to them. Regards, Che-Hoo On 11 Mar, 2012, at 7:27 PM, Peter Losher wrote: > On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote: > >> Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily. > > You would have to ask Verisign as operators of the com/net gTLD servers and Afilias for .org about their DNS deployments. I can only speak for ISC as we operate F.ROOT-SERVERS.NET. > > Best Wishes - Peter > -- > [ plosher at isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] > > From me at anuragbhatia.com Sun Mar 11 10:11:19 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 11 Mar 2012 20:41:19 +0530 Subject: root zone stats In-Reply-To: <4F5BE02F.60901@dougbarton.us> References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> <86haxw7jfh.fsf@seastrom.com> <4F5BE02F.60901@dougbarton.us> Message-ID: Thanks for sharing interesting data. Was wondering you have map of g TLD server locations? Something like that of root servers? (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Mar 11, 2012 4:44 AM, "Doug Barton" wrote: > Since there was a question about this, some numbers: > > Serial: 2012031001 > > Statistics > ========== > Number of root servers: 13 > Roots with IPv6 glue: 9 > > Number of gTLDs: 22 > Number of ccTLDs: 249 > Number of IDN TLDs: 42 > Total number of TLDs: 313 > > Number of IPv4 hosts: 1176 > Number of IPv4 addresses: 1145 > > Number of IPv6 hosts: 427 > Number of IPv6 addresses: 412 > TLDs with IPv6 glue: 258 > > Total name server hosts: 1177 > Total NS addresses: 1557 > > Number of DS records: 141 > Number of TLDs with DS: 85 > > > Enjoy, > > Doug > > -- > If you're never wrong, you're not trying hard enough > > From drc at virtualized.org Sun Mar 11 10:43:10 2012 From: drc at virtualized.org (David Conrad) Date: Sun, 11 Mar 2012 09:43:10 -0600 Subject: [apnic-talk] root zone stats In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> <86haxw7jfh.fsf@seastrom.com> <4F5BE02F.60901@dougbarton.us> Message-ID: Anurag, On Mar 11, 2012, at 9:11 AM, Anurag Bhatia wrote: > Thanks for sharing interesting data. Was wondering you have map of g TLD server locations? Something like that of root servers? > You would probably need to ask the operators of the gTLDs. As they are (generally) commercial services, whether they publish the locations of their servers is a business decision that they would each independently make. Regards, -drc From iljitsch at muada.com Sun Mar 11 10:48:15 2012 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 11 Mar 2012 16:48:15 +0100 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> On 9 Mar 2012, at 10:02 , Jeff Wheeler wrote: > The way we are headed right now, it is likely that the IPv6 address > space being issued today will look like "the swamp" in a few short > years, and we will regret repeating this obvious mistake. > We had this discussion on the list exactly a year ago. At that time, > the average IPv6 origin ASN was announcing 1.43 routes. That figure > today is 1.57 routes per origin ASN. The IETF and IRTF have looked at the routing scalability issue for a long time. The IETF came up with shim6, which allows multihoming without BGP. Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered to adopt shim6. I haven't followed the IRTF RRG results for a while, but at some point LISP came out of this, where we basically tunnel the entire internet so the core routers don't have to see the real routing table. But back to the topic at hand: filtering long prefixes. There are two reasons you want to do this: 1. Attackers could flood BGP with bogus prefixes to make tables overflow 2. Legitimate prefixes may be deaggregated so tables overflow It won't be quick or easy, but the RPKI stuff should solve 1. So that leaves the issue of deaggregating legitimate prefixes. There are around 100k prefixes given out by the RIRs and nearly 400k in the routing tables. A quick look at the IPv4 BGP table shows that unless I missed the day in school when they covered "reasons to advertise 64 /22s instead of a /16" a good percentage of those deaggregates happen without any legitimate reason. Although the RIRs don't make this as easy as they could, it IS possible to determine the maximum prefix length for any given block of RIR space, and then simply filter on that prefix length. That takes care of the /48s and /32 deaggregating, but unfortunately not the /44s out of space used for /48s or the /20s out of space used for /32s. So the RIRs should up their game here, then we can really hold LIR's feet to the fire and stop them from deaggregating. That does of course leave people who do have a good reason to deaggreagate in the cold. But that's also easy to solve: if you run two separate networks, you need two prefixes and two AS numbers. So the RIRs should develop policies that allow for this if it's reasonable. If that means that an organization can't have both a bunch of independently announced prefixes AND have all those prefixes be part of one aggregate for easy firewall configuration, that's too bad. The RIRs should pick up on this, because there WILL be a moment an ISP deaggregates a /32 into 65000 /48s with the result that half the IPv6 internet goes down. From maxsec at gmail.com Sun Mar 11 11:33:50 2012 From: maxsec at gmail.com (Martin Hepworth) Date: Sun, 11 Mar 2012 16:33:50 +0000 Subject: root zone stats In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> <86haxw7jfh.fsf@seastrom.com> <4F5BE02F.60901@dougbarton.us> Message-ID: On Sunday, 11 March 2012, David Conrad wrote: > Anurag, > > On Mar 11, 2012, at 9:11 AM, Anurag Bhatia wrote: >> Thanks for sharing interesting data. Was wondering you have map of g TLD server locations? Something like that of root servers? >> > > You would probably need to ask the operators of the gTLDs. As they are (generally) commercial services, whether they publish the locations of their servers is a business decision that they would each independently make. > > Regards, > -drc > Correct, location of the .uk servers aren't published as they are treated as part of national infrastructure and protected as such -- Martin Oxford uk -- -- Martin Hepworth Oxford, UK From Ed.Lewis at neustar.biz Sun Mar 11 12:14:30 2012 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Sun, 11 Mar 2012 11:14:30 -0600 Subject: ccTLD operators do not "rule", was Re: Concern about ... In-Reply-To: <5803165C-6981-43E3-9239-BF1F9D341720@delong.com> References: <4F5AFD28.9010103@apolix.co.za> <79350CD0-0BFE-4590-9856-B85C34F89241@pch.net> <4F5BD03E.6020004@nic-naa.net> <5803165C-6981-43E3-9239-BF1F9D341720@delong.com> Message-ID: At 16:38 -0800 3/10/12, Owen DeLong wrote: >The more telling fallacy here that really speaks to the heart of why I >am dismayed and disappointed by ICANN's management of the whole TLD mess >is the idea that a CCTLD is the property of a TLD operator to begin with. This is not true. First, there is the ccTLD itself - it is an organization that is recognized has having legitimate claim to the country code. These do change at times. Then there is the ccTLD operator. Some ccTLDs "own and operate" and some do out source the technical operations, sometimes just DNS, sometimes everything (e.g., the database). When out sourcing, the ccTLD "owner" makes contractural demands of the operator. If the ccTLD requires an in-country DNS presence that is easily arranged by the operator. (The operator reflects the cost in the price.) With the growing awareness of the role of the Internet, ccTLDs do not let the operator "do their thing." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From joelja at bogus.com Sun Mar 11 14:15:33 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 11 Mar 2012 12:15:33 -0700 Subject: filtering /48 is going to be necessary In-Reply-To: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> Message-ID: <4F5CF9D5.9050601@bogus.com> On 3/11/12 08:48 , Iljitsch van Beijnum wrote: > On 9 Mar 2012, at 10:02 , Jeff Wheeler wrote: > >> The way we are headed right now, it is likely that the IPv6 >> address space being issued today will look like "the swamp" in a >> few short years, and we will regret repeating this obvious >> mistake. > >> We had this discussion on the list exactly a year ago. At that >> time, the average IPv6 origin ASN was announcing 1.43 routes. That >> figure today is 1.57 routes per origin ASN. > > The IETF and IRTF have looked at the routing scalability issue for a > long time. The IETF came up with shim6, which allows multihoming > without BGP. Unfortunately, ARIN started to allow IPv6 PI just in > time so nobody bothered to adopt shim6. That's a fairly simplistic version of why shim6 failed. A better reason (appart from the fact the building an upper layer overlay of the whole internet on an ip protocol that's largely unedeployed was hard) is that it leaves the destination unable to perform traffic engineering. That fundementaly is the business we're in when advertising prefixes to more than one provider, ingress path selection. Sancho Panza couldn't get us out of that one. From arturo.servin at gmail.com Sun Mar 11 14:30:54 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Sun, 11 Mar 2012 13:30:54 -0600 Subject: filtering /48 is going to be necessary In-Reply-To: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> Message-ID: <2DD83247-6C6D-488B-B4C9-E41808DDDE56@gmail.com> On 11 Mar 2012, at 09:48, Iljitsch van Beijnum wrote: > On 9 Mar 2012, at 10:02 , Jeff Wheeler wrote: > >> The way we are headed right now, it is likely that the IPv6 address >> space being issued today will look like "the swamp" in a few short >> years, and we will regret repeating this obvious mistake. > >> We had this discussion on the list exactly a year ago. At that time, >> the average IPv6 origin ASN was announcing 1.43 routes. That figure >> today is 1.57 routes per origin ASN. > > The IETF and IRTF have looked at the routing scalability issue for a long time. The IETF came up with shim6, which allows multihoming without BGP. Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered to adopt shim6. I haven't followed the IRTF RRG results for a while, but at some point LISP came out of this, where we basically tunnel the entire internet so the core routers don't have to see the real routing table. > > But back to the topic at hand: filtering long prefixes. There are two reasons you want to do this: > > 1. Attackers could flood BGP with bogus prefixes to make tables overflow > > 2. Legitimate prefixes may be deaggregated so tables overflow > > It won't be quick or easy, but the RPKI stuff should solve 1. > > Unless the attacker uses the same origin AS that is in the ROA. Probably it won't hijack the traffic but it may create a DoS or any other kind of problem. Regards, as From frnkblk at iname.com Sun Mar 11 16:22:33 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 11 Mar 2012 16:22:33 -0500 Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: References: Message-ID: <0d8d01ccffcd$12caf050$3860d0f0$@iname.com> Verizon is FiOS, AT&T has U-verse which is FTTC. Frank -----Original Message----- From: chris [mailto:tknchris at gmail.com] Sent: Saturday, March 10, 2012 8:34 PM To: Faisal Imtiaz Cc: NANOG list Subject: Re: BellSouth (att?) with a clue in Raleigh, NC Looks like no dice on uverse, says its not available. i thought uverse was fios though atleast that was my understanding. now im even more confused, how can att/bellsouth be the ILEC and have zero internet options at all but be offering pots? Only logical thing I can think of is distance from the CO making dsl a no-go but i cant get an actual qual to atleast confirm that :( On Sat, Mar 10, 2012 at 9:23 PM, Faisal Imtiaz wrote: > Google for their Uverse site and check if u can get it... They will do > Uverse (Internet only). Only if u order online.... > > Faisal > > Sent from my iPhone > > On Mar 10, 2012, at 9:02 PM, chris wrote: > > > Hi, > > > > I am trying to look into dsl in the RDU area and at&t customer service > has > > been exceedingly unhelpful only telling me "no service available, we have > > no idea when services will become available, check back periodically". > > I would atleast like to get an answer that theres no available capacity, > > its over the 18k limit of dsl, or some other logical answer. Is there > > anyone at bellsouth/att or one of their clec's who can help me do some > > qual's and hopefully also help get this delivered? > > > > i did some lookups on known pots in the area and came up with: > > LATA426 > > NameR ALEIGH N CAROLINA > > Historical Region BellSouth > > Area Codes in LATA 919 > > Carrier > > Common Name AT&T Southeast > > OCN 9417 > > OCN Type RBOC > > Name Bellsouth Telecomm Inc dba Southern Bell Telephone & Telegraph > > Abbreviation BELLSOUTH SO BELL > > DBA Southern Bell Telephone & Telegraph > > FKA Southern Bell Telephone & Telegraph > > > > > > so im pretty sure im contacting the right telco just surprised that their > > customer service is offering pots but says no internet available, wtf? > > > > thanks for any info you can provide, > > chris > > > From frnkblk at iname.com Sun Mar 11 16:50:42 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 11 Mar 2012 16:50:42 -0500 Subject: root zone stats In-Reply-To: <4F5BE02F.60901@dougbarton.us> References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> <86haxw7jfh.fsf@seastrom.com> <4F5BE02F.60901@dougbarton.us> Message-ID: <0da701ccffd1$019ff650$04dfe2f0$@iname.com> Some nice info here, too: http://bgp.he.net/report/dns Frank -----Original Message----- From: Doug Barton [mailto:dougb at dougbarton.us] Sent: Saturday, March 10, 2012 5:14 PM Cc: APNIC Mailing List; nanog at nanog.org Subject: root zone stats Since there was a question about this, some numbers: Serial: 2012031001 Statistics ========== Number of root servers: 13 Roots with IPv6 glue: 9 Number of gTLDs: 22 Number of ccTLDs: 249 Number of IDN TLDs: 42 Total number of TLDs: 313 Number of IPv4 hosts: 1176 Number of IPv4 addresses: 1145 Number of IPv6 hosts: 427 Number of IPv6 addresses: 412 TLDs with IPv6 glue: 258 Total name server hosts: 1177 Total NS addresses: 1557 Number of DS records: 141 Number of TLDs with DS: 85 Enjoy, Doug -- If you're never wrong, you're not trying hard enough From nick at foobar.org Sun Mar 11 17:02:47 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 11 Mar 2012 22:02:47 +0000 Subject: BGP MD5 at IXP In-Reply-To: <86lin87l70.fsf@seastrom.com> References: <4EDF1A71-7DBA-4097-BEDF-6EBB1C43089E@nosignal.org> <86lin87l70.fsf@seastrom.com> Message-ID: <4F5D2107.5020704@foobar.org> On 10/03/2012 11:24, Robert E. Seastrom wrote: > Hopefully your modern exchange point router has some sort of control > plane policing. My gut feeling is that lots don't. The behaviour of various operating systems regarding MD5 processing is interesting. *BSD (and I assume consequently junos) checks ttl and sequence numbers before checking md5. Linux and IOS do md5 first, and I just wonder about the wisdom of this approach due to the slightly higher computational overhead of calculating the hash. In general, I'm slightly in favour of md5 at ixps, not because of session security, but when exchange participants leave an ixp, lots of people don't bother to remove the bgp sessions. If as a newcomer to the IXP you get a re-used ip address, without md5 it can sometimes be possible to do Interesting and Bad Things with old sessions from other ixp participants. FWIW, for the INEX route server system we: - use bsd - implement packet filtering to accept tcp/bgp only from the ixp subnet - generally use md5 for ipv4 sessions - generally don't use md5 for ipv6 sessions for historical reasons This works for us. > I agree with Andy's conclusion. Don't do it unless whoever you're > peering with demands it. It's not worth the complexity to set it up > in the first place, and it's not worth your time to argue against it > if someone is quite convinced that enabling md5 on your bgp session > will save the world. yep, agreed. Doesn't make that much difference in real life so don't lose sleep about it. The only real difference it makes is that it can help shut up "security" audit people (the tick-box compliance variety) from their ivory tower whining. Nick From iljitsch at muada.com Sun Mar 11 17:15:38 2012 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 11 Mar 2012 23:15:38 +0100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F5CF9D5.9050601@bogus.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> Message-ID: <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> On 11 Mar 2012, at 20:15 , Joel jaeggli wrote: >> The IETF and IRTF have looked at the routing scalability issue for a >> long time. The IETF came up with shim6, which allows multihoming >> without BGP. Unfortunately, ARIN started to allow IPv6 PI just in >> time so nobody bothered to adopt shim6. > That's a fairly simplistic version of why shim6 failed. A better reason > (appart from the fact the building an upper layer overlay of the whole > internet on an ip protocol that's largely unedeployed was hard) is that > it leaves the destination unable to perform traffic engineering. I'm not saying that shim6 would have otherwise ruled the world by now, it was always an uphill battle because it requires support on both sides of a communication session/association. But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI after a decade, just when the multi6/shim6 effort started to get going but before the work was complete enough to judge whether it would be good enough. > That fundementaly is the business we're in when advertising prefixes to more > than one provider, ingress path selection. That's the business network operators are in. That's not the business end users who don't want to depend on a single ISP are in. Remember, shim6 was always meant as a solution that addresses the needs of a potential 1 billion "basement multihomers" with maybe ADSL + cable. The current 25k or so multihomers are irrelevant from the perspective of routing scalability. It's the other 999,975,000 that will kill the routing tables if multihoming becomes mainstream. From faisal at snappydsl.net Sun Mar 11 17:55:51 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sun, 11 Mar 2012 18:55:51 -0400 Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: References: Message-ID: <4F5D2D77.1050002@snappydsl.net> HI Chris, If you are out of luck in getting DSL or Uverse. I would suggest that you try your local Cable Service Provider. If that does not work out either, I would suggest you take a look to see if you have A WISP (Fixed Wireless Service) service provider in the area. (http://www.wipa.org/find-a-wisp .. Find a WISP link is under About WISPA menu). Regards. Faisal Imtiaz Snappy Internet& Telecom On 3/10/2012 9:34 PM, chris wrote: > Looks like no dice on uverse, says its not available. i thought uverse > was fios though atleast that was my understanding. now im even more > confused, how can att/bellsouth be the ILEC and have zero internet > options at all but be offering pots? Only logical thing I can think of > is distance from the CO making dsl a no-go but i cant get an actual > qual to atleast confirm that :( > > On Sat, Mar 10, 2012 at 9:23 PM, Faisal Imtiaz > wrote: > > Google for their Uverse site and check if u can get it... They > will do Uverse (Internet only). Only if u order online.... > > Faisal > > Sent from my iPhone > > On Mar 10, 2012, at 9:02 PM, chris > wrote: > > > Hi, > > > > I am trying to look into dsl in the RDU area and at&t customer > service has > > been exceedingly unhelpful only telling me "no service > available, we have > > no idea when services will become available, check back > periodically". > > I would atleast like to get an answer that theres no available > capacity, > > its over the 18k limit of dsl, or some other logical answer. Is > there > > anyone at bellsouth/att or one of their clec's who can help me > do some > > qual's and hopefully also help get this delivered? > > > > i did some lookups on known pots in the area and came up with: > > LATA426 > > NameR ALEIGH N CAROLINA > > Historical Region BellSouth > > Area Codes in LATA 919 > > Carrier > > Common Name AT&T Southeast > > OCN 9417 > > OCN Type RBOC > > Name Bellsouth Telecomm Inc dba Southern Bell Telephone & Telegraph > > Abbreviation BELLSOUTH SO BELL > > DBA Southern Bell Telephone & Telegraph > > FKA Southern Bell Telephone & Telegraph > > > > > > so im pretty sure im contacting the right telco just surprised > that their > > customer service is offering pots but says no internet > available, wtf? > > > > thanks for any info you can provide, > > chris > > > > From virendra.rode at gmail.com Sun Mar 11 18:22:12 2012 From: virendra.rode at gmail.com (virendra rode) Date: Sun, 11 Mar 2012 16:22:12 -0700 Subject: Concern about gTLD servers in India In-Reply-To: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> References: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> Message-ID: <4F5D33A4.7070102@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/11/2012 03:57 AM, Peter Losher wrote: > On Mar 9, 2012, at 10:19 PM, Anurag Bhatia wrote: > >> I can see India has 3 root servers hosting root zone - i, j & k in India >> which is good. So we can resolve the root zone i.e dot within India. > > > One correction to that; F has been operating in India from NIXI Chennai's PoP since 2005. The reason you may not see it from your location in India is that it's a local node, so we advertise F's prefixes with the NO_EXPORT community string to limit it's reach to networks directly connected to the local IX/routeserver @NIXI Chennai. - --------------------------- I see 192.5.5.0/24 less widely seen by the peers as opposed to 192.5.4.0/23 maybe as you mentioned the longer prefix (/24) should be visible to clients using local instance of f-root. Why? It would be bad to attract traffic from half way around the world to a local node as they are there to serve the local community. Just wondering how do the other root keepers manage that because reminds me of an outage (k-root related) sometime september or october time frame of 2010 that a /24 may have leak more widely than intended from a one of the local instances. I know off-topic here but what caught my interest is in "no_export" set for root server as the outage mentioned above came near the K-root local instance in India. regards, /virendra > > And even with that restriction as noted at APNIC 33 in Dehli, the node is one of our (F's) busiest in Asia... > > -Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk9dM6QACgkQ3HuimOHfh+H61gD/VGHBJdphTPA1yOYUGr7nmouG UJwR3yL4WAPcgfpDh6oA/AvwWW7kqU00ghOVE+Xioejv2gKPBQDB18hHGrmEcxtY =RDVK -----END PGP SIGNATURE----- From bonomi at mail.r-bonomi.com Sun Mar 11 18:35:22 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 11 Mar 2012 18:35:22 -0500 (CDT) Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: <4F5D2D77.1050002@snappydsl.net> Message-ID: <201203112335.q2BNZM6e036288@mail.r-bonomi.com> Faisal Imtiaz wrote: > > HI Chris, > If you are out of luck in getting DSL or Uverse. > I would suggest that you try your local Cable Service Provider. > If that does not work out either, I would suggest you take a look to see > if you have A WISP (Fixed Wireless Service) service provider in the area. > > (http://www.wipa.org/find-a-wisp .. Find a WISP link is under About > WISPA menu). "Spelling counts." The correct URL is; As in ireless nternent ervices

rovider ssociation. From dougb at dougbarton.us Sun Mar 11 19:42:02 2012 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 11 Mar 2012 17:42:02 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> Message-ID: <4F5D465A.2060301@dougbarton.us> On 3/11/2012 3:15 PM, Iljitsch van Beijnum wrote: > But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI after a decade Because as far back as 2003 ARIN members (and members from all the other RIRs for that matter) were saying in very clear terms that PI space was a requirement for moving to v6. No one wanted to lose the provider independence that they had gained with v4. Without that, v6 was a total non-starter. ARIN was simply listening to its members. Doug -- If you're never wrong, you're not trying hard enough From owen at delong.com Sun Mar 11 20:44:22 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 11 Mar 2012 18:44:22 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> Message-ID: On Mar 11, 2012, at 3:15 PM, Iljitsch van Beijnum wrote: > On 11 Mar 2012, at 20:15 , Joel jaeggli wrote: > >>> The IETF and IRTF have looked at the routing scalability issue for a >>> long time. The IETF came up with shim6, which allows multihoming >>> without BGP. Unfortunately, ARIN started to allow IPv6 PI just in >>> time so nobody bothered to adopt shim6. > >> That's a fairly simplistic version of why shim6 failed. A better reason >> (appart from the fact the building an upper layer overlay of the whole >> internet on an ip protocol that's largely unedeployed was hard) is that >> it leaves the destination unable to perform traffic engineering. > > I'm not saying that shim6 would have otherwise ruled the world by now, it was always an uphill battle because it requires support on both sides of a communication session/association. > > But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI after a decade, just when the multi6/shim6 effort started to get going but before the work was complete enough to judge whether it would be good enough. > As the person who led the charge in that action, I can probably answer that question... First, from my perspective at the time, SHIM6 didn't stand a chance. It was massively complex, required modifying the stack on every single end system to yield useful results and mad windows domain administration look simple by comparison. As such, I just didn't see any probability of SHIM6 becoming operational reality. (I think LISP suffers from many, though not all) of the same problems, frankly. I remember having this argument with you at the time, so, I'm surprised you don't remember the other side of the argument from the original discussions. However, there was also tremendous pressure in the community for "We're not going to adopt IPv6 when it puts us at a competitive disadvantage by locking us in to our upstream choices while we have portability with IPv4." Like it or not, that's a reality and it's a reality that is critically important to getting IPv6 adopted on a wider scale. Fortunately, it was a reality we were able to address through policy (though not without significant opposition from purists like yourself and larger providers that like the idea of locking in customers). >> That fundementaly is the business we're in when advertising prefixes to more >> than one provider, ingress path selection. > > That's the business network operators are in. That's not the business end users who don't want to depend on a single ISP are in. Remember, shim6 was always meant as a solution that addresses the needs of a potential 1 billion "basement multihomers" with maybe ADSL + cable. The current 25k or so multihomers are irrelevant from the perspective of routing scalability. It's the other 999,975,000 that will kill the routing tables if multihoming becomes mainstream. It's not just about depending on a single ISP, it's also about being able to change your mind about which ISPs you are attached to without having to undertake a multi-month corporate-wide project in the process. Let's compare... BGP multihoming with portable PI prefix: 1. Sign new contract. 2. Make new connection. 3. Bring up new BGP session. 4. Verify routes are working in both directions and seen globally. 5. -- 6. -- 7. -- 8. -- 9. Tear down old BGP session. 10. -- 11. Terminate old contract. 12. -- PA based prefix: 1. Sign new contract. 2. Make new connection. 3. Get routing working for new prefix over new connection. 4. Add new prefix to all routers, switches, provisioning systems, databases, etc. 5. Renumber every machine in the company. 6. Renumber all of the VPNs. 7. Deal with all the remote ACL issues. 8. Deal with any other fallout. 9. Turn off old prefix and connection. 10. Deal with the fallout from the things that weren't symptomatic in steps 4-9. 11. Terminate old contract 12. Remove old prefix from all remaining equipment configurations. By my count, that's twice as many steps to move a PA end-user organization and let's face it, steps 5, 6, and 7 (which don't exist in the PI scenario) take the longest and steps 7, 8, and 10 (again, non-existant in the PI scenario) are the most painful and potentially the most costly. No multihomed business in their right mind is going to accept PA space as a viable way to run their network. Owen From meirea at charterschoolit.com Sun Mar 11 21:25:52 2012 From: meirea at charterschoolit.com (Mario Eirea) Date: Mon, 12 Mar 2012 02:25:52 +0000 Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: References: Message-ID: It has been my personal experience that when UVerse enters an area, traditional DSL has disappears. There are locations where we have ONUs in the building with available DSL circuits and they refuse to sell it to us. On another note, they sometimes try to offer us a 768k connection in a place where we currently have 6mb DSL service. One more thing, once you get UVerse, you have to forfeit your traditional DSL. Apparently, the two services cannot coexist (some billing program issue), what makes it worse, if you suddenly realize your 6Mb was replaced with a 768k UVerse, there's no going back. If you can avoid the ATT hassle. Try looking into wireless providers. WiMax has come to the rescue many times when the Cable and Telco companies have not been able to provide us with the service at the price point we were looking for. -Mario Eirea On Mar 10, 2012, at 9:03 PM, "chris" wrote: > Hi, > > I am trying to look into dsl in the RDU area and at&t customer service has > been exceedingly unhelpful only telling me "no service available, we have > no idea when services will become available, check back periodically". > I would atleast like to get an answer that theres no available capacity, > its over the 18k limit of dsl, or some other logical answer. Is there > anyone at bellsouth/att or one of their clec's who can help me do some > qual's and hopefully also help get this delivered? > > i did some lookups on known pots in the area and came up with: > LATA426 > NameR ALEIGH N CAROLINA > Historical Region BellSouth > Area Codes in LATA 919 > Carrier > Common Name AT&T Southeast > OCN 9417 > OCN Type RBOC > Name Bellsouth Telecomm Inc dba Southern Bell Telephone & Telegraph > Abbreviation BELLSOUTH SO BELL > DBA Southern Bell Telephone & Telegraph > FKA Southern Bell Telephone & Telegraph > > > so im pretty sure im contacting the right telco just surprised that their > customer service is offering pots but says no internet available, wtf? > > thanks for any info you can provide, > chris From faisal at snappydsl.net Sun Mar 11 22:03:05 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sun, 11 Mar 2012 23:03:05 -0400 Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: References: Message-ID: <4F5D6769.9040604@snappydsl.net> my comments below:- Faisal Imtiaz Snappy Internet& Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 3/11/2012 10:25 PM, Mario Eirea wrote: > It has been my personal experience that when UVerse enters an area, traditional DSL has disappears. Yes, that is true, AT&T would mark an area as not qualifying for DSL if there was Uverse in the Area, but this practice has been in-consistent. > There are locations where we have ONUs in the building with available DSL circuits and they refuse to sell it to us. Yes, we have seen that too, not sure what is the official reason, but in system show the Remote DSLAM being out of capacity. :) > On another note, they sometimes try to offer us a 768k connection in a place where we currently have 6mb DSL service. There has to be more context to this... a lot of DSLAM they are or have quietly turned down backhaul capacity, as such new circuits are only for lower speeds. > One more thing, once you get UVerse, you have to forfeit your traditional DSL. Apparently, the two services cannot coexist (some billing program issue), Yes that is correct ... > what makes it worse, if you suddenly realize your 6Mb was replaced with a 768k UVerse, there's no going back. That does not make sense... there is no such thing as 768K Uverse... (Uverse starts at 3meg down, 768K down is called DSL Lite.. ) > If you can avoid the ATT hassle. Try looking into wireless providers. Agreed... > WiMax has come to the rescue many times when the Cable and Telco companies have not been able to provide us with the service at the price point we were looking for. Agreed.. > > -Mario Eirea > > On Mar 10, 2012, at 9:03 PM, "chris" wrote: > >> Hi, >> >> I am trying to look into dsl in the RDU area and at&t customer service has >> been exceedingly unhelpful only telling me "no service available, we have >> no idea when services will become available, check back periodically". >> I would atleast like to get an answer that theres no available capacity, >> its over the 18k limit of dsl, or some other logical answer. Is there >> anyone at bellsouth/att or one of their clec's who can help me do some >> qual's and hopefully also help get this delivered? >> >> i did some lookups on known pots in the area and came up with: >> LATA426 >> NameR ALEIGH N CAROLINA >> Historical Region BellSouth >> Area Codes in LATA 919 >> Carrier >> Common Name AT&T Southeast >> OCN 9417 >> OCN Type RBOC >> Name Bellsouth Telecomm Inc dba Southern Bell Telephone& Telegraph >> Abbreviation BELLSOUTH SO BELL >> DBA Southern Bell Telephone& Telegraph >> FKA Southern Bell Telephone& Telegraph >> >> >> so im pretty sure im contacting the right telco just surprised that their >> customer service is offering pots but says no internet available, wtf? >> >> thanks for any info you can provide, >> chris > From tknchris at gmail.com Sun Mar 11 23:19:23 2012 From: tknchris at gmail.com (chris) Date: Mon, 12 Mar 2012 00:19:23 -0400 Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: <008d01ccfffd$78d75b10$6a861130$@net> References: <0d8d01ccffcd$12caf050$3860d0f0$@iname.com> <008d01ccfffd$78d75b10$6a861130$@net> Message-ID: 919 is in fact the area I'm looking at. so far i've put together: select areas can get att dsl up to 3mbit but its rare select areas have uverse select areas have centurylink(couldnt believe this but verified it from a friend in cary, nc) twc cable has good coverage over most of the area all in all what a horrible lack of options really. i just started looking into time warner, looks like they have some kind of wholesale offering: http://wholesalecarrierservice.com/ crossing my fingers that the twc wholesale will fit my needs but not holding my breath i thank everyone for all their replies to this thread, there has been an abundance of great information. chris On Sun, Mar 11, 2012 at 11:08 PM, LQ Marshall wrote: > There are a number of COs in RDU area and especially 919 area code which > are > reportedly at capacity. There has been little or no movement in upgrade > "plans" at these locations (over years). Depending on which CO you are > coming out of and your budget there are other options. > > FIOS is very rare in the 919 area as most of it (all?) is Bell South/ATT. > U-Verse has limited coverage in the area. IMOHO if you're looking for the > sub $100 solution TWC is the way to go. > > gl > > -----Original Message----- > From: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Sunday, March 11, 2012 5:23 PM > To: 'chris' > Cc: NANOG list > Subject: RE: BellSouth (att?) with a clue in Raleigh, NC > > Verizon is FiOS, AT&T has U-verse which is FTTC. > > Frank > > -----Original Message----- > From: chris [mailto:tknchris at gmail.com] > Sent: Saturday, March 10, 2012 8:34 PM > To: Faisal Imtiaz > Cc: NANOG list > Subject: Re: BellSouth (att?) with a clue in Raleigh, NC > > Looks like no dice on uverse, says its not available. i thought uverse was > fios though atleast that was my understanding. now im even more confused, > how can att/bellsouth be the ILEC and have zero internet options at all but > be offering pots? Only logical thing I can think of is distance from the CO > making dsl a no-go but i cant get an actual qual to atleast confirm that :( > > On Sat, Mar 10, 2012 at 9:23 PM, Faisal Imtiaz > wrote: > > > Google for their Uverse site and check if u can get it... They will do > > Uverse (Internet only). Only if u order online.... > > > > Faisal > > > > Sent from my iPhone > > > > On Mar 10, 2012, at 9:02 PM, chris wrote: > > > > > Hi, > > > > > > I am trying to look into dsl in the RDU area and at&t customer > > > service > > has > > > been exceedingly unhelpful only telling me "no service available, we > have > > > no idea when services will become available, check back periodically". > > > I would atleast like to get an answer that theres no available > > > capacity, its over the 18k limit of dsl, or some other logical > > > answer. Is there anyone at bellsouth/att or one of their clec's who > > > can help me do some qual's and hopefully also help get this delivered? > > > > > > i did some lookups on known pots in the area and came up with: > > > LATA426 > > > NameR ALEIGH N CAROLINA > > > Historical Region BellSouth > > > Area Codes in LATA 919 > > > Carrier > > > Common Name AT&T Southeast > > > OCN 9417 > > > OCN Type RBOC > > > Name Bellsouth Telecomm Inc dba Southern Bell Telephone & Telegraph > > > Abbreviation BELLSOUTH SO BELL DBA Southern Bell Telephone & > > > Telegraph FKA Southern Bell Telephone & Telegraph > > > > > > > > > so im pretty sure im contacting the right telco just surprised that > their > > > customer service is offering pots but says no internet available, wtf? > > > > > > thanks for any info you can provide, chris > > > > > > > From meirea at charterschoolit.com Sun Mar 11 23:51:43 2012 From: meirea at charterschoolit.com (Mario Eirea) Date: Mon, 12 Mar 2012 04:51:43 +0000 Subject: BellSouth (att?) with a clue in Raleigh, NC In-Reply-To: <4F5D6769.9040604@snappydsl.net> References: <4F5D6769.9040604@snappydsl.net> Message-ID: On 3/11/2012 10:25 PM, Mario Eirea wrote: > It has been my personal experience that when UVerse enters an area, traditional DSL has disappears. Yes, that is true, AT&T would mark an area as not qualifying for DSL if there was Uverse in the Area, but this practice has been in-consistent. > There are locations where we have ONUs in the building with available DSL circuits and they refuse to sell it to us. Yes, we have seen that too, not sure what is the official reason, but in system show the Remote DSLAM being out of capacity. :) I'm sure this is true, I know we have requested service disconnections more than once in the past and have had the account closed, but DSL has remained on the line. Plug in a modem and you get sync, type in a user and password for another site and you are surfing... I hope they don't make it a habit of leaving circuits up for non paying customers. That a lot of unused service going to waste. > On another note, they sometimes try to offer us a 768k connection in a place where we currently have 6mb DSL service. There has to be more context to this... a lot of DSLAM they are or have quietly turned down backhaul capacity, as such new circuits are only for lower speeds. > One more thing, once you get UVerse, you have to forfeit your > traditional DSL. Apparently, the two services cannot coexist (some > billing program issue), Yes that is correct ... > what makes it worse, if you suddenly realize your 6Mb was replaced with a 768k UVerse, there's no going back. That does not make sense... there is no such thing as 768K Uverse... (Uverse starts at 3meg down, 768K down is called DSL Lite.. ) That's what I thought, but not the case. This is especially prevalent in the South Miami area. One think I know is that the service was labeled "UVerse" not "Fast Access DSL", however, I cannot tell you if the underlying technology is ADSL or VDSL2 (we went running to the hills after 768k). The justification they gave us for the lower speeds on the "UVerse" service was that they were in the process of transitioning their existing DSL service to UVerse, and until that was complete, the backhaul capacity was not going to be available. I still don't believe this... Does not make any sense to me that they would have to wait for everyone on their old service to switch to UVerse before they make the bandwidth available. Its ATT, I have a real hard time cutting though all the layers of junk before you get to someone that actually tells you the truth or knows what's going on. > If you can avoid the ATT hassle. Try looking into wireless providers. Agreed... > WiMax has come to the rescue many times when the Cable and Telco companies have not been able to provide us with the service at the price point we were looking for. Agreed.. > > -Mario Eirea > > On Mar 10, 2012, at 9:03 PM, "chris" wrote: > >> Hi, >> >> I am trying to look into dsl in the RDU area and at&t customer >> service has been exceedingly unhelpful only telling me "no service >> available, we have no idea when services will become available, check back periodically". >> I would atleast like to get an answer that theres no available >> capacity, its over the 18k limit of dsl, or some other logical >> answer. Is there anyone at bellsouth/att or one of their clec's who >> can help me do some qual's and hopefully also help get this delivered? >> >> i did some lookups on known pots in the area and came up with: >> LATA426 >> NameR ALEIGH N CAROLINA >> Historical Region BellSouth >> Area Codes in LATA 919 >> Carrier >> Common Name AT&T Southeast >> OCN 9417 >> OCN Type RBOC >> Name Bellsouth Telecomm Inc dba Southern Bell Telephone& Telegraph >> Abbreviation BELLSOUTH SO BELL DBA Southern Bell Telephone& >> Telegraph FKA Southern Bell Telephone& Telegraph >> >> >> so im pretty sure im contacting the right telco just surprised that >> their customer service is offering pots but says no internet available, wtf? >> >> thanks for any info you can provide, >> chris > From mukom.tamon at gmail.com Mon Mar 12 00:47:45 2012 From: mukom.tamon at gmail.com (Mukom Akong T.) Date: Mon, 12 Mar 2012 09:47:45 +0400 Subject: filtering /48 is going to be necessary In-Reply-To: References: Message-ID: On Fri, Mar 9, 2012 at 11:27 PM, Owen DeLong wrote: >> >> 1) absolutely must drop /48 de-aggregates from ISP blocks >> 2) absolutely must make RIR policy so orgs can get /48s for >> anycasting, and whatever other purposes >> > > Item 1 will be interesting. > Item 2 is already done in ARIN and I think RIPE and APNIC. > I'm not sure about AfriNIC or LACNIC. AfriNC already does so. See http://www.afrinic.net/docs/policies/AFPUB-2007-v6-001.htm -- Mukom Akong [Tamon] ______________ ?We don't LIVE in order to BREATH. Similarly WORKING in order to make MONEY puts us on a one way street to irrelevance.? [In Search of Excellence & Perfection] - http://perfexcellence.org [Moments of TechXcellence] - http://techexcellence.net [ICT Business Integration] -?http://ibiztech.wordpress.com [About Me] - http://about.me/perfexcellence From mohta at necom830.hpcl.titech.ac.jp Mon Mar 12 01:17:46 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 12 Mar 2012 15:17:46 +0900 Subject: filtering /48 is going to be necessary In-Reply-To: References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> Message-ID: <4F5D950A.8030703@necom830.hpcl.titech.ac.jp> William Herrin wrote: > C) Big iron is either using massively parallel FIBs (many copies of > the radix tree) or they're using TCAM instead of DRAM, a specialized > tristate version of SRAM. In either case, you're talking 10 to 100 > times the cost, ten times the power consumption and ten times the heat > versus DRAM. TCAM is a specialized version of CAM. CAM is much worse than SRAM. > A router handling 10M routes is achievable today if we're willing to > go back to $20k as the minimum cost BGP box. That's an order of > magnitude more than we have now and three orders of magnitude short of > where we need to be before we can stop sweating the prefix count. For 16M routes, we only need /24. With /24 aggregation, route look up is trivially easy with a 16M entry single chip SRAM every 3ns consuming 1W. That's why IPv4 or original IPv6 proposal with 8B address is much better than the current IPv6. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Mon Mar 12 02:19:23 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 12 Mar 2012 16:19:23 +0900 Subject: filtering /48 is going to be necessary In-Reply-To: <4F5CF9D5.9050601@bogus.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> Message-ID: <4F5DA37B.6050403@necom830.hpcl.titech.ac.jp> Joel jaeggli wrote: > That's a fairly simplistic version of why shim6 failed. A better reason > (appart from the fact the building an upper layer overlay of the whole > internet on an ip protocol that's largely unedeployed was hard) is that Shim6 failed mostly because of its complexity. It is complex mostly because its architecture is broken, trying to hide existence of shim6 from applications (the end systems within end hosts), which is against the end to end principle and impossible, only to make application modifications even more complicated. Other added features makes shim6 even worse. > it leaves the destination unable to perform traffic engineering. That > fundementaly is the business we're in when advertising prefixes to more > than one provider, ingress path selection. That's not a inherent problem of architectures with multiple addresses. Destination hosts can listen to advertisements of destination network administrators and suggest source hosts which prefixes are preferred by the administrators. That is the end to end way of destination traffic engineering without bloating routing table entries. Masataka Ohta From elmi at 4ever.de Mon Mar 12 03:25:32 2012 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 12 Mar 2012 09:25:32 +0100 Subject: Questions about anycasting setup In-Reply-To: <2763367C-26BA-4330-812E-C5898E154D14@gibbard.org> References: <20120309081131.GC17726@h.detebe.org> <4F59C701.3090503@altadena.net> <2763367C-26BA-4330-812E-C5898E154D14@gibbard.org> Message-ID: <20120312082532.GD17726@h.detebe.org> Morn' Steve, scg at gibbard.org (Steve Gibbard) wrote: > I have no idea what Cisco equipment Elmar is using, but I wouldn't jump to the conclusion that it can't withdraw routes when needed. We use scripts external to both the routing platform and the service delivery platform to check the service and reconfigure L3 equipment (which is all kinds of L3 capable hardware). Elmar. From me at anuragbhatia.com Mon Mar 12 04:09:11 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 12 Mar 2012 14:39:11 +0530 Subject: Concern about gTLD servers in India In-Reply-To: <1FEB0783-9C97-4C7E-A3FC-274BDEAEB31B@isc.org> References: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> <72442ECD-AD48-4CD3-8DC6-947C9007EB65@isc.org> <1FEB0783-9C97-4C7E-A3FC-274BDEAEB31B@isc.org> Message-ID: Just looked at j root in detail. Unfortunately not much of traffic is going to J root. BSNL along with its main upstream providers Tata & Airtel - all picking outside routes. Tata AS4755 is taking directly to AS6453 while AS6453 is passing to NTT in London which is next taking back to Japan and then going to HK anycasted node (yeah head shake routing!). Here's a view: traceroute to j.gtld-servers.net (192.48.79.30), 30 hops max, 60 byte packets 1 router.local (192.168.1.1) [AS8151/AS28513] 1.180 ms 1.621 ms 2.121 ms 2 117.207.48.1 (117.207.48.1) [AS9829] 26.935 ms 29.328 ms 31.956 ms 3 218.248.173.46 (218.248.173.46) [AS9829] 34.393 ms 37.093 ms * 4 115.114.57.165.static-Mumbai.vsnl.net.in (115.114.57.165) [AS4755] 74.623 ms 78.281 ms 82.352 ms 5 if-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) [*] 299.987 ms 300.397 ms 314.175 ms 6 if-6-2.tcore1.L78-London.as6453.net (80.231.130.5) [AS6453] 314.573 ms 264.576 ms 261.030 ms 7 Vlan704.icore1.LDN-London.as6453.net (80.231.130.10) [AS6453] 279.896 ms 280.312 ms * 8 Vlan522.icore1.LDN-London.as6453.net (195.219.83.22) [AS6453] 333.651 ms 326.233 ms 330.307 ms 9 ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) [AS2914] 323.084 ms 324.204 ms 329.300 ms 10 as-0.r22.osakjp01.jp.bb.gin.ntt.net (129.250.5.35) [AS2914] 457.845 ms 459.011 ms 456.842 ms 11 as-0.r20.newthk02.hk.bb.gin.ntt.net (129.250.2.7) [AS2914] 495.869 ms 495.615 ms 496.840 ms 12 ae-1.r02.chwahk02.hk.bb.gin.ntt.net (129.250.3.131) [AS2914] 476.471 ms 478.525 ms 478.104 ms 13 * * * 14 * * * 15 * * * *Router:* gin-mlv-core1 *Site:* IN, Mumbai - MLV, VSNL *Command:* show ip bgp 192.48.79.30 BGP routing table entry for *192.48.79.0/24* Bestpath Modifiers: deterministic-med Paths: (3 available, best #2) Multipath: eBGP 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from mlv-tcore1. (66.110.10.202) Origin IGP, valid, internal Community: Originator: ldn-icore1. 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from cxr-tcore1. (66.110.10.113) Origin IGP, valid, internal, best Community: Originator: ldn-icore1. 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from mlv-tcore2. (66.110.10.215) Origin IGP, valid, internal Community: Originator: ldn-icore1. Path via NTT in all cases. So Mumbai - London - Japan - HongKong. Very likely because of same old problem I mentioned - Tata peers with NTT in London but not Japan. anurag at laptop:~$ dig j.gtld-servers.net a +short 192.48.79.30 anurag at laptop:~$ awhois 192.48.79.30 AS | IP | BGP Prefix | CC | AS Name 36631 | 192.48.79.30 | 192.48.79.0/24 | US | ZGTLD - VeriSign Global Registry Services http://bgp.he.net/AS36631#_peers And situation for Airtel isn't better at all for J root. Instead of picking NTT, they are using Packnet/AsiaNetcom because Packnet is likely a client of Hurricane Electric and Airtel peers with HE. Mon Mar 12 14:22:49 GMT+05:30 2012 traceroute 192.48.79.30 Type escape sequence to abort. Tracing the route to j.gtld-servers.net (192.48.79.30) 1 59.145.6.149 [MPLS: Label 800 Exp 0] 288 msec 59.145.6.145 [MPLS: Label 800 Exp 0] 284 msec 59.145.0.181 [MPLS: Label 1668 Exp 0] 260 msec 2 202.56.223.50 [MPLS: Label 308480 Exp 0] 256 msec 256 msec 202.56.223.205 [MPLS: Label 311696 Exp 0] 276 msec 3 182.79.220.198 [MPLS: Label 1795 Exp 0] 276 msec 276 msec 182.79.252.161 [MPLS: Label 1795 Exp 0] 272 msec 4 AES-Static-122.36.144.59.airtel.in (59.144.36.122) 272 msec 272 msec 288 msec 5 he.net.coresite.com (206.223.143.122) 288 msec 292 msec 272 msec 6 10gigabitethernet2-1.core1.lax1.he.net (72.52.92.121) [AS 6939] 272 msec 276 msec 288 msec 7 pacnet.10gigabitethernet2-3.core1.lax1.he.net (216.218.223.206) [AS 6939] 288 msec 288 msec 272 msec 8 te0-1-0-0.wr1.nrt0.asianetcom.net (61.14.157.89) [AS 10026] 264 msec 264 msec 284 msec 9 te0-0-4-0.wr2.nrt0.asianetcom.net (61.14.157.14) [AS 10026] [MPLS: Label 16191 Exp 0] 288 msec 292 msec 276 msec 10 te0-0-0-0.wr2.osa0.asianetcom.net (61.14.157.2) [AS 10026] [MPLS: Label 16002 Exp 0] 276 msec 300 msec 292 msec 11 te0-0-4-0.wr1.osa0.asianetcom.net (61.14.157.21) [AS 10026] 292 msec 292 msec 276 msec 12 te0-1-0-0.wr1.hkg0.asianetcom.net (61.14.157.57) [AS 10026] 272 msec 268 msec 288 msec 13 ge-4-1-0-0.cr4.hkg3.asianetcom.net (61.14.157.142) [AS 10026] 284 msec 288 msec 264 msec 14 te3-2.gw1.hkg4.asianetcom.net (202.147.16.198) [AS 10026] 336 msec 264 msec 284 msec 15 VNB-0025.gw1.hkg4.asianetcom.net (203.192.137.78) [AS 10026] 284 msec 288 msec 268 msec 16 * * * Same problem applies on J gTLD server too. It might be having an instance in India but since no link to local ISPs or niXi...everyone hears J root in Hong Kong. Anyone from Verisign or Indian ISPs here for onlist or offlist comments? Again, I apologize for any wrong conclusions. I am still learning all this stuff. Please excuse my ignorance and correct me if you find something. Thanks On Sun, Mar 11, 2012 at 4:57 PM, Peter Losher wrote: > On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote: > > > Btw coming back to original question - can you put some light on gTLDs > in India? Are there any instances? Just to clarify - with gTLD I am > refering to .com/net/org primarily. > > You would have to ask Verisign as operators of the com/net gTLD servers > and Afilias for .org about their DNS deployments. I can only speak for ISC > as we operate F.ROOT-SERVERS.NET. > > Best Wishes - Peter > -- > [ plosher at isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From chcheng at ieee.org Mon Mar 12 04:45:02 2012 From: chcheng at ieee.org (Che-Hoo CHENG) Date: Mon, 12 Mar 2012 17:45:02 +0800 Subject: [apnic-talk] Concern about gTLD servers in India In-Reply-To: References: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> <72442ECD-AD48-4CD3-8DC6-947C9007EB65@isc.org> <1FEB0783-9C97-4C7E-A3FC-274BDEAEB31B@isc.org> Message-ID: <7B0A3622-87CF-4C36-8956-F448DCC9D501@ieee.org> J root should be j.root-servers.net (192.58.128.30). Che-Hoo On 12 Mar, 2012, at 5:09 PM, Anurag Bhatia wrote: > Just looked at j root in detail. > > > Unfortunately not much of traffic is going to J root. BSNL along with its main upstream providers Tata & Airtel - all picking outside routes. Tata AS4755 is taking directly to AS6453 while AS6453 is passing to NTT in London which is next taking back to Japan and then going to HK anycasted node (yeah head shake routing!). > > > Here's a view: > > traceroute to j.gtld-servers.net (192.48.79.30), 30 hops max, 60 byte packets > 1 router.local (192.168.1.1) [AS8151/AS28513] 1.180 ms 1.621 ms 2.121 ms > 2 117.207.48.1 (117.207.48.1) [AS9829] 26.935 ms 29.328 ms 31.956 ms > 3 218.248.173.46 (218.248.173.46) [AS9829] 34.393 ms 37.093 ms * > 4 115.114.57.165.static-Mumbai.vsnl.net.in (115.114.57.165) [AS4755] 74.623 ms 78.281 ms 82.352 ms > 5 if-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) [*] 299.987 ms 300.397 ms 314.175 ms > 6 if-6-2.tcore1.L78-London.as6453.net (80.231.130.5) [AS6453] 314.573 ms 264.576 ms 261.030 ms > 7 Vlan704.icore1.LDN-London.as6453.net (80.231.130.10) [AS6453] 279.896 ms 280.312 ms * > 8 Vlan522.icore1.LDN-London.as6453.net (195.219.83.22) [AS6453] 333.651 ms 326.233 ms 330.307 ms > 9 ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) [AS2914] 323.084 ms 324.204 ms 329.300 ms > 10 as-0.r22.osakjp01.jp.bb.gin.ntt.net (129.250.5.35) [AS2914] 457.845 ms 459.011 ms 456.842 ms > 11 as-0.r20.newthk02.hk.bb.gin.ntt.net (129.250.2.7) [AS2914] 495.869 ms 495.615 ms 496.840 ms > 12 ae-1.r02.chwahk02.hk.bb.gin.ntt.net (129.250.3.131) [AS2914] 476.471 ms 478.525 ms 478.104 ms > 13 * * * > 14 * * * > 15 * * * > > > > > Router: gin-mlv-core1 > Site: IN, Mumbai - MLV, VSNL > Command: show ip bgp 192.48.79.30 > > > BGP routing table entry for 192.48.79.0/24 > Bestpath Modifiers: deterministic-med > Paths: (3 available, best #2) > Multipath: eBGP > 2914 36631 36631, (aggregated by 36631 203.131.245.40) > ldn-icore1. (metric 2991) from mlv-tcore1. (66.110.10.202) > Origin IGP, valid, internal > Community: > Originator: ldn-icore1. > 2914 36631 36631, (aggregated by 36631 203.131.245.40) > ldn-icore1. (metric 2991) from cxr-tcore1. (66.110.10.113) > Origin IGP, valid, internal, best > Community: > Originator: ldn-icore1. > 2914 36631 36631, (aggregated by 36631 203.131.245.40) > ldn-icore1. (metric 2991) from mlv-tcore2. (66.110.10.215) > Origin IGP, valid, internal > Community: > Originator: ldn-icore1. > > > Path via NTT in all cases. > > So Mumbai - London - Japan - HongKong. Very likely because of same old problem I mentioned - Tata peers with NTT in London but not Japan. > > anurag at laptop:~$ dig j.gtld-servers.net a +short > 192.48.79.30 > > > anurag at laptop:~$ awhois 192.48.79.30 > AS | IP | BGP Prefix | CC | AS Name > 36631 | 192.48.79.30 | 192.48.79.0/24 | US | ZGTLD - VeriSign Global Registry Services > > > http://bgp.he.net/AS36631#_peers > > > > > And situation for Airtel isn't better at all for J root. Instead of picking NTT, they are using Packnet/AsiaNetcom because Packnet is likely a client of Hurricane Electric and Airtel peers with HE. > > Mon Mar 12 14:22:49 GMT+05:30 2012 > traceroute 192.48.79.30 > > Type escape sequence to abort. > Tracing the route to j.gtld-servers.net (192.48.79.30) > > 1 59.145.6.149 [MPLS: Label 800 Exp 0] 288 msec > 59.145.6.145 [MPLS: Label 800 Exp 0] 284 msec > 59.145.0.181 [MPLS: Label 1668 Exp 0] 260 msec > 2 202.56.223.50 [MPLS: Label 308480 Exp 0] 256 msec 256 msec > 202.56.223.205 [MPLS: Label 311696 Exp 0] 276 msec > 3 182.79.220.198 [MPLS: Label 1795 Exp 0] 276 msec 276 msec > 182.79.252.161 [MPLS: Label 1795 Exp 0] 272 msec > 4 AES-Static-122.36.144.59.airtel.in (59.144.36.122) 272 msec 272 msec 288 msec > 5 he.net.coresite.com (206.223.143.122) 288 msec 292 msec 272 msec > 6 10gigabitethernet2-1.core1.lax1.he.net (72.52.92.121) [AS 6939] 272 msec 276 msec 288 msec > 7 pacnet.10gigabitethernet2-3.core1.lax1.he.net (216.218.223.206) [AS 6939] 288 msec 288 msec 272 msec > 8 te0-1-0-0.wr1.nrt0.asianetcom.net (61.14.157.89) [AS 10026] 264 msec 264 msec 284 msec > 9 te0-0-4-0.wr2.nrt0.asianetcom.net (61.14.157.14) [AS 10026] [MPLS: Label 16191 Exp 0] 288 msec 292 msec 276 msec > 10 te0-0-0-0.wr2.osa0.asianetcom.net (61.14.157.2) [AS 10026] [MPLS: Label 16002 Exp 0] 276 msec 300 msec 292 msec > 11 te0-0-4-0.wr1.osa0.asianetcom.net (61.14.157.21) [AS 10026] 292 msec 292 msec 276 msec > 12 te0-1-0-0.wr1.hkg0.asianetcom.net (61.14.157.57) [AS 10026] 272 msec 268 msec 288 msec > 13 ge-4-1-0-0.cr4.hkg3.asianetcom.net (61.14.157.142) [AS 10026] 284 msec 288 msec 264 msec > 14 te3-2.gw1.hkg4.asianetcom.net (202.147.16.198) [AS 10026] 336 msec 264 msec 284 msec > 15 VNB-0025.gw1.hkg4.asianetcom.net (203.192.137.78) [AS 10026] 284 msec 288 msec 268 msec > 16 * * * > > > > Same problem applies on J gTLD server too. It might be having an instance in India but since no link to local ISPs or niXi...everyone hears J root in Hong Kong. > > > > Anyone from Verisign or Indian ISPs here for onlist or offlist comments? > > Again, I apologize for any wrong conclusions. I am still learning all this stuff. Please excuse my ignorance and correct me if you find something. > > > Thanks > > On Sun, Mar 11, 2012 at 4:57 PM, Peter Losher wrote: > On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote: > > > Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily. > > You would have to ask Verisign as operators of the com/net gTLD servers and Afilias for .org about their DNS deployments. I can only speak for ISC as we operate F.ROOT-SERVERS.NET. > > Best Wishes - Peter > -- > [ plosher at isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] > > > > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com > > _______________________________________________ > apnic-talk mailing list > apnic-talk at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-talk From rs at seastrom.com Mon Mar 12 10:07:54 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 12 Mar 2012 11:07:54 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F5D465A.2060301@dougbarton.us> (Doug Barton's message of "Sun, 11 Mar 2012 17:42:02 -0700") References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> Message-ID: <86k42prh6d.fsf@seastrom.com> Doug Barton writes: > On 3/11/2012 3:15 PM, Iljitsch van Beijnum wrote: >> But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI after a decade > > Because as far back as 2003 ARIN members (and members from all the other > RIRs for that matter) were saying in very clear terms that PI space was > a requirement for moving to v6. No one wanted to lose the provider > independence that they had gained with v4. Without that, v6 was a total > non-starter. > > ARIN was simply listening to its members. It didn't help that there was initially no implementation of shim6 whatsoever. That later turned into a single prototype implementation of shim6 for linux. As much as I tried to keep an open mind about shim6, eventually it became clear that this was a Gedankenexperiment in protocol design. Somewhere along the line I started publicly referring to it as "sham6". I'm sure I'm not the only person who came to that conclusion. Grass-roots, bottom-up policy process + Need for multihoming + Got tired of waiting = IPv6 PI -r From jared at puck.nether.net Mon Mar 12 10:18:54 2012 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 12 Mar 2012 11:18:54 -0400 Subject: filtering /48 is going to be necessary In-Reply-To: References: <70180960-F3F6-40B6-97D5-1763D16DF42F@steffann.nl> <41F6C547EA49EC46B4EE1EB2BC2F34184ABD176F30@EXVPMBX100-1.exc.icann.org> <4F5AE797.6010702@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C880@RWC-MBX1.corp.seven.com> <4F5AF56D.4010902@bogus.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D0C907@RWC-MBX1.corp.seven.com> Message-ID: <122CB721-C9FE-4E96-B76D-B29EE3F2C6E5@puck.nether.net> The big issue is not the control plane but forwarding plane memory. SRAM is hot and expensive. Jared Mauch On Mar 10, 2012, at 5:50 PM, Sven Olaf Kamphuis wrote: > you did buy a new iphone i bet.. why no modern routers. From leigh.porter at ukbroadband.com Mon Mar 12 10:21:57 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 12 Mar 2012 15:21:57 +0000 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <86k42prh6d.fsf@seastrom.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> Message-ID: > > Grass-roots, bottom-up policy process > + > Need for multihoming > + > Got tired of waiting > = > IPv6 PI > > -r A perfect summation. Also given that people understand what PI space is and how it works and indeed it does pretty much just work for the end users of the space. -- Leigh Porter UK Broadband ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From seth.mos at dds.nl Mon Mar 12 10:23:25 2012 From: seth.mos at dds.nl (Seth Mos) Date: Mon, 12 Mar 2012 16:23:25 +0100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <86k42prh6d.fsf@seastrom.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> Message-ID: <4F5E14ED.8050808@dds.nl> On 12-3-2012 16:07, Robert E. Seastrom wrote: > > Doug Barton writes: > > Grass-roots, bottom-up policy process > + > Need for multihoming > + > Got tired of waiting > = > IPv6 PI + Cheap End Users = IPv6 NPt (IPv6 Prefix Translation) Cheers, Seth From bicknell at ufp.org Mon Mar 12 10:31:55 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 12 Mar 2012 08:31:55 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <86k42prh6d.fsf@seastrom.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> Message-ID: <20120312153155.GA85481@ussenterprise.ufp.org> In a message written on Mon, Mar 12, 2012 at 11:07:54AM -0400, Robert E. Seastrom wrote: > Grass-roots, bottom-up policy process > + > Need for multihoming > + > Got tired of waiting > = > IPv6 PI I'll also add that Shim6 folks never made a good economic argument. It's true that having routes in the DFZ costs money, and that reducing the number of routes will save the industry money in router upgrades and such to handle more routes. However, it's also true that deploying SHIM6 (or similar solutions) also has a cost in rewritten software, traning for network engineers and administrators, and so on. It was never clear to me that even if it worked 100% as advertised that it would be cheaper / better in the global sense. -- 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 iljitsch at muada.com Mon Mar 12 10:56:17 2012 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 12 Mar 2012 16:56:17 +0100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> Message-ID: On 12 Mar 2012, at 16:21 , Leigh Porter wrote: >> Grass-roots, bottom-up policy process >> + >> Need for multihoming >> + >> Got tired of waiting >> = >> IPv6 PI > A perfect summation. Except that it didn't happen in that order. When ARIN approved PI the shim6 effort was well underway, but it was too early to be able to know to what degree it would solve the multihoming problem. Earlier, when multi6 was stuck or later, when shim6, at least as a specification, but preferably as multiple implementations, could have been evaluated would both have been reasonable times to decide to go for PI instead. Of course as has been the case over and over the argument "if you give us feature X we'll implement IPv6" has never borne out. > Also given that people understand what PI space is and how it works and indeed it does pretty much just work for the end users of the space. The trouble is that it doesn't scale. Which is fine right now at the current IPv6 routing table size, but who knows what the next decades bring. We've been living with IPv4 for 30 years now, and IPv6 doesn't have a built-in 32-bit expiry date so it's almost certainly going to be around for much longer. From malayter at gmail.com Mon Mar 12 11:27:43 2012 From: malayter at gmail.com (Ryan Malayter) Date: Mon, 12 Mar 2012 09:27:43 -0700 (PDT) Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <86k42prh6d.fsf@seastrom.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> Message-ID: <7140c7c3-827e-4215-a77c-91fb458f4947@h20g2000yqd.googlegroups.com> On Mar 12, 10:07?am, "Robert E. Seastrom" wrote: > It didn't help that there was initially no implementation of shim6 > whatsoever. ?That later turned into a single prototype implementation > of shim6 for linux. ?As much as I tried to keep an open mind about > shim6, eventually it became clear that this was a Gedankenexperiment > in protocol design. ?Somewhere along the line I started publicly > referring to it as "sham6". ?I'm sure I'm not the only person who came > to that conclusion. > I thought the IETF required two inter-operable implementations for protocols. Or was that just for standards-track stuff? Anyway, the effort involved in getting Shim6 implemented globally on all devices would have been nearly as large as switching over all applications from TCP to a protocol with a "proper" session layer, like SCTP. I believe there are libraries that wrap SCTP and make it look like TCP to legacy applications; wouldn't that have been a better approach? From carlosm3011 at gmail.com Mon Mar 12 11:59:01 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Mon, 12 Mar 2012 13:59:01 -0300 Subject: Programmers with network engineering skills In-Reply-To: <201203081724.05236.lowen@pari.edu> References: <201203081724.05236.lowen@pari.edu> Message-ID: <4F5E2B55.20604@gmail.com> Hey! On 3/8/12 8:24 PM, Lamar Owen wrote: > On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote: > ... >> (16) The default gateway's IP address is always 192.168.0.1 >> (17) The user portion of E-mail addresses never contain special >> characters like "-" "+" "$" "~" "." ",", "[", "]" I've just had my ' xx AT cagnazzo.name' email address rejected by a web form saying that 'it is not a valid email address'. So I guess point (17) can be extended to say that 'no email address shall end in anything different that .com, .net or the local ccTLD' :=) Carlos From btalley at photobucket.com Mon Mar 12 12:10:07 2012 From: btalley at photobucket.com (Brian Talley) Date: Mon, 12 Mar 2012 11:10:07 -0600 Subject: Ciena CN4200 documentation Message-ID: Does anyone have a user manual and/or configuration guide for a Ciena CN4200? I tried contacting their technical publication phone number and email but never heard back. If anyone has anything that's more in-depth than marketing material, please contact me off-list. I'm primarily interested in how to troubleshoot "loss of frame" messages and what the front panel LED states mean, but anything will help. TIA, BT -- Brian Talley Network Engineer btalley at photobucket.com From owen at delong.com Mon Mar 12 12:09:20 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Mar 2012 10:09:20 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F5E14ED.8050808@dds.nl> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <4F5E14ED.8050808@dds.nl> Message-ID: <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> On Mar 12, 2012, at 8:23 AM, Seth Mos wrote: > On 12-3-2012 16:07, Robert E. Seastrom wrote: >> >> Doug Barton writes: >> > >> Grass-roots, bottom-up policy process >> + >> Need for multihoming >> + >> Got tired of waiting >> = >> IPv6 PI > > + > Cheap End Users > = > IPv6 NPt (IPv6 Prefix Translation) > > Cheers, > > Seth I don't get the association between cheap end users and NPT. Can you explain how one relates to the other, given the added costs of unnecessarily translating prefixes? Owen From owen at delong.com Mon Mar 12 12:16:28 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Mar 2012 10:16:28 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> Message-ID: <14551DBF-5ED2-4A2E-BB78-F496EBEC4016@delong.com> On Mar 12, 2012, at 8:56 AM, Iljitsch van Beijnum wrote: > On 12 Mar 2012, at 16:21 , Leigh Porter wrote: > >>> Grass-roots, bottom-up policy process >>> + >>> Need for multihoming >>> + >>> Got tired of waiting >>> = >>> IPv6 PI > >> A perfect summation. > > Except that it didn't happen in that order. When ARIN approved PI the shim6 effort was well underway, but it was too early to be able to know to what degree it would solve the multihoming problem. Earlier, when multi6 was stuck or later, when shim6, at least as a specification, but preferably as multiple implementations, could have been evaluated would both have been reasonable times to decide to go for PI instead. > > Of course as has been the case over and over the argument "if you give us feature X we'll implement IPv6" has never borne out. > Except it didn't happen that way. The argument wasn't "If you give us PI, we'll implement IPv6." The argument that carried the day and is, IMHO, quite valid was "If you don't give us PI we definitely WON'T implement IPv6." The inability to obtain PI was a serious detractor from IPv6 for any organization that already had IPv4 PI. Shim6 showed no promise whatsoever of changing this even in its most optimistic marketing predictions at the time. (As you point out, it was well underway at that point and it's not as if we didn't look at it prior to drafting the policy proposal.) Frankly, I think the long term solution is to implement IDR based on Locators in the native packet header and not using map/encap schemes that reduce MTU, but that doesn't seem to be a popular idea so far. >> Also given that people understand what PI space is and how it works and indeed it does pretty much just work for the end users of the space. > > The trouble is that it doesn't scale. Which is fine right now at the current IPv6 routing table size, but who knows what the next decades bring. We've been living with IPv4 for 30 years now, and IPv6 doesn't have a built-in 32-bit expiry date so it's almost certainly going to be around for much longer. If IPv6 works out in the 1.6-2:1 prefix:ASN ratio that I expect or even as much as 4:1, we'll get at least another 30 years out of it. Since we've had IPv6 now for about 15 years, it's already half way through that original 30. :p Owen From darlewis at cisco.com Mon Mar 12 13:49:38 2012 From: darlewis at cisco.com (Darrel Lewis) Date: Mon, 12 Mar 2012 11:49:38 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> Message-ID: <428B5E69-15E7-437A-8430-A1724BBC361A@cisco.com> On Mar 11, 2012, at 3:15 PM, Iljitsch van Beijnum wrote: > On 11 Mar 2012, at 20:15 , Joel jaeggli wrote: > >>> The IETF and IRTF have looked at the routing scalability issue for a >>> long time. The IETF came up with shim6, which allows multihoming >>> without BGP. Unfortunately, ARIN started to allow IPv6 PI just in >>> time so nobody bothered to adopt shim6. > >> That's a fairly simplistic version of why shim6 failed. A better reason >> (appart from the fact the building an upper layer overlay of the whole >> internet on an ip protocol that's largely unedeployed was hard) is that >> it leaves the destination unable to perform traffic engineering. > > I'm not saying that shim6 would have otherwise ruled the world by now, it was always an uphill battle because it requires support on both sides of a communication session/association. > > But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI after a decade, just when the multi6/shim6 effort started to get going but before the work was complete enough to judge whether it would be good enough. > >> That fundementaly is the business we're in when advertising prefixes to more >> than one provider, ingress path selection. > > That's the business network operators are in. That's not the business end users who don't want to depend on a single ISP are in. Remember, shim6 was always meant as a solution that addresses the needs of a potential 1 billion "basement multihomers" with maybe ADSL + cable. The current 25k or so multihomers are irrelevant from the perspective of routing scalability. It's the other 999,975,000 that will kill the routing tables if multihoming becomes mainstream. When discussing 'why shim6 failed' I think its only fair to include a link to a (well reasoned, imho) network operator's perspective on what it did and did not provide in the way of capabilities that network operators desired. http://www.nanog.org/meetings/nanog35/abstracts.php?pt=NDQ3Jm5hbm9nMzU=&nm=nanog35 -Darrel From hrlinneweh at sbcglobal.net Mon Mar 12 13:53:13 2012 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Mon, 12 Mar 2012 11:53:13 -0700 (PDT) Subject: =?utf-8?B?VVMgd2l0aGRyYXdzIElBTkEgUkZQLCDigJhubyBzdWl0YWJsZSByZXNwb25z?= =?utf-8?B?ZXPigJk=?= Message-ID: <1331578393.47483.YahooMailNeo@web180308.mail.gq1.yahoo.com> http://www.theregister.co.uk/2012/03/11/icann_loses_one_horse_race/ -Henry From seth.mos at dds.nl Mon Mar 12 13:53:04 2012 From: seth.mos at dds.nl (Seth Mos) Date: Mon, 12 Mar 2012 19:53:04 +0100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <4F5E14ED.8050808@dds.nl> <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> Message-ID: <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl> Hi, Op 12 mrt 2012, om 18:09 heeft Owen DeLong het volgende geschreven: >> + >> Cheap End Users >> = >> IPv6 NPt (IPv6 Prefix Translation) >> >> Cheers, >> >> Seth > > I don't get the association between cheap end users and NPT. Can you explain how one relates to the other, given the added costs of unnecessarily translating prefixes? Well, to explain cheap here I would like to explain it as following: - The existing yumcha plastic soap box that you can buy at your local electronics store is powerful enough. About as fast in v6 as it does v4 since it is all software anyhow. It only gets faster from there. - Requires no cooperation from the ISP. This gets excessively worse where n > 1. Some have 8 or more for added bandwidth. - The excessive cost associated by current ISP practices that demand you use a business connection (at reduced bandwidth and increased cost). Somehow there was a decision that you can't have PI on "consumer" connections. - Traffic engineering is a cinch, since it is all controlled by the single box. For example round robin the connections for increased download speed. Similar to how we do it in v4 land. - It is mighty cheap to implement in current software, a number of Cisco and Jumiper releases support it. The various *bsd platforms do and linux is in development. - Not to underestimate the failover capabilities when almost all routers support 3G dongles for backup internet these days. There are considerable drawbacks ofcourse: - Rewriting prefixes breaks voip/ftp again although without the port rewriting the impact is less, but significant. I'd really wish that h323, ftp and voip would go away. Or other protocols the embed local IP information inside the datagram. But I digress. - People balk at the idea of NAT66, not to underestimate a very focal group here. All for solutions here. :-) - It requires keeping state, so no graceful failover. This means dropping sessions ofcourse but the people that want this likely won't care for the price they are paying. Probably missed a bunch of arguments the people will complain about. It is probably best explained in the current experimental draft for NPt. http://tools.ietf.org/html/rfc6296 Cheers, Seth From rs at seastrom.com Mon Mar 12 14:00:03 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 12 Mar 2012 15:00:03 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <7140c7c3-827e-4215-a77c-91fb458f4947@h20g2000yqd.googlegroups.com> (Ryan Malayter's message of "Mon, 12 Mar 2012 09:27:43 -0700 (PDT)") References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <7140c7c3-827e-4215-a77c-91fb458f4947@h20g2000yqd.googlegroups.com> Message-ID: <86ipi9d4r0.fsf@seastrom.com> Ryan Malayter writes: > On Mar 12, 10:07?am, "Robert E. Seastrom" wrote: >> It didn't help that there was initially no implementation of shim6 >> whatsoever. ?That later turned into a single prototype implementation >> of shim6 for linux. ?As much as I tried to keep an open mind about >> shim6, eventually it became clear that this was a Gedankenexperiment >> in protocol design. ?Somewhere along the line I started publicly >> referring to it as "sham6". ?I'm sure I'm not the only person who came >> to that conclusion. >> > > I thought the IETF required two inter-operable implementations for > protocols. Or was that just for standards-track stuff? Rough consensus and working code is soooooo 1993. -r From bill at herrin.us Mon Mar 12 14:07:12 2012 From: bill at herrin.us (William Herrin) Date: Mon, 12 Mar 2012 15:07:12 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <20120312153155.GA85481@ussenterprise.ufp.org> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> Message-ID: On Mon, Mar 12, 2012 at 11:31 AM, Leo Bicknell wrote: > In a message written on Mon, Mar 12, 2012 at 11:07:54AM -0400, Robert E. Seastrom wrote: >> Grass-roots, bottom-up policy process >> + >> Need for multihoming >> + >> Got tired of waiting >> = >> IPv6 PI > > It was never clear to me that even if it worked 100% as advertised that > it would be cheaper / better in the global sense. Hi Leo, When I ran the numbers a few years ago, a route had a global cost impact in the neighborhood of $8000/year. It's tough to make a case that folks who need multihoming's reliability can't afford to put that much into the system. As long as the system is largely restricted to folks who do put that much in, there's really no "problem" with the current flood-all-routers multihoming strategy: at $8k/year the demand will never again exceed the supply. A *working* multi-addressed end user system (like shim6 attempted) could solve cheap multihoming. That could have a billion dollar a year impact as folks at the leaf nodes decide they don't need the more costly BGP multihoming. But that's not where the real money is. Often overlooked is that multihoming through multi-addressing could solve IP mobility too. Provider-agnostic and media-agnostic mobility without levering off a "home" router. That's where the money is. Carry your voip call uninterrupted from your home wifi on the cable modem to your cell provider in the car to your employer's wired ethernet and back. Keep your SSH sessions alive on the notebook as you travel from home, to the airport, to London and to the hotel. Let folks access the web server on your notebook as it travels from home, to the airport, to Tokyo and back. The capability doesn't exist today. The potential economic impact of such a capability's creation is unbounded. Unfortunately, shim6 didn't work in some of the boundary cases. Since single-homing works pretty well in the ordinary case, there's not much point to a multihoming protocol that fails to deliver all the boundary cases. IIRC, the main problem was that they tried to bootstrap the layer 3 to layer 2 mapping function instead of externally requesting it. That's like trying to build ARP by making a unicast request to a local router instead of a broadcast/multicast request on the LAN. What happens when the local routers no longer have MAC addresses that you know about? Fail. Also, in complete fairness, shim6 suffered for the general lack of consumer interest in IPv6 that persists even today. It's proponents bought in to the hype that new work should focus on IPv6, and they paid for it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Mon Mar 12 14:30:32 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Mar 2012 12:30:32 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <4F5E14ED.8050808@dds.nl> <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl> Message-ID: On Mar 12, 2012, at 11:53 AM, Seth Mos wrote: > Hi, > > Op 12 mrt 2012, om 18:09 heeft Owen DeLong het volgende geschreven: > >>> + >>> Cheap End Users >>> = >>> IPv6 NPt (IPv6 Prefix Translation) >>> >>> Cheers, >>> >>> Seth >> >> I don't get the association between cheap end users and NPT. Can you explain how one relates to the other, given the added costs of unnecessarily translating prefixes? > > Well, to explain cheap here I would like to explain it as following: > > - The existing yumcha plastic soap box that you can buy at your local electronics store is powerful enough. About as fast in v6 as it does v4 since it is all software anyhow. It only gets faster from there. > Right. > - Requires no cooperation from the ISP. This gets excessively worse where n > 1. Some have 8 or more for added bandwidth. > This one doesn't really parse for me. I'm not sure I understand what you are saying. > - The excessive cost associated by current ISP practices that demand you use a business connection (at reduced bandwidth and increased cost). Somehow there was a decision that you can't have PI on "consumer" connections. > There's a big gap between PA without NPT and NPT, however. At the consumer level, I'd rather go PA than NPT. For a business, it's a different story, but, for a business, PI seems feasible and I would think that the business connection is sort of a given. > - Traffic engineering is a cinch, since it is all controlled by the single box. For example round robin the connections for increased download speed. Similar to how we do it in v4 land. > With all the same dysfunction. Further, in v4 land this depends a great deal on support built into applications and ALGs and a lot of other bloat and hacking to glue the broken little pieces back together and make it all work. I'm truly hoping that we can move away from that in IPv6. I'd really like to see application developers free to develop robust networking code in their applications instead of having to focus all their resources on dealing with the perils and pitfalls of NAT environments. > - It is mighty cheap to implement in current software, a number of Cisco and Jumiper releases support it. The various *bsd platforms do and linux is in development. Well, I guess that depends on how and where you measure cost. Sure, if you only count the cost of making the capability available in the feature set on the router, it's cheap and easy. If you count the cost and overhead of the application bloat and complexity and the support costs, the security costs, etc. it adds up pretty quickly. Sort of like it doesn't cost much to send spam, but, the cost of dealing with the never ending onslaught of unwanted email seems to go up every year. (Yes, I just compared people using NPT to spammers). > - Not to underestimate the failover capabilities when almost all routers support 3G dongles for backup internet these days. > If you care that much about failover, PI is a much better solution. I know my view is unpopular, but, I really would rather see PI made inexpensive and readily available than see NAT brought into the IPv6 mainstream. However, in my experience, very few residential customers make use of that 3G backup port. > There are considerable drawbacks ofcourse: > > - Rewriting prefixes breaks voip/ftp again although without the port rewriting the impact is less, but significant. I'd really wish that h323, ftp and voip would go away. Or other protocols the embed local IP information inside the datagram. But I digress. > Yep. > - People balk at the idea of NAT66, not to underestimate a very focal group here. All for solutions here. :-) > For good reason! > - It requires keeping state, so no graceful failover. This means dropping sessions ofcourse but the people that want this likely won't care for the price they are paying. > True. > Probably missed a bunch of arguments the people will complain about. It is probably best explained in the current experimental draft for NPt. > http://tools.ietf.org/html/rfc6296 More than likely. Hopefully we can stop trying so hard to break the internet and start working on ways to make it better soon. Owen From oscar.vives at gmail.com Mon Mar 12 14:46:52 2012 From: oscar.vives at gmail.com (Tei) Date: Mon, 12 Mar 2012 12:46:52 -0700 Subject: Programmers with network engineering skills In-Reply-To: <4F5E2B55.20604@gmail.com> References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> Message-ID: On 12 March 2012 09:59, Carlos Martinez-Cagnazzo wrote: > Hey! > > On 3/8/12 8:24 PM, Lamar Owen wrote: >> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote: >> ... >>> ? ?(16) ?The default gateway's IP address is always 192.168.0.1 >>> ? ?(17) The user portion of E-mail addresses never contain special >>> characters like ?"-" "+" ?"$" ? "~" ?"." ?",", "[", ?"]" > I've just had my ' xx AT cagnazzo.name' email address rejected by a web > form saying that 'it is not a valid email address'. So I guess point > (17) can be extended to say that 'no email address shall end in anything > different that .com, .net or the local ccTLD' > > :=) > > Carlos Yea, I don't even know how programmers can get that wrong. The regex is not even hard or anything. (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\]) -- -- ?in del ?ensaje. From tjc at ecs.soton.ac.uk Mon Mar 12 14:50:41 2012 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 12 Mar 2012 19:50:41 +0000 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <4F5E14ED.8050808@dds.nl> <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl> <3FA2D2CD-A31A-4D22-AF06-58C5DCDC126E@ecs.soton.ac.uk> Message-ID: On 12 Mar 2012, at 19:30, Owen DeLong wrote: > I know my view is unpopular, but, I really would rather see PI made inexpensive and readily available than see NAT brought into the IPv6 mainstream. However, in my experience, very few residential customers make use of that 3G backup port. So what assumptions do you think future IPv6-enabled homenets might make about the prefixes they receive or can use? Isn't having a PI per residential homenet rather unlikely? It would be desirable to avoid NPTv6 in the homenet scenario. Tim From myeaddress at gmail.com Mon Mar 12 15:05:19 2012 From: myeaddress at gmail.com (Maverick) Date: Mon, 12 Mar 2012 16:05:19 -0400 Subject: Whitelist of update servers Message-ID: Is there a whitelist that applications have to talk to in order to update themselves? From mdavids at forfun.net Mon Mar 12 15:06:10 2012 From: mdavids at forfun.net (Marco Davids (Prive)) Date: Mon, 12 Mar 2012 21:06:10 +0100 (CET) Subject: root zone stats In-Reply-To: <0da701ccffd1$019ff650$04dfe2f0$@iname.com> References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> <86haxw7jfh.fsf@seastrom.com> <4F5BE02F.60901@dougbarton.us> <0da701ccffd1$019ff650$04dfe2f0$@iname.com> Message-ID: On Sun, 11 Mar 2012, Frank Bulk wrote: > Some nice info here, too: http://bgp.he.net/report/dns Nice, but... not 100% up to date? .cw seems to be missing. -- Marco > > Frank > > -----Original Message----- > From: Doug Barton [mailto:dougb at dougbarton.us] > Sent: Saturday, March 10, 2012 5:14 PM > Cc: APNIC Mailing List; nanog at nanog.org > Subject: root zone stats > > Since there was a question about this, some numbers: > > Serial: 2012031001 > > Statistics > ========== > Number of root servers: 13 > Roots with IPv6 glue: 9 > > Number of gTLDs: 22 > Number of ccTLDs: 249 > Number of IDN TLDs: 42 > Total number of TLDs: 313 > > Number of IPv4 hosts: 1176 > Number of IPv4 addresses: 1145 > > Number of IPv6 hosts: 427 > Number of IPv6 addresses: 412 > TLDs with IPv6 glue: 258 > > Total name server hosts: 1177 > Total NS addresses: 1557 > > Number of DS records: 141 > Number of TLDs with DS: 85 > > > Enjoy, > > Doug > > -- > If you're never wrong, you're not trying hard enough > > > > > From owen at delong.com Mon Mar 12 15:04:40 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Mar 2012 13:04:40 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <4F5E14ED.8050808@dds.nl> <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl> <3FA2D2CD-A31A-4D22-AF06-58C5DCDC126E@ecs.soton.ac.uk> Message-ID: On Mar 12, 2012, at 12:50 PM, Tim Chown wrote: > > On 12 Mar 2012, at 19:30, Owen DeLong wrote: > >> I know my view is unpopular, but, I really would rather see PI made inexpensive and readily available than see NAT brought into the IPv6 mainstream. However, in my experience, very few residential customers make use of that 3G backup port. > > So what assumptions do you think future IPv6-enabled homenets might make about the prefixes they receive or can use? Isn't having a PI per residential homenet rather unlikely? > Yes, but, having reasonable and/or multiple PA prefixes is very likely and there is no reason not to use that instead of cobbled solutions based on NPT. > It would be desirable to avoid NPTv6 in the homenet scenario. > Very much so. (Or any other scenario I can think of as well). Owen From mdavids at forfun.net Mon Mar 12 15:10:27 2012 From: mdavids at forfun.net (Marco Davids (Prive)) Date: Mon, 12 Mar 2012 21:10:27 +0100 (CET) Subject: root zone stats In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> <86haxw7jfh.fsf@seastrom.com> <4F5BE02F.60901@dougbarton.us> <0da701ccffd1$019ff650$04dfe2f0$@iname.com> Message-ID: On Mon, 12 Mar 2012, Marco Davids (Prive) wrote: >> Some nice info here, too: http://bgp.he.net/report/dns > .cw seems to be missing. Oops, it isn't... it's just not wehere I expected it. -- Marco From brunner at nic-naa.net Mon Mar 12 15:14:52 2012 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 12 Mar 2012 16:14:52 -0400 Subject: US withdraws IANA RFP, =?UTF-8?B?4oCYbm8gc3VpdGFibGUgcmVzcG9u?= =?UTF-8?B?c2Vz4oCZ?= In-Reply-To: <1331578393.47483.YahooMailNeo@web180308.mail.gq1.yahoo.com> References: <1331578393.47483.YahooMailNeo@web180308.mail.gq1.yahoo.com> Message-ID: <4F5E593C.3080106@nic-naa.net> good head line copy edit. body lacks substance, though not attitude. -e From bill at herrin.us Mon Mar 12 15:15:38 2012 From: bill at herrin.us (William Herrin) Date: Mon, 12 Mar 2012 16:15:38 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <4F5E14ED.8050808@dds.nl> <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl> <3FA2D2CD-A31A-4D22-AF06-58C5DCDC126E@ecs.soton.ac.uk> Message-ID: On Mon, Mar 12, 2012 at 3:50 PM, Tim Chown wrote: > On 12 Mar 2012, at 19:30, Owen DeLong wrote: >> I know my view is unpopular, but, I really would rather see >>PI made inexpensive and readily available than see NAT >>brought into the IPv6 mainstream. However, in my >>experience, very few residential customers make >>use of that 3G backup port. > > So what assumptions do you think future IPv6-enabled >homenets might make about the prefixes they receive >or can use? ? Isn't having a PI per residential homenet >rather unlikely? Hi Tim, Not at all. You just build a second tier to the routing system. BGP is at the top tier. The second tier anchors SOHO users' provider independent addresses to a dynamically mapped set of top-tier relay addresses where each address in the relay anchor set can reach the SOHO's IP. Then you put an entry relay at many/most ISPs which receives the unrouted portions of PI space, looks up the exit relay set and relays the packet. The ingress relays have to keep some state but it's all discardable (can be re-looked up at any time). Also, they can be pushed close enough to the network edge that they aren't overwhelmed. The egress relays are stateless. Do it right and you get within a couple percent of the routing efficiency of BGP for SOHOs with only two or three ISPs. There are some issues with dead path detection which get thorny but they're solvable. There's also an origin filtering problem: packets originating from the PI space to BGP routed space aren't relayed and the ISP doesn't necessarily need to know that one of the PA addresses assigned to customer X is acting as an inbound relay for PI space. Again: solvable. If you want to dig in to how such a thing might work, read: http://bill.herrin.us/network/trrp.html Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bhmccie at gmail.com Mon Mar 12 15:19:16 2012 From: bhmccie at gmail.com (-Hammer-) Date: Mon, 12 Mar 2012 15:19:16 -0500 Subject: Whitelist of update servers In-Reply-To: References: Message-ID: <4F5E5A44.6080106@gmail.com> Can you be a little more specific? Otherwise I think your answer would be.... "The Internet" -Hammer- "I was a normal American nerd" -Jack Herer On 3/12/2012 3:05 PM, Maverick wrote: > Is there a whitelist that applications have to talk to in order to > update themselves? > > From bhmccie at gmail.com Mon Mar 12 15:21:02 2012 From: bhmccie at gmail.com (-Hammer-) Date: Mon, 12 Mar 2012 15:21:02 -0500 Subject: root zone stats In-Reply-To: References: <4F5AFD28.9010103@apolix.co.za> <4F5B0140.8010300@apolix.co.za> <86haxw7jfh.fsf@seastrom.com> <4F5BE02F.60901@dougbarton.us> <0da701ccffd1$019ff650$04dfe2f0$@iname.com> Message-ID: <4F5E5AAE.8010601@gmail.com> Shouldn't "eh" be Canada and not Western Sahara? -Hammer- "I was a normal American nerd" -Jack Herer On 3/12/2012 3:10 PM, Marco Davids (Prive) wrote: > On Mon, 12 Mar 2012, Marco Davids (Prive) wrote: > >>> Some nice info here, too: http://bgp.he.net/report/dns > >> .cw seems to be missing. > > Oops, it isn't... it's just not wehere I expected it. > > -- > Marco > > > From paul at paulgraydon.co.uk Mon Mar 12 15:22:23 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Mon, 12 Mar 2012 10:22:23 -1000 Subject: Whitelist of update servers In-Reply-To: References: Message-ID: <4F5E5AFF.1000008@paulgraydon.co.uk> On 03/12/2012 10:05 AM, Maverick wrote: > Is there a whitelist that applications have to talk to in order to > update themselves? > Which applications? What updates? From keegan.holley at sungard.com Mon Mar 12 15:30:12 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Mon, 12 Mar 2012 16:30:12 -0400 Subject: Whitelist of update servers In-Reply-To: References: Message-ID: 2012/3/12 Maverick > Is there a whitelist that applications have to talk to in order to > update themselves? > > sometimes From goemon at anime.net Mon Mar 12 15:30:59 2012 From: goemon at anime.net (goemon at anime.net) Date: Mon, 12 Mar 2012 13:30:59 -0700 (PDT) Subject: Whitelist of update servers In-Reply-To: References: Message-ID: vague question gets vague answer. "yes" -Dan On Mon, 12 Mar 2012, Maverick wrote: > Is there a whitelist that applications have to talk to in order to > update themselves? > From myeaddress at gmail.com Mon Mar 12 15:34:21 2012 From: myeaddress at gmail.com (Maverick) Date: Mon, 12 Mar 2012 16:34:21 -0400 Subject: Whitelist of update servers In-Reply-To: References: Message-ID: Like list of sites that operating systems or applications installed on your machines go to update themselves. One way could be to go on each vendors site and look at their update servers like microsoft.update.com but it would be good if there is a list of such servers for all OS and applications so that it could be used as a whitelist. On Mon, Mar 12, 2012 at 4:30 PM, Keegan Holley wrote: > > 2012/3/12 Maverick >> >> Is there a whitelist that applications have to talk to in order to >> update themselves? >> > sometimes > From keegan.holley at sungard.com Mon Mar 12 15:40:24 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Mon, 12 Mar 2012 16:40:24 -0400 Subject: Whitelist of update servers In-Reply-To: References: Message-ID: 2012/3/12 Maverick > Like list of sites that operating systems or applications installed on > your machines go to update themselves. One way could be to go on each > vendors site and look at their update servers like > microsoft.update.com but it would be good if there is a list of such > servers for all OS and applications so that it could be used as a > whitelist. > > I stick with my original answer... sometimes. I'm not sure if this is different now, but I remember MS update being spoofed with bogus DNS entries because the process is died to that dns name. I think this is the most popular method combined with some sort of encryption and/or signing to verify the updates themselves. I'm sure there are applications that use a white list though. There are alot of shops that update via some kind of CDN, so the whitelist method is a bit combersome at scale and is not immune to spoofing or other attacks. The most secure thing is probably to protect the updates themselves. From alter3d at alter3d.ca Mon Mar 12 15:40:44 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Mon, 12 Mar 2012 16:40:44 -0400 Subject: Whitelist of update servers In-Reply-To: References: Message-ID: <4F5E5F4C.1060204@alter3d.ca> I'm trying to determine if this is supposed to be an exercise in "How To Annoy Your Sysadmins" or "How To Do Network Security The Really, Really Wrong Way" or some combination of the two.... - Pete On 12-03-12 04:34 PM, Maverick wrote: > Like list of sites that operating systems or applications installed on > your machines go to update themselves. One way could be to go on each > vendors site and look at their update servers like > microsoft.update.com but it would be good if there is a list of such > servers for all OS and applications so that it could be used as a > whitelist. > > On Mon, Mar 12, 2012 at 4:30 PM, Keegan Holley > wrote: >> 2012/3/12 Maverick >>> Is there a whitelist that applications have to talk to in order to >>> update themselves? >>> >> sometimes >> From bill at herrin.us Mon Mar 12 15:53:26 2012 From: bill at herrin.us (William Herrin) Date: Mon, 12 Mar 2012 16:53:26 -0400 Subject: Whitelist of update servers In-Reply-To: <4F5E5F4C.1060204@alter3d.ca> References: <4F5E5F4C.1060204@alter3d.ca> Message-ID: On Mon, Mar 12, 2012 at 4:40 PM, Peter Kristolaitis wrote: > On 12-03-12 04:34 PM, Maverick wrote: >> Like list of sites that operating systems or applications installed on >> your machines go to update themselves. One way could be to go on each >> vendors site and look at their update servers like >> microsoft.update.com but it would be good if there is a list of such >> servers for all OS and applications so that it could be used as a >> whitelist. > I'm trying to determine if this is supposed to be an exercise in > ? ?"How To Annoy Your Sysadmins" > or > ? ?"How To Do Network Security The Really, Really Wrong Way" > or some combination of the two.... Pete, There are scenarios in which it is completely reasonable to provide white listed Web access instead of general Internet access. Consider: PCs in a prison with access to legal library and off-site education web sites. It would be helpful if they could also access automatic updates so they don't get malware but God help the sysadmin if one of the prisoners figures out how to get to child porn. That having been said, this is almost certainly the wrong mailing list to ask. It just isn't the kind of work we do here. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From alter3d at alter3d.ca Mon Mar 12 16:02:14 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Mon, 12 Mar 2012 17:02:14 -0400 Subject: Whitelist of update servers In-Reply-To: References: <4F5E5F4C.1060204@alter3d.ca> Message-ID: <4F5E6456.3050506@alter3d.ca> On 12-03-12 04:53 PM, William Herrin wrote: > On Mon, Mar 12, 2012 at 4:40 PM, Peter Kristolaitis wrote: >> On 12-03-12 04:34 PM, Maverick wrote: >>> Like list of sites that operating systems or applications installed on >>> your machines go to update themselves. One way could be to go on each >>> vendors site and look at their update servers like >>> microsoft.update.com but it would be good if there is a list of such >>> servers for all OS and applications so that it could be used as a >>> whitelist. >> I'm trying to determine if this is supposed to be an exercise in >> "How To Annoy Your Sysadmins" >> or >> "How To Do Network Security The Really, Really Wrong Way" >> or some combination of the two.... > Pete, > > There are scenarios in which it is completely reasonable to provide > white listed Web access instead of general Internet access. Consider: > PCs in a prison with access to legal library and off-site education > web sites. It would be helpful if they could also access automatic > updates so they don't get malware but God help the sysadmin if one of > the prisoners figures out how to get to child porn. > > That having been said, this is almost certainly the wrong mailing list > to ask. It just isn't the kind of work we do here. > > Regards, > Bill Herrin > > In my experience, if you're dealing with a locked down environment like that, one or both of the following will be true: - The users won't have sufficient privileges on the workstation to apply updates anyways - Software updates and configuration changes are managed centrally I agree that there are situations where whitelisted Web access might be suitable, but I expect the number of situations where you'd want whitelisted Web access AND ad-hoc software updates AND users to have local admin access on their workstations would be... very low. - Pete From paul at paulgraydon.co.uk Mon Mar 12 16:03:22 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Mon, 12 Mar 2012 11:03:22 -1000 Subject: Whitelist of update servers In-Reply-To: References: <4F5E5F4C.1060204@alter3d.ca> Message-ID: <4F5E649A.1000805@paulgraydon.co.uk> On 03/12/2012 10:53 AM, William Herrin wrote: > On Mon, Mar 12, 2012 at 4:40 PM, Peter Kristolaitis wrote: >> On 12-03-12 04:34 PM, Maverick wrote: >>> Like list of sites that operating systems or applications installed on >>> your machines go to update themselves. One way could be to go on each >>> vendors site and look at their update servers like >>> microsoft.update.com but it would be good if there is a list of such >>> servers for all OS and applications so that it could be used as a >>> whitelist. >> I'm trying to determine if this is supposed to be an exercise in >> "How To Annoy Your Sysadmins" >> or >> "How To Do Network Security The Really, Really Wrong Way" >> or some combination of the two.... > Pete, > > There are scenarios in which it is completely reasonable to provide > white listed Web access instead of general Internet access. Consider: > PCs in a prison with access to legal library and off-site education > web sites. It would be helpful if they could also access automatic > updates so they don't get malware but God help the sysadmin if one of > the prisoners figures out how to get to child porn. But there are ways of doing that, such as Windows Software Update Services, and a little bit of policy enforcement from a centralised place. That gives you a centralised, controlled place to push updates out from without risking the machines going off to the internet to get them themselves (and an opportunity to try limited roll-out just in case.) For that matter if it's necessary to be talking about blacklisting/whitelisting sites under such conditions as PCs in a prison you're really better off just paying for something like a Websense to take care of it. Paul From keegan.holley at sungard.com Mon Mar 12 16:12:51 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Mon, 12 Mar 2012 17:12:51 -0400 Subject: Programmers with network engineering skills In-Reply-To: References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> Message-ID: 2012/3/12 Tei > On 12 March 2012 09:59, Carlos Martinez-Cagnazzo > wrote: > > Hey! > > > > On 3/8/12 8:24 PM, Lamar Owen wrote: > >> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote: > >> ... > >>> (16) The default gateway's IP address is always 192.168.0.1 > >>> (17) The user portion of E-mail addresses never contain special > >>> characters like "-" "+" "$" "~" "." ",", "[", "]" > > I've just had my ' xx AT cagnazzo.name' email address rejected by a web > > form saying that 'it is not a valid email address'. So I guess point > > (17) can be extended to say that 'no email address shall end in anything > > different that .com, .net or the local ccTLD' > > > > :=) > > > > Carlos > > > Yea, I don't even know how programmers can get that wrong. The regex > is not even hard or anything. > > > > (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\]) > > I bet it's even harder without the use of a search engine. From iljitsch at muada.com Mon Mar 12 16:14:00 2012 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 12 Mar 2012 22:14:00 +0100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <4F5E14ED.8050808@dds.nl> <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl> <3FA2D2CD-A31A-4D22-AF06-58C5DCDC126E@ecs.soton.ac.uk> Message-ID: On 12 Mar 2012, at 21:15 , William Herrin wrote: > Not at all. You just build a second tier to the routing system. It's so strange how people think a locator/identifier split will solve the scalability problem. We already have two tiers: DNS names and IP addresses. So that didn't solve anything. I don't see any reason a second second tier would. From sfouant at shortestpathfirst.net Mon Mar 12 16:22:55 2012 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 12 Mar 2012 17:22:55 -0400 Subject: =?utf-8?Q?Re:_US_withdraws_IANA_RFP,_=E2=80=98no_suitable_respon?= =?utf-8?Q?ses=E2=80=99?= In-Reply-To: <4F5E593C.3080106@nic-naa.net> References: <1331578393.47483.YahooMailNeo@web180308.mail.gq1.yahoo.com> <4F5E593C.3080106@nic-naa.net> Message-ID: Was waiting for a response from Eric and without fail he comes through in record time... :-b Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI Technical Trainer, Juniper Networks Follow us on Twitter @JuniperEducate Sent from my iPad On Mar 12, 2012, at 4:14 PM, Eric Brunner-Williams wrote: > good head line copy edit. > > body lacks substance, though not attitude. > > -e > From owen at delong.com Mon Mar 12 16:32:23 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Mar 2012 14:32:23 -0700 Subject: Programmers with network engineering skills In-Reply-To: References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> Message-ID: <31CC8256-381A-4512-9628-8055D4B6A30A@delong.com> On Mar 12, 2012, at 2:12 PM, Keegan Holley wrote: > 2012/3/12 Tei > >> On 12 March 2012 09:59, Carlos Martinez-Cagnazzo >> wrote: >>> Hey! >>> >>> On 3/8/12 8:24 PM, Lamar Owen wrote: >>>> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote: >>>> ... >>>>> (16) The default gateway's IP address is always 192.168.0.1 >>>>> (17) The user portion of E-mail addresses never contain special >>>>> characters like "-" "+" "$" "~" "." ",", "[", "]" >>> I've just had my ' xx AT cagnazzo.name' email address rejected by a web >>> form saying that 'it is not a valid email address'. So I guess point >>> (17) can be extended to say that 'no email address shall end in anything >>> different that .com, .net or the local ccTLD' >>> >>> :=) >>> >>> Carlos >> >> >> Yea, I don't even know how programmers can get that wrong. The regex >> is not even hard or anything. >> >> >> >> (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\]) >> >> > I bet it's even harder without the use of a search engine. Whenever I've built code to check someone's email address on a form, I always just looked for the following: 1. matches ^[^@]+@[A-Za-z0-0\-\.]+[A-Za-z]$ 2. The component to the right of the @ sign returns at least one A, AAAA, or MX record. If it passed those two checks, I figured that was about as good as I could do without resorting to one of the following: 1. An incomprehensible and unmaintainable regex as the one above 2. Actually attempting delivery to said address Owen From mike at mtcc.com Mon Mar 12 16:42:52 2012 From: mike at mtcc.com (Michael Thomas) Date: Mon, 12 Mar 2012 14:42:52 -0700 Subject: Programmers with network engineering skills In-Reply-To: <31CC8256-381A-4512-9628-8055D4B6A30A@delong.com> References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <31CC8256-381A-4512-9628-8055D4B6A30A@delong.com> Message-ID: <4F5E6DDC.2050707@mtcc.com> On 03/12/2012 02:32 PM, Owen DeLong wrote: > Whenever I've built code to check someone's email address on a form, I always just looked for the following: 1. matches ^[^@]+@[A-Za-z0-0\-\.]+[A-Za-z]$ 2. The component to the right of the @ sign returns at least one A, AAAA, or MX record. If it passed those two checks, I figured that was about as good as I could do without resorting to one of the following: 1. An incomprehensible and unmaintainable regex as the one above 2. Actually attempting delivery to said address Owen "'I know, I'll use a regular expression!' now you have two problems." Mike From bill at herrin.us Mon Mar 12 17:01:38 2012 From: bill at herrin.us (William Herrin) Date: Mon, 12 Mar 2012 18:01:38 -0400 Subject: Programmers with network engineering skills In-Reply-To: <31CC8256-381A-4512-9628-8055D4B6A30A@delong.com> References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <31CC8256-381A-4512-9628-8055D4B6A30A@delong.com> Message-ID: On Mon, Mar 12, 2012 at 5:32 PM, Owen DeLong wrote: > Whenever I've built code to check someone's email address on a form, I always just looked for the following: > > 1. ? ? ?matches ^[^@]+@[A-Za-z0-0\-\.]+[A-Za-z]$ > 2. ? ? ?The component to the right of the @ sign returns at least one A, AAAA, or MX record. Hi Owen, If I'm not mistaken, "B at M4N"@delong.com is a legitimately formatted email address which fails part one of your test. Something along the lines of @delong.com;bob at some.private.network is also supposed to be legit though it's been so long since I looked at it that I may have munged the format. No, I don't allow these in systems I've designed either. Just sayin'. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From paul at paulgraydon.co.uk Mon Mar 12 17:09:18 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Mon, 12 Mar 2012 12:09:18 -1000 Subject: Programmers with network engineering skills In-Reply-To: References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> Message-ID: <4F5E740E.5040505@paulgraydon.co.uk> On 03/12/2012 09:46 AM, Tei wrote: > On 12 March 2012 09:59, Carlos Martinez-Cagnazzo wrote: >> Hey! >> >> On 3/8/12 8:24 PM, Lamar Owen wrote: >>> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote: >>> ... >>>> (16) The default gateway's IP address is always 192.168.0.1 >>>> (17) The user portion of E-mail addresses never contain special >>>> characters like "-" "+" "$" "~" "." ",", "[", "]" >> I've just had my ' xx AT cagnazzo.name' email address rejected by a web >> form saying that 'it is not a valid email address'. So I guess point >> (17) can be extended to say that 'no email address shall end in anything >> different that .com, .net or the local ccTLD' >> >> :=) >> >> Carlos > > Yea, I don't even know how programmers can get that wrong. The regex > is not even hard or anything. > > > (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\]) > > It's supposedly a lot harder than that. Try this for strict RFC822 compliance (from http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html): (?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?: \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:( ?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0 31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\ ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+ (?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?: (?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n) ?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\ r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n) ?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t] )*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])* )(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*) *:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+ |\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r \n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?: \r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t ]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031 ]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]( ?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(? :(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(? :\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(? :(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)? [ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]| \\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<> @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|" (?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t] )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(? :[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[ \]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000- \031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|( ?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,; :\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([ ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\" .\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\ ]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\ [\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\ r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\] |\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0 00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\ .|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@, ;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(? :[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])* (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[ ^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\] ]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*( ?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:( ?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[ \["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t ])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t ])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(? :\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+| \Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?: [^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\ ]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n) ?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[" ()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n) ?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<> @,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@, ;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t] )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)? (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?: \r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[ "()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t]) *))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]) +|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\ .(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:( ?:\r\n)?[ \t])*))*)?;\s*) Paul From lukasz at bromirski.net Mon Mar 12 17:20:13 2012 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Mon, 12 Mar 2012 23:20:13 +0100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <4F5E14ED.8050808@dds.nl> <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl> <3FA2D2CD-A31A-4D22-AF06-58C5DCDC126E@ecs.soton.ac.uk> Message-ID: <4F5E769D.4050707@bromirski.net> On 2012-03-12 22:14, Iljitsch van Beijnum wrote: > On 12 Mar 2012, at 21:15 , William Herrin wrote: > >> Not at all. You just build a second tier to the routing system. > > It's so strange how people think a locator/identifier split will solve > the scalability problem. We already have two tiers: DNS names and IP > addresses. So that didn't solve anything. I don't see any reason a > second second tier would. Wrong analogy IMHO. Using it, you'd know how to get to specific host in IPv4/IPv6-centric Internet by looking up it's name. Knowing a host is 'thishost.org' doesn't give you information needed to route IPv4/v6 packets that we still use, to this specific system. You still need to lookup the IP assigned to this name. For LISP (other solutions may vary obviously) knowing node 54.100 is available (after lookup) currently at 200.101 makes possibility for core routers to only remember the paths to 200.101/16 and not thousands of this prefix aggregates. This is aggregation of information at the same level of lookup execution. The real problems for world-wide LISP adoption are currently: - nobody sees a FIB explosion for IPv6, because - only around 8k worth of prefixes is in the global IPv6 table Hardly a reason for anyone to implement aggregation. If IPv6 would reach todays IPv4 level of 400k it would be still not a very compelling reason apart from those SPs willing to run all their edge without MPLS and with L3 devices that have very tiny FIBs - like 2/4/8k of entries. Typical core router has ability to forward 2-3M of IPv4 prefixes in hardware, and around 500k-2M of IPv6 prefixes in hardware - today. Ideal LISP use case would be for example 4M of IPv6 prefixes with steady clearly visible growth. Aggregating this down to for example (I've made this completely up) 200k prefixes and still having ability to traffic engineer the paths between the source and destination almost at the levels of having all 4M prefixes in FIB is very compelling reason to deploy LISP. -- "There's no sense in being precise when | ?ukasz Bromirski you don't know what you're talking | jid:lbromirski at jabber.org about." John von Neumann | http://lukasz.bromirski.net From owen at delong.com Mon Mar 12 17:40:29 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Mar 2012 15:40:29 -0700 Subject: Programmers with network engineering skills In-Reply-To: References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <31CC8256-381A-4512-9628-8055D4B6A30A@delong.com> Message-ID: <728A9697-AD60-482A-A533-E7868CFF9546@delong.com> I don't believe that is true. From RFC-821, it is true that: @ONE, @TWO:JOE at THREE Is supposed to be valid as a forward path, but, not an address. However, I believe its use is effectively, if not actually deprecated at this point. It doesn't really describe address, per se, but, it does define mailbox as follows: mailbox A character string (address) which identifies a user to whom mail is to be sent. Mailbox normally consists of the host and user specifications. The standard mailbox naming convention is defined to be "user at domain". Additionally, the "container" in which mail is stored. Looking at more recent RFC 5321, One important change is this: Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs: o The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4. Regarding addresses, it says this: 2.3.11. Mailbox and Address As used in this specification, an "address" is a character string that identifies a user to whom mail will be sent or a location into which mail will be deposited. The term "mailbox" refers to that depository. The two terms are typically used interchangeably unless the distinction between the location in which mail is placed (the mailbox) and a reference to it (the address) is important. An address normally consists of user and domain specifications. The standard mailbox naming convention is defined to be "local-part at domain"; contemporary usage permits a much broader set of applications than simple "user names". Consequently, and due to a long history of problems when intermediate hosts have attempted to Klensin Standards Track [Page 15] RFC 5321 SMTP October 2008 optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. Yes, there are user parts that are technically valid which my regex would reject. There are also some invalid addresses which I don't reject (for example, I won't reject Abc. at example.com). If you want to get truly pathologically pedantic about it: http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses You may have noticed my particular test wouldn't accept foo!bar!ucbvax!user format addresses, either. It works well enough for my purposes. I did not claim it was perfect. Owen On Mar 12, 2012, at 3:01 PM, William Herrin wrote: > On Mon, Mar 12, 2012 at 5:32 PM, Owen DeLong wrote: >> Whenever I've built code to check someone's email address on a form, I always just looked for the following: >> >> 1. matches ^[^@]+@[A-Za-z0-0\-\.]+[A-Za-z]$ >> 2. The component to the right of the @ sign returns at least one A, AAAA, or MX record. > > Hi Owen, > > If I'm not mistaken, "B at M4N"@delong.com is a legitimately formatted > email address which fails part one of your test. Something along the > lines of @delong.com;bob at some.private.network is also supposed to be > legit though it's been so long since I looked at it that I may have > munged the format. > > No, I don't allow these in systems I've designed either. Just sayin'. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From owen at delong.com Mon Mar 12 17:43:22 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Mar 2012 15:43:22 -0700 Subject: Programmers with network engineering skills In-Reply-To: <4F5E740E.5040505@paulgraydon.co.uk> References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <4F5E740E.5040505@paulgraydon.co.uk> Message-ID: <51FDF739-7B10-43C6-949C-06C5802780B9@delong.com> I think this proves one thing... Given enough monkeys with typewriters, you will, in fact, not get Shakespeare, but, instead, regular expressions for Shakespeare's email address. Owen On Mar 12, 2012, at 3:09 PM, Paul Graydon wrote: > On 03/12/2012 09:46 AM, Tei wrote: >> On 12 March 2012 09:59, Carlos Martinez-Cagnazzo wrote: >>> Hey! >>> >>> On 3/8/12 8:24 PM, Lamar Owen wrote: >>>> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote: >>>> ... >>>>> (16) The default gateway's IP address is always 192.168.0.1 >>>>> (17) The user portion of E-mail addresses never contain special >>>>> characters like "-" "+" "$" "~" "." ",", "[", "]" >>> I've just had my ' xx AT cagnazzo.name' email address rejected by a web >>> form saying that 'it is not a valid email address'. So I guess point >>> (17) can be extended to say that 'no email address shall end in anything >>> different that .com, .net or the local ccTLD' >>> >>> :=) >>> >>> Carlos >> >> Yea, I don't even know how programmers can get that wrong. The regex >> is not even hard or anything. >> >> >> (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\]) >> >> > It's supposedly a lot harder than that. Try this for strict RFC822 compliance (from http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html): > > (?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] > )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?: > \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:( > ?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ > \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0 > 31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\ > ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+ > (?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?: > (?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z > |(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n) > ?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\ > r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ > \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n) > ?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t] > )*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ > \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])* > )(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] > )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*) > *:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+ > |\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r > \n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?: > \r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t > ]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031 > ]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]( > ?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(? > :(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(? > :\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(? > :(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)? > [ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] > \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]| > \\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<> > @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|" > (?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t] > )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ > ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(? > :[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[ > \]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000- > \031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|( > ?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,; > :\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([ > ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\" > .\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\ > ]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\ > [\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\ > r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] > \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\] > |\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0 > 00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\ > .|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@, > ;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(? > :[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])* > (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". > \[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[ > ^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\] > ]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*( > ?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ > ".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:( > ?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[ > \["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t > ])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t > ])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(? > :\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+| > \Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?: > [^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\ > ]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n) > ?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[" > ()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n) > ?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<> > @,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ > \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@, > ;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t] > )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ > ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)? > (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". > \[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?: > \r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[ > "()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t]) > *))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]) > +|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\ > .(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z > |(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:( > ?:\r\n)?[ \t])*))*)?;\s*) > > Paul From bill at herrin.us Mon Mar 12 17:50:13 2012 From: bill at herrin.us (William Herrin) Date: Mon, 12 Mar 2012 18:50:13 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <4F5E14ED.8050808@dds.nl> <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl> <3FA2D2CD-A31A-4D22-AF06-58C5DCDC126E@ecs.soton.ac.uk> Message-ID: On Mon, Mar 12, 2012 at 5:14 PM, Iljitsch van Beijnum wrote: > On 12 Mar 2012, at 21:15 , William Herrin wrote: >> Not at all. You just build a second tier to the routing system. > > We already have two tiers: DNS names and IP addresses. Hi Iljitsch, If only that were true. The DNS doesn't sit to the side of TCP, managing the moment to moment layer 4 to layer 3 mapping function the way ARP sits to the side of IP. Instead, the DNS's function is actuated all the way up at layer 7. This was the crux of my complaint about the getaddrinfo/connect APIs last week. Their design makes a future introduction of a transport protocol, something which actually does interact with the name service at the proper layer, needlessly hard. That and the common non-operation of the DNS TTL invalidates DNS' use as a routing tier. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeroen at mompl.net Mon Mar 12 18:22:53 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 12 Mar 2012 16:22:53 -0700 Subject: Programmers with network engineering skills In-Reply-To: <728A9697-AD60-482A-A533-E7868CFF9546@delong.com> References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <31CC8256-381A-4512-9628-8055D4B6A30A@delong.com> <728A9697-AD60-482A-A533-E7868CFF9546@delong.com> Message-ID: <4F5E854D.3050102@mompl.net> Owen DeLong wrote: > http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses > > You may have noticed my particular test wouldn't accept foo!bar!ucbvax!user format addresses, either. > > It works well enough for my purposes. I did not claim it was perfect. Why not leave it to the MTA to decide what is a valid address? It only requires a few SMTP commands to the MTA to know if it will accept it. Normally the MTA will tell you after the "rcpt to:" command if it will accept it (i'm ignoring some badly behaving MTAs who will swallow anything and then bounce, no point trying to work around such crap). No need to re-invent the wheel, unless you're actually creating an MTA or something similar. Who is to say that even IF your address verifier verifies it as valid that the MTA is configured to allow it (or the other way around)? MTAs can be arbitrarily configured to (dis)allow "bang path" addresses, IP addresses etc. Regards, Jeroen -- Earthquake Magnitude: 5.0 Date: Monday, March 12, 2012 17:55:10 UTC Location: Kepulauan Talaud, Indonesia Latitude: 3.0222; Longitude: 127.0054 Depth: 35.00 km From mohta at necom830.hpcl.titech.ac.jp Mon Mar 12 18:29:20 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 13 Mar 2012 08:29:20 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> Message-ID: <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> William Herrin wrote: > When I ran the numbers a few years ago, a route had a global cost > impact in the neighborhood of $8000/year. It's tough to make a case > that folks who need multihoming's reliability can't afford to put that > much into the system. The cost for bloated DFZ routing table is not so small and is paid by all the players, including those who use DFZ but do not multihome. Those who can't pay the cost silently give up to be multihomed, which is why you overlooked them. Even those who pays the cost are not using full routing table for IGP, which makes their multihoming less capable. > A *working* multi-addressed end user system (like shim6 attempted) Shim6 is too poorly designed that it does not work. > Often overlooked is that multihoming through multi-addressing could > solve IP mobility too. Not. What is often overlooked is the fact that they are orthogonal problems. > Carry > your voip call uninterrupted from your home wifi on the cable modem to > your cell provider in the car to your employer's wired ethernet and > back. Use mobile IP implemented long before shim6 was designed. > Unfortunately, shim6 didn't work in some of the boundary cases. Since > single-homing works pretty well in the ordinary case, there's not much > point to a multihoming protocol that fails to deliver all the boundary > cases. Just like NAT, shim6 is an intelligent intermediate entity trying to hide its existence from applications, which is why it does not work sometimes just as NAT does not work sometimes. The only end to end way to handle multiple addresses is to let applications handle them explicitly. Masataka Ohta From owen at delong.com Mon Mar 12 18:47:02 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 12 Mar 2012 16:47:02 -0700 Subject: Programmers with network engineering skills In-Reply-To: <4F5E854D.3050102@mompl.net> References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <31CC8256-381A-4512-9628-8055D4B6A30A@delong.com> <728A9697-AD60-482A-A533-E7868CFF9546@delong.com> <4F5E854D.3050102@mompl.net> Message-ID: <670D79A1-4FBF-41CC-9EA5-7AE84949D906@delong.com> Sometimes you don't want to have your application exposed to an unconstrained wait outside of your control. Sometimes your application may not have access/permissions/etc. to open sockets. (This is actually a common security precaution in some CGI environments). Owen On Mar 12, 2012, at 4:22 PM, Jeroen van Aart wrote: > Owen DeLong wrote: >> http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses >> You may have noticed my particular test wouldn't accept foo!bar!ucbvax!user format addresses, either. >> It works well enough for my purposes. I did not claim it was perfect. > > Why not leave it to the MTA to decide what is a valid address? It only requires a few SMTP commands to the MTA to know if it will accept it. Normally the MTA will tell you after the "rcpt to:" command if it will accept it (i'm ignoring some badly behaving MTAs who will swallow anything and then bounce, no point trying to work around such crap). > > No need to re-invent the wheel, unless you're actually creating an MTA or something similar. > > Who is to say that even IF your address verifier verifies it as valid that the MTA is configured to allow it (or the other way around)? MTAs can be arbitrarily configured to (dis)allow "bang path" addresses, IP addresses etc. > > Regards, > Jeroen > > -- > Earthquake Magnitude: 5.0 > Date: Monday, March 12, 2012 17:55:10 UTC > Location: Kepulauan Talaud, Indonesia > Latitude: 3.0222; Longitude: 127.0054 > Depth: 35.00 km From randy at psg.com Mon Mar 12 19:51:15 2012 From: randy at psg.com (Randy Bush) Date: Tue, 13 Mar 2012 09:51:15 +0900 Subject: Whitelist of update servers In-Reply-To: References: Message-ID: i tend to two defenses o if it is not an urgent update, i wait to hear from peers that it is safe. o i generally do not accept pop-up updates. if one looks tasty, when possible i navigate directly to the site (yes, i know about dns spoofing) and download. randy From bill at herrin.us Mon Mar 12 20:01:29 2012 From: bill at herrin.us (William Herrin) Date: Mon, 12 Mar 2012 21:01:29 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> Message-ID: 2012/3/12 Masataka Ohta : > William Herrin wrote: > >> When I ran the numbers a few years ago, a route had a global cost >> impact in the neighborhood of $8000/year. It's tough to make a case >> that folks who need multihoming's reliability can't afford to put that >> much into the system. > > The cost for bloated DFZ routing table is not so small and is > paid by all the players, including those who use DFZ but do > not multihome. Hi, http://bill.herrin.us/network/bgpcost.html If you believe there's an error in my methodology, feel free to take issue with it. >> Often overlooked is that multihoming through multi-addressing could >> solve IP mobility too. > > Not. > > What is often overlooked is the fact that they are orthogonal > problems. I respectfully disagree. Current mobility efforts have gone down a blind alley of relays from a home server and handoffs from one network to the next. And in all fairness, with TCP tightly bound to a particular IP address pair there aren't a whole lot of other options. Nevertheless, it's badly suboptimal. Latency and routing inefficiency rapidly increases with distance from the home node among other major problems. However, there's another way to imagine the problem: Networks become available. Networks cease to be available. No handoff. No home server. Just add and drop. Announce a route into the global system to each available network with priority set based on the node's best estimate of the network's bandwidth, likely future availablilty, etc. Cancel the announcement for any network that has left or is leaving range. Modify the announcement priority as the node's estimate of the network evolves. This is quite impossible with today's BGP core. The update rate would crush the core, as would the prefix count. And if those problems were magically solved, BGP still isn't capable of propagating a change fast enough to be useful for mobile applications. But suppose you had a TCP protocol that wasn't statically bound to the IP address by the application layer. Suppose each side of the connection referenced each other by name, TCP expected to spread packets across multiple local and remote addresses, and suppose TCP, down at layer 4, expected to generate calls to the DNS any time it wasn't sure what addresses it should be talking to. DNS servers can withstand the update rate. And the prefix count is moot. DNS is a distributed database. It *already* easily withstands hundreds of millions of entries in the in-addr.arpa zone alone. And if the node gets even moderately good at predicting when it will lose availability for each network it connects to and/or when to ask the DNS again instead of continuing to try the known IP addresses you can get to where network drops are ordinarily lossless and only occasionally result in a few packet losses over the course of a a single-digit number of seconds. Which would be just dandy for mobile IP applications. > The only end to end way to handle multiple addresses is to let > applications handle them explicitly. For connection-oriented protocols, that's nonsense. Pick an appropriate mapping function and you can handle multiple layer 3 addresses just fine at layer 4. Just like we successfully handle layer 2 addresses at layer 3. For connectionless protocols, maybe. Certainly layer 7 knowledge is needed to decide whether each path is operational. However, I'm not convinced that can't be reliably accomplished with a hinting process where the application tells layer 4 its best guess of which send()'s succeeded or failed and lets layer 4 figure out the resulting gory details of address selection. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jgreco at ns.sol.net Mon Mar 12 20:31:21 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 12 Mar 2012 20:31:21 -0500 (CDT) Subject: Programmers with network engineering skills In-Reply-To: <4F5E854D.3050102@mompl.net> Message-ID: <201203130131.q2D1VLXa087735@aurora.sol.net> > Owen DeLong wrote: > > http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses > > > > You may have noticed my particular test wouldn't accept foo!bar!ucbvax!user format addresses, either. > > > > It works well enough for my purposes. I did not claim it was perfect. > > Why not leave it to the MTA to decide what is a valid address? It only > requires a few SMTP commands to the MTA to know if it will accept it. > Normally the MTA will tell you after the "rcpt to:" command if it will > accept it (i'm ignoring some badly behaving MTAs who will swallow > anything and then bounce, no point trying to work around such crap). > > No need to re-invent the wheel, unless you're actually creating an MTA > or something similar. > > Who is to say that even IF your address verifier verifies it as valid > that the MTA is configured to allow it (or the other way around)? MTAs > can be arbitrarily configured to (dis)allow "bang path" addresses, IP > addresses etc. The ideal world contains a mix of techniques. You cannot just blindly leave it to the MTA to decide what's valid. Along that path lies madness. How do you pass the address to the MTA? Don't do it as a system() call unless you want someone to own your box with a semicolon. Do you allow \n? \r? Do you allow \\? There is a certain amount of paranoia that is prudent, and a certain amount that is actually necessary... though it's true that implementations often don't bother to work that out correctly... ... 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 jeff-kell at utc.edu Mon Mar 12 21:10:42 2012 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 12 Mar 2012 22:10:42 -0400 Subject: Whitelist of update servers In-Reply-To: References: Message-ID: <4F5EACA2.6020808@utc.edu> An "IP-based" whitelist is pretty much doomed from the start. Many vendors use content delivery networks and that is too large and volatile to chase. We have had some success in captive portal environments with DNS manipulation, allowing only certain domains to resolve, and redirecting everything else to the portal. The list is still non-trivial, but manageable. So don't manage it at the router level, you will have better luck at the DNS layer. Jeff On 3/12/2012 8:51 PM, Randy Bush wrote: > i tend to two defenses > > o if it is not an urgent update, i wait to hear from peers that > it is safe. > > o i generally do not accept pop-up updates. if one looks tasty, > when possible i navigate directly to the site (yes, i know about > dns spoofing) and download. From josh.hoppes at gmail.com Mon Mar 12 21:42:02 2012 From: josh.hoppes at gmail.com (Josh Hoppes) Date: Mon, 12 Mar 2012 21:42:02 -0500 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> Message-ID: On Mon, Mar 12, 2012 at 8:01 PM, William Herrin wrote: > But suppose you had a TCP protocol that wasn't statically bound to the > IP address by the application layer. Suppose each side of the > connection referenced each other by name, TCP expected to spread > packets across multiple local and remote addresses, and suppose TCP, > down at layer 4, expected to generate calls to the DNS any time it > wasn't sure what addresses it should be talking to. > > DNS servers can withstand the update rate. And the prefix count is > moot. DNS is a distributed database. It *already* easily withstands > hundreds of millions of entries in the in-addr.arpa zone alone. And if > the node gets even moderately good at predicting when it will lose > availability for each network it connects to and/or when to ask the > DNS again instead of continuing to try the known IP addresses you can > get to where network drops are ordinarily lossless and only > occasionally result in a few packet losses over the course of a a > single-digit number of seconds. > > Which would be just dandy for mobile IP applications. DNS handles many of millions of records sure, but that's because it was designed with caching in mind. DNS changes are rarely done at the rapid I think you are suggesting except for those who can stand the brunt of 5 minute time to live values. I think it would be insane to try and set a TTL much lower then that, but that would seem to work counter to the idea of sub 10 second loss. If you cut down caching as significantly as I think this idea would suggest I would expect scaling will take a plunge. Also consider the significant increased load on DNS servers to handling the constant stream of dynamic DNS updates to make this possible, and that you have to find some reliable trust mechanism to handle these updates because with out that you just made man in the middle attacks a just a little bit easier. That said, I might be misunderstanding something. I would like to see that idea elaborated. From keegan.holley at sungard.com Mon Mar 12 22:01:57 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Mon, 12 Mar 2012 23:01:57 -0400 Subject: Programmers with network engineering skills In-Reply-To: <31CC8256-381A-4512-9628-8055D4B6A30A@delong.com> References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <31CC8256-381A-4512-9628-8055D4B6A30A@delong.com> Message-ID: <49FDF372-AA33-4339-8F89-6DC94FFBBEDD@sungard.com> On Mar 12, 2012, at 5:32 PM, Owen DeLong wrote: > > On Mar 12, 2012, at 2:12 PM, Keegan Holley wrote: > >> 2012/3/12 Tei >> >>> On 12 March 2012 09:59, Carlos Martinez-Cagnazzo >>> wrote: >>>> Hey! >>>> >>>> On 3/8/12 8:24 PM, Lamar Owen wrote: >>>>> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote: >>>>> ... >>>>>> (16) The default gateway's IP address is always 192.168.0.1 >>>>>> (17) The user portion of E-mail addresses never contain special >>>>>> characters like "-" "+" "$" "~" "." ",", "[", "]" >>>> I've just had my ' xx AT cagnazzo.name' email address rejected by a web >>>> form saying that 'it is not a valid email address'. So I guess point >>>> (17) can be extended to say that 'no email address shall end in anything >>>> different that .com, .net or the local ccTLD' >>>> >>>> :=) >>>> >>>> Carlos >>> >>> >>> Yea, I don't even know how programmers can get that wrong. The regex >>> is not even hard or anything. >>> >>> >>> >>> (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\]) >>> >>> >> I bet it's even harder without the use of a search engine. > > Whenever I've built code to check someone's email address on a form, I always just looked for the following: > > 1. matches ^[^@]+@[A-Za-z0-0\-\.]+[A-Za-z]$ > 2. The component to the right of the @ sign returns at least one A, AAAA, or MX record. > > If it passed those two checks, I figured that was about as good as I could do without resorting to one of the following: > 1. An incomprehensible and unmaintainable regex as the one above > 2. Actually attempting delivery to said address > > Owen > I've done some scripting with the similar goals and to be completely honest I've skews at least consulted google. It's much easier to read and test a regular expression like the one above than to write one from scratch. Sometimes it takes an incomprehensible regex to be thorough. Sometimes close enough really is close enough though. It depends on the problem you are trying to solve. > From marka at isc.org Mon Mar 12 22:12:29 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 13 Mar 2012 14:12:29 +1100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: Your message of "Mon, 12 Mar 2012 21:42:02 CDT." References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> Message-ID: <20120313031229.DE1681E6E2B4@drugs.dv.isc.org> In message , Josh Hoppes writes: > Also consider the significant increased load on DNS servers to > handling the constant stream of dynamic DNS updates to make this > possible, and that you have to find some reliable trust mechanism to > handle these updates because with out that you just made man in the > middle attacks a just a little bit easier. The DNS already supports cryptographically authenticated updates. There is a good chance that your DHCP server used one of the methods below when you got your lease. SIG(0), TSIG and GSS_TSIG all scale appropiately for this. Mark -- 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 Mar 12 22:18:12 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 13 Mar 2012 14:18:12 +1100 Subject: Programmers with network engineering skills In-Reply-To: Your message of "Mon, 12 Mar 2012 20:31:21 CDT." <201203130131.q2D1VLXa087735@aurora.sol.net> References: <201203130131.q2D1VLXa087735@aurora.sol.net> Message-ID: <20120313031812.EFD301E6E4AB@drugs.dv.isc.org> In message <201203130131.q2D1VLXa087735 at aurora.sol.net>, Joe Greco writes: > > Owen DeLong wrote: > > > http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses > > > > > > You may have noticed my particular test wouldn't accept foo!bar!ucbvax!us > er format addresses, either. > > > > > > It works well enough for my purposes. I did not claim it was perfect. > > > > Why not leave it to the MTA to decide what is a valid address? It only > > requires a few SMTP commands to the MTA to know if it will accept it. > > Normally the MTA will tell you after the "rcpt to:" command if it will > > accept it (i'm ignoring some badly behaving MTAs who will swallow > > anything and then bounce, no point trying to work around such crap). > > > > No need to re-invent the wheel, unless you're actually creating an MTA > > or something similar. > > > > Who is to say that even IF your address verifier verifies it as valid > > that the MTA is configured to allow it (or the other way around)? MTAs > > can be arbitrarily configured to (dis)allow "bang path" addresses, IP > > addresses etc. > > The ideal world contains a mix of techniques. > > You cannot just blindly leave it to the MTA to decide what's valid. > Along that path lies madness. How do you pass the address to the MTA? > Don't do it as a system() call unless you want someone to own your > box with a semicolon. Only if you don't properly quote/escape the arguments you are passing. > Do you allow \n? \r? Do you allow \\? There > is a certain amount of paranoia that is prudent, and a certain amount > that is actually necessary... though it's true that implementations > often don't bother to work that out correctly... > > ... 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(CN > N) > With 24 million small businesses in the US alone, that's way too many apples. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gih at apnic.net Mon Mar 12 22:19:00 2012 From: gih at apnic.net (Geoff Huston) Date: Tue, 13 Mar 2012 14:19:00 +1100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <20120312153155.GA85481@ussenterprise.ufp.org> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> Message-ID: <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> On 13/03/2012, at 2:31 AM, Leo Bicknell wrote: > In a message written on Mon, Mar 12, 2012 at 11:07:54AM -0400, Robert E. Seastrom wrote: >> Grass-roots, bottom-up policy process >> + >> Need for multihoming >> + >> Got tired of waiting >> = >> IPv6 PI > > I'll also add that Shim6 folks never made a good economic argument. > It's true that having routes in the DFZ costs money, and that > reducing the number of routes will save the industry money in router > upgrades and such to handle more routes. However, it's also true > that deploying SHIM6 (or similar solutions) also has a cost in > rewritten software, traning for network engineers and administrators, > and so on. > > It was never clear to me that even if it worked 100% as advertised that > it would be cheaper / better in the global sense. > I think that's asking too much of the IETF Leo - Shim6 went through much the same process as most of the IETF work these days: bubble of thought, BOF sanity check, requirements work, protocol prototyping, technology specification. Yes, the economics of routing are strange, and the lack of any real strictures in the routing tables are testament to the observation that despite more than two decades of tossing the idea around we've yet to find the equivalent of a "route deaggregation tax" or a "route advertisement tax" or any other mechanism that effectively turns the routing space into a form of market that imposes some economic constraints on the activity. So after so long looking for such a framework in routing, the hope that someday we will figure it out gets smaller and smaller every day. And in some ways the routing explosion problem is one of fear rather than actuality - the growth rates of the IPv4 routing table have been sitting at around 8% - 15% p.a. for many years. oWhile you can't route the Internet on 15 year old hardware, the growth figures are still low enough under Moore's Law that the unit cost of routing is not escalating at levels that are notably higher than other cost elements for an ISP. Its not the routing table explosion that will cause you to raise your fees or worse, go bankrupt tomorrow. So in some ways for Shim6 to have a "good economic argument" I suspect that Shim6 would have to have pulled out of thin air an approach that completely externalised the cost of routing, and made routing completely free for ISPs. And that is simply fantasy land! Geoff From gih at apnic.net Mon Mar 12 22:33:29 2012 From: gih at apnic.net (Geoff Huston) Date: Tue, 13 Mar 2012 14:33:29 +1100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <4F5E14ED.8050808@dds.nl> <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl> <3FA2D2CD-A31A-4D22-AF06-58C5DCDC126E@ecs.soton.ac.uk> Message-ID: <5E848BE7-83D8-4509-9D83-BE3B01E6CA18@apnic.net> On 13/03/2012, at 8:14 AM, Iljitsch van Beijnum wrote: > On 12 Mar 2012, at 21:15 , William Herrin wrote: > >> Not at all. You just build a second tier to the routing system. > > It's so strange how people think a locator/identifier split will solve the scalability problem. We already have two tiers: DNS names and IP addresses. So that didn't solve anything. I don't see any reason a second second tier would. I think you have encountered an article of faith Iljitsch :-) http://en.wikipedia.org/wiki/Indirectio: Any problem can be solved by adding another layer of indirection. From bill at herrin.us Mon Mar 12 23:34:35 2012 From: bill at herrin.us (William Herrin) Date: Tue, 13 Mar 2012 00:34:35 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <5E848BE7-83D8-4509-9D83-BE3B01E6CA18@apnic.net> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <4F5E14ED.8050808@dds.nl> <85C74EB9-609F-4BC0-98EA-7B8700089E35@delong.com> <9D19C39B-4CC6-4A24-95AE-3D4CAEA184CD@dds.nl> <3FA2D2CD-A31A-4D22-AF06-58C5DCDC126E@ecs.soton.ac.uk> <5E848BE7-83D8-4509-9D83-BE3B01E6CA18@apnic.net> Message-ID: On Mon, Mar 12, 2012 at 11:33 PM, Geoff Huston wrote: > On 13/03/2012, at 8:14 AM, Iljitsch van Beijnum wrote: >> On 12 Mar 2012, at 21:15 , William Herrin wrote: >>> Not at all. You just build a second tier to the routing system. >> >> It's so strange how people think a locator/identifier split >> will solve the scalability problem. We already have two >> tiers: DNS names and IP addresses. So that didn't solve >> anything. I don't see any reason a second second tier would. > > I think you have encountered an article of faith Iljitsch :-) > > ? ?http://en.wikipedia.org/wiki/Indirection: ?Any problem can be solved by adding another layer of indirection. "But that usually will create another problem." Then the test must be: does any particular proposed layer of indirection solve more intractable and more valuable problems than it creates, enough more valuable to be worth the cost of implementation? Still, I concede that it would be "better" to more effectively use the indirection layer we have (DNS) rather than create another. Better, but not necessarily achievable. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Mar 12 23:54:54 2012 From: bill at herrin.us (William Herrin) Date: Tue, 13 Mar 2012 00:54:54 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> Message-ID: On Mon, Mar 12, 2012 at 10:42 PM, Josh Hoppes wrote: > On Mon, Mar 12, 2012 at 8:01 PM, William Herrin wrote: >> Which would be just dandy for mobile IP applications. > > DNS handles many of millions of records sure, but that's because it > was designed with caching in mind. DNS changes are rarely done at the > rapid I think you are suggesting except for those who can stand the > brunt of 5 minute time to live values. I think it would be insane to > try and set a TTL much lower then that, but that would seem to work > counter to the idea of sub 10 second loss. If you cut down caching as > significantly as I think this idea would suggest I would expect > scaling will take a plunge. Hi Josh, Actually, there was a study presented a few years ago. I think it was at a Fall NANOG. At any rate, a gentleman at a university decided to study the impact of adjusting the DNS TTL on the query count hitting his authoritative server. IIRC he tested ranges from 24 hours to 60 seconds. In my opinion he didn't control properly for browser DNS pinning (which would tend to suppress query count) but even with that taken into account, the increase in queries due to decreased TTLs was much less than you might expect. > Also consider the significant increased load on DNS servers to > handling the constant stream of dynamic DNS updates to make this > possible, and that you have to find some reliable trust mechanism to > handle these updates because with out that you just made man in the > middle attacks a just a little bit easier. That's absolutely correct. We would see a ten-factor increase in load on the naming system and could see as much as a two order of magnitude increase in load. But not on the root -- that load increase is distributed almost exclusively to the leaves. And DNS has long since proven it can scale up many orders of magnitude more than that. By adding servers to be sure... but the DNS job parallelizes trivially and well. Route processing, like with BGP, doesn't. And you're right about implementing a trust mechanism suitable for such an architecture. There's quite a bit of cryptographic work already present in DNS updates but I frankly have no idea whether it would hold up here or whether something new would be required. If it can be reduced to "hostname and DNS password," and frankly I'd be shocked if it couldn't, then any problem should be readily solvable. > That said, I might be misunderstanding something. I would like to see > that idea elaborated. >From your questions, it sounds like you're basically following the concept. I sketched out the idea a couple years ago, working through some of the permutations. And the MPTCP working group has been chasing some of the concepts for a while too, though last I checked they'd fallen into one of the major architectural pitfalls of shim6, trying to bootstrap the address list instead of relying on a mapper. The main problem is that we "can't get there from here." No set of changes modest enough to not be another "IPv6 transition" gets the job done. We'd need to entrench smaller steps in the direction of such a protocol first. Like enhancing the sockets API with a variant of connect() which expects to take a host name and service name and return a connected protocol-agnostic socket. Today, just some under-the-hood calls to a non-blocking getaddrinfo and some parallelized connect()'s that happens to work better and be an easier choice than what most folks could write for themselves. But in the future, a socket connection call which receives all the knowledge that a multi-addressed protocol needs to get the job done without further changes to the application's code. Or, if I'm being fair about it, doing what the MPTCP folks are doing and then following up later with additional enhancements to call out to DNS from the TCP layer. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeroen at mompl.net Tue Mar 13 01:50:54 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 12 Mar 2012 23:50:54 -0700 Subject: Programmers with network engineering skills In-Reply-To: <201203130131.q2D1VLXa087735@aurora.sol.net> References: <201203130131.q2D1VLXa087735@aurora.sol.net> Message-ID: <4F5EEE4E.2050807@mompl.net> Joe Greco wrote: > The ideal world contains a mix of techniques. Yes and copying parts of relevant code of an MTA could be one. > You cannot just blindly leave it to the MTA to decide what's valid. > Along that path lies madness. How do you pass the address to the MTA? > Don't do it as a system() call unless you want someone to own your > box with a semicolon. Well, the whole world can pass whatever it wants to an MTA, it's supposed to be listening on internet facing port 25 all the time, that's it's mean reason of existence. An MTA is particularly well suited to take any kind of abuse, because that's exactly what it's expecting. Unless in cases such as Owen mentioned I'd say it's a pretty good solution. The madness to me lies in making your own email validating code... Greetings, Jeroen -- Earthquake Magnitude: 4.5 Date: Tuesday, March 13, 2012 04:15:05 UTC Location: Dominican Republic region Latitude: 19.3644; Longitude: -68.0645 Depth: 19.20 km From mohta at necom830.hpcl.titech.ac.jp Tue Mar 13 02:21:17 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 13 Mar 2012 16:21:17 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> Message-ID: <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> William Herrin wrote: >>> When I ran the numbers a few years ago, a route had a global cost >>> impact in the neighborhood of $8000/year. It's tough to make a case >>> that folks who need multihoming's reliability can't afford to put that >>> much into the system. >> >> The cost for bloated DFZ routing table is not so small and is >> paid by all the players, including those who use DFZ but do >> not multihome. > > Hi, > > http://bill.herrin.us/network/bgpcost.html > > If you believe there's an error in my methodology, feel free to take > issue with it. Your estimate on the number of routers in DFZ: somewhere between 120,000 and 180,000 with the consensus number near 150,000 is a result of high cost of routers and is inappropriate to estimate global cost of a routing table entry. Because DFZ capable routers are so expensive, the actual number of routers is so limited. If the number of routes in DFZ is, say, 100, many routers and hosts will be default free. >>> Often overlooked is that multihoming through multi-addressing could >>> solve IP mobility too. >> >> Not. >> >> What is often overlooked is the fact that they are orthogonal >> problems. > > I respectfully disagree. My statement is based on my experience to implement locator/ID separation system with multi-address TCP and IP mobility. They need separate mechanisms and separate coding. > Current mobility efforts have gone down a > blind alley of relays from a home server and handoffs from one network > to the next. And in all fairness, with TCP tightly bound to a > particular IP address pair there aren't a whole lot of other options. > Nevertheless, it's badly suboptimal. Latency and routing inefficiency > rapidly increases with distance from the home node among other major > problems. That is a mobility issue of triangle elimination having nothing to do with TCP. > But suppose you had a TCP protocol that wasn't statically bound to the > IP address by the application layer. Suppose each side of the > connection referenced each other by name, TCP expected to spread > packets across multiple local and remote addresses, and suppose TCP, > down at layer 4, expected to generate calls to the DNS any time it > wasn't sure what addresses it should be talking to. Ignoring that DNS does not work so fast, TCP becomes "it wasn't sure what addresses it should be talking to" only after a long timeout. > And if > the node gets even moderately good at predicting when it will lose > availability for each network it connects to and/or when to ask the > DNS again instead of continuing to try the known IP addresses you can What? A node asks DNS IP addresses of its peer, because the node is changing its IP addresses? >> The only end to end way to handle multiple addresses is to let >> applications handle them explicitly. > > For connection-oriented protocols, that's nonsense. Pick an > appropriate mapping function and you can handle multiple layer 3 > addresses just fine at layer 4. It will require the applications perform reverse mapping function, when they require raw IP addresses. > For connectionless protocols, maybe. I'm afraid you are unaware of connected UDP. > However, I'm not > convinced that can't be reliably accomplished with a hinting process > where the application tells layer 4 its best guess of which send()'s > succeeded or failed and lets layer 4 figure out the resulting gory > details of address selection. That's annoying, which is partly why shim6 failed. It's a lot easier for UDP-based applications directly manage multiple IP addresses. Masataka Ohta From me at payam124.com Tue Mar 13 03:49:12 2012 From: me at payam124.com (Payam Poursaied) Date: Tue, 13 Mar 2012 12:19:12 +0330 Subject: HSBC - Canada / US Contact off list Message-ID: <047801cd00f6$299703d0$7cc50b70$@payam124.com> Hi Can someone from HSBC (specially Canada) who is involved in network operation contact me off-list. Some of our customers which get IP address from specific network blocks, could not reach hsbc.ca. follow-up with internet banking staff, customer support, and .., did not point us to the right person. Thnx -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5593 bytes Desc: not available URL: From aledm at qix.co.uk Tue Mar 13 05:53:49 2012 From: aledm at qix.co.uk (Aled Morris) Date: Tue, 13 Mar 2012 10:53:49 +0000 Subject: Programmers with network engineering skills In-Reply-To: <4F5EEE4E.2050807@mompl.net> References: <201203130131.q2D1VLXa087735@aurora.sol.net> <4F5EEE4E.2050807@mompl.net> Message-ID: On 13 March 2012 06:50, Jeroen van Aart wrote: > Unless in cases such as Owen mentioned I'd say it's a pretty good > solution. The madness to me lies in making your own email validating code... > > Not forgetting Lett's Law Aled From malayter at gmail.com Tue Mar 13 06:49:39 2012 From: malayter at gmail.com (Ryan Malayter) Date: Tue, 13 Mar 2012 04:49:39 -0700 (PDT) Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> Message-ID: <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> On Mar 13, 2:21?am, Masataka Ohta wrote: > William Herrin wrote: > >>> When I ran the numbers a few years ago, a route had a global cost > >>> impact in the neighborhood of $8000/year. It's tough to make a case > >>> that folks who need multihoming's reliability can't afford to put that > >>> much into the system. > > >> The cost for bloated DFZ routing table is not so small and is > >> paid by all the players, including those who use DFZ but do > >> not multihome. > > > Hi, > > >http://bill.herrin.us/network/bgpcost.html > > > If you believe there's an error in my methodology, feel free to take > > issue with it. > > Your estimate on the number of routers in DFZ: > > ? ? ? ? somewhere between 120,000 and 180,000 with the consensus > ? ? ? ? number near 150,000 > > is a result of high cost of routers and is inappropriate to > estimate global cost of a routing table entry. > > Because DFZ capable routers are so expensive, the actual > number of routers is so limited. > > If the number of routes in DFZ is, say, 100, many routers and > hosts will be default free For quite some time, a sub-$2000 PC running Linux/BSD has been able to cope with DFZ table sizes and handle enough packets per second to saturate two or more if the prevalent LAN interfaces of the day. The reason current routers in the core are so expensive is because of the 40 gigabit interfaces, custom ASICs to handle billions of PPS, esoteric features, and lack of competition. The fact that long-haul fiber is very expensive to run limits the number of DFZ routers more than anything else. Why not take a default route and simplify life when you're at the end of a single coax link? If your lucky enough to have access to fiber from multiple providers, the cost of a router which can handle a full table is not a major concern compared with your monthly recurring charges. -- RPM From mohta at necom830.hpcl.titech.ac.jp Tue Mar 13 08:03:39 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 13 Mar 2012 22:03:39 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> Message-ID: <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> Ryan Malayter wrote: >> If the number of routes in DFZ is, say, 100, many routers and >> hosts will be default free > > For quite some time, a sub-$2000 PC running Linux/BSD has been able to > cope with DFZ table sizes and handle enough packets per second to > saturate two or more if the prevalent LAN interfaces of the day. What if, you run windows? > The reason current routers in the core are so expensive is because of > the 40 gigabit interfaces, custom ASICs to handle billions of PPS, > esoteric features, and lack of competition. The point of http://bill.herrin.us/network/bgpcost.html was that routers are more expensive because of bloated routing table. If you deny it, you must deny its conclusion. > The fact that long-haul fiber is very expensive to run limits the > number of DFZ routers more than anything else. Given that global routing table is bloated because of site multihoming, where the site uses multiple ISPs within a city, costs of long-haul fiber is irrelevant. > Why not take a default > route and simplify life when you're at the end of a single coax link? That's fine. > If your lucky enough to have access to fiber from multiple providers, > the cost of a router which can handle a full table is not a major > concern compared with your monthly recurring charges. As it costs less than $100 per month to have fiber from a local ISP, having them from multiple ISPs costs a lot less is negligible compared to having routers with a so bloated routing table. Masataka Ohta From jgreco at ns.sol.net Tue Mar 13 08:41:21 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 13 Mar 2012 08:41:21 -0500 (CDT) Subject: Programmers with network engineering skills In-Reply-To: <20120313031812.EFD301E6E4AB@drugs.dv.isc.org> Message-ID: <201203131341.q2DDfLd1098884@aurora.sol.net> > > The ideal world contains a mix of techniques. > > > > You cannot just blindly leave it to the MTA to decide what's valid. > > Along that path lies madness. How do you pass the address to the MTA? > > Don't do it as a system() call unless you want someone to own your > > box with a semicolon. > > Only if you don't properly quote/escape the arguments you are passing. That's a great theory that's been a disaster in practice, as "properly" is difficult and mistakes often turn into exploits. That's not to say that you're not right, obviously you are, but that is kind of more of a sign of the scope of the problem than anything else. In an ideal world, it wouldn't be an issue. In reality, the set of allowed characters for e-mail addresses should probably have been a bit more controlled... ... 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 bicknell at ufp.org Tue Mar 13 08:48:05 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 13 Mar 2012 06:48:05 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> Message-ID: <20120313134805.GA41217@ussenterprise.ufp.org> In a message written on Tue, Mar 13, 2012 at 02:19:00PM +1100, Geoff Huston wrote: > On 13/03/2012, at 2:31 AM, Leo Bicknell wrote: > > It was never clear to me that even if it worked 100% as advertised that > > it would be cheaper / better in the global sense. > > I think that's asking too much of the IETF Leo - Shim6 went through much the > same process as most of the IETF work these days: bubble of thought, BOF sanity > check, requirements work, protocol prototyping, technology specification. I think you took my statement a bit too literally, as if I wanted a proof that shim6 would be cheaper than building larger routers. That would be asking way too much. However, shim6 for me never even passed the theoretical smell test economically. To make routers handle more DFZ routes basically means putting more memory in routers. It may be super fancy super expensive fast TCAM to handle the job, but at the end of the day it's pretty much just more memory, which means more money. There's a wild range of estimates as to how many DFZ routers there are out there, but it seems like the low end is 50,000 and the high end is 500,000. A lot of ram and a lot of money for sure, but as far as we can tell a tractable problem even with a growth rate much higher than we have now. Compare and contrast with shim6, even if you assume it does everything it was billed to do. First, it assumes we migrate everyone to IPv6, because it's not an IPv4 solution. Second, it assumes we update well, basically every since device with an IP stack. I'm guessing we're north of 5 billion IP devices in the world, and wouldn't be surprised if the number isn't more like 10 billion. Third, because it is a software solution, it will have to be patched/maintained/ported _forever_. I'm hard pressed in my head to rationalize how maintaining software for the next 50 years on a few billion or so boxes is cheaper in the global sense than adding memory to perhaps half a million routers. -- 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 jmaslak at antelope.net Tue Mar 13 10:03:48 2012 From: jmaslak at antelope.net (Joel Maslak) Date: Tue, 13 Mar 2012 09:03:48 -0600 Subject: Regex validation, was Re: Programmers with network engineering skills Message-ID: On Mon, Mar 12, 2012 at 9:18 PM, Mark Andrews wrote: > Only if you don't properly quote/escape the arguments you are passing. You're using your OS wrong if you are quoting/escaping the arguments. You do not need a shell involved to use fork() + exec() + wait(), as the shell is not involved (assuming Unix; I also suspect libc has a nice packaged function for this that is not insecure like system(), but it's not all that hard to roll your own). In Perl, use the multi-argument form of system(), not the single argument version(). In both cases you should clear the environment as well prior to the exec()/system() unless you know nobody can play with LD_PRELOAD, IFS, etc. This is one of my pet peeves about programming - programmers calling out to insecure functions when secure alternatives are available. The same goes for SQL statements - if you need to quote things to prevent SQL injection, you're using your SQL database wrong. Look up prepared statements. Generally, it's very bad practice to dynamically build SQL strings. It's also very common practice, hence why so many applications have SQL injection vulnerabilities. It's the Perl/PHP equivalent of the buffer overflow that simply wouldn't exist if developers, instead of trying to figure out how to quote everything, simply used prepared statements and placeholders. As for checking for bogus email addresses, read the RFC and code it right. That's not with a too-simple regex, nor is it with a complex regex. You need a parser, which is the right tool for the job. Regex is not. But there is value in not passing utter garbage to another program (it has a tendency to clog mail queues, if for no other reason) - just make sure you do it right. I might add that the same goes for names. People don't just have a first name and a last name - some people just have one name, some people have three or four names, some people have surnames with spaces, hypens, or apostrophes (remember what I said about SQL?!), etc. Yet most systems I see assume people have two names with no spaces, apostrophies, hyphens, etc. Big mistake. And don't get me started on addresses, which might have one address line, two address lines, even 5 address lines, to say nothing that international addresses may or may not put the "street" part first. It's certainly not easily regex-able. Okay, I'll step off the soap box and let the next person holler about how I was wrong about all this! From carlosm3011 at gmail.com Tue Mar 13 10:26:02 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Tue, 13 Mar 2012 12:26:02 -0300 Subject: Programmers with network engineering skills In-Reply-To: <51FDF739-7B10-43C6-949C-06C5802780B9@delong.com> References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <4F5E740E.5040505@paulgraydon.co.uk> <51FDF739-7B10-43C6-949C-06C5802780B9@delong.com> Message-ID: <4F5F670A.8050705@gmail.com> I may add that when I reached the point of having my 'AT cagnazzo.name' address rejected by the form, I was already pretty angry because the form had a sign, all written in UPPER CASE LETTERS, saying that the form did not support other browsers than Internet Explorer. :=) C. On 3/12/12 7:43 PM, Owen DeLong wrote: > I think this proves one thing... > > Given enough monkeys with typewriters, you will, in fact, not > get Shakespeare, but, instead, regular expressions for Shakespeare's > email address. > > Owen > > On Mar 12, 2012, at 3:09 PM, Paul Graydon wrote: > >> On 03/12/2012 09:46 AM, Tei wrote: >>> On 12 March 2012 09:59, Carlos Martinez-Cagnazzo wrote: >>>> Hey! >>>> >>>> On 3/8/12 8:24 PM, Lamar Owen wrote: >>>>> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote: >>>>> ... >>>>>> (16) The default gateway's IP address is always 192.168.0.1 >>>>>> (17) The user portion of E-mail addresses never contain special >>>>>> characters like "-" "+" "$" "~" "." ",", "[", "]" >>>> I've just had my ' xx AT cagnazzo.name' email address rejected by a web >>>> form saying that 'it is not a valid email address'. So I guess point >>>> (17) can be extended to say that 'no email address shall end in anything >>>> different that .com, .net or the local ccTLD' >>>> >>>> :=) >>>> >>>> Carlos >>> Yea, I don't even know how programmers can get that wrong. The regex >>> is not even hard or anything. >>> >>> >>> (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\]) >>> >>> >> It's supposedly a lot harder than that. Try this for strict RFC822 compliance (from http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html): >> >> (?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] >> )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?: >> \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:( >> ?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ >> \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0 >> 31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\ >> ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+ >> (?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?: >> (?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z >> |(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n) >> ?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\ >> r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ >> \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n) >> ?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t] >> )*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ >> \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])* >> )(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] >> )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*) >> *:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+ >> |\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r >> \n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?: >> \r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t >> ]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031 >> ]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]( >> ?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(? >> :(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(? >> :\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(? >> :(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)? >> [ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] >> \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]| >> \\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<> >> @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|" >> (?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t] >> )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ >> ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(? >> :[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[ >> \]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000- >> \031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|( >> ?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,; >> :\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([ >> ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\" >> .\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\ >> ]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\ >> [\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\ >> r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] >> \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\] >> |\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0 >> 00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\ >> .|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@, >> ;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(? >> :[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])* >> (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". >> \[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[ >> ^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\] >> ]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*( >> ?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ >> ".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:( >> ?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[ >> \["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t >> ])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t >> ])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(? >> :\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+| >> \Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?: >> [^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\ >> ]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n) >> ?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[" >> ()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n) >> ?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<> >> @,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ >> \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@, >> ;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t] >> )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ >> ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)? >> (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". >> \[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?: >> \r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[ >> "()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t]) >> *))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]) >> +|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\ >> .(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z >> |(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:( >> ?:\r\n)?[ \t])*))*)?;\s*) >> >> Paul > From Mike.Rae at sjrb.ca Tue Mar 13 10:36:28 2012 From: Mike.Rae at sjrb.ca (Mike Rae) Date: Tue, 13 Mar 2012 15:36:28 +0000 Subject: Email Integration / Account Migration In-Reply-To: <4F5F670A.8050705@gmail.com> References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <4F5E740E.5040505@paulgraydon.co.uk> <51FDF739-7B10-43C6-949C-06C5802780B9@delong.com> <4F5F670A.8050705@gmail.com> Message-ID: Hi : If there is anyone out there that has experience with migrating Email from one ISP to another at the retail level using products such as the "True Switch" product from ESAYA, and would be willing to share some thoughts/experiences, could you please contact me off list ? Thanks mike From nanog at techmonkeys.org Tue Mar 13 11:51:28 2012 From: nanog at techmonkeys.org (Jeff Fisher) Date: Tue, 13 Mar 2012 10:51:28 -0600 Subject: CISCO ASA Botnet Traffic Filter contact off-list Message-ID: <4F5F7B10.2040008@techmonkeys.org> Hi, Does anyone have a contact at CISCO that deals with their ASA botnet filtering software? I'm having trouble finding out why our network is listed. Thanks, Jeff From bill at herrin.us Tue Mar 13 12:26:10 2012 From: bill at herrin.us (William Herrin) Date: Tue, 13 Mar 2012 13:26:10 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> Message-ID: 2012/3/13 Masataka Ohta : > William Herrin wrote: >> http://bill.herrin.us/network/bgpcost.html >> >> If you believe there's an error in my methodology, feel free to take >> issue with it. > > Your estimate on the number of routers in DFZ: > > ? ? ? ?somewhere between 120,000 and 180,000 with the consensus > ? ? ? ?number near 150,000 > > is a result of high cost of routers and is inappropriate to > estimate global cost of a routing table entry. Hi, Please elaborate. In what way is the average cost of routers carrying the DFZ table an inappropriate variable in estimating the cost of the routing system? > Because DFZ capable routers are so expensive, the actual > number of routers is so limited. > > If the number of routes in DFZ is, say, 100, many routers and > hosts will be default free. If wishes were horses, beggars would ride. The number of routes in the DFZ isn't 100 and is trending north, not south. >>>> Often overlooked is that multihoming through multi-addressing could >>>> solve IP mobility too. >>> >>> Not. >>> >>> What is often overlooked is the fact that they are orthogonal >>> problems. >> >> I respectfully disagree. > > My statement is based on my experience to implement locator/ID > separation system with multi-address TCP and IP mobility. > > They need separate mechanisms and separate coding. I've been an IRTF RRG participant and in my day job I build backend systems for mobile messaging devices used in some very challenging and very global IP and non-IP environments. If we're done touting our respective qualifications to hold an opinion, let's get back to vetting the idea itself. >> Current mobility efforts have gone down a >> blind alley of relays from a home server and handoffs from one network >> to the next. And in all fairness, with TCP tightly bound to a >> particular IP address pair there aren't a whole lot of other options. >> Nevertheless, it's badly suboptimal. Latency and routing inefficiency >> rapidly increases with distance from the home node among other major >> problems. > > That is a mobility issue of triangle elimination having nothing > to do with TCP. Au contraire. Triangle elimination is a problem because the IP address can't change with session survivability. But that's because TCP and UDP require it. If A follows from B and B follows from C then A follows from C: TCP is at fault. >> But suppose you had a TCP protocol that wasn't statically bound to the >> IP address by the application layer. Suppose each side of the >> connection referenced each other by name, TCP expected to spread >> packets across multiple local and remote addresses, and suppose TCP, >> down at layer 4, expected to generate calls to the DNS any time it >> wasn't sure what addresses it should be talking to. > > Ignoring that DNS does not work so fast, TCP becomes "it wasn't > sure what addresses it should be talking to" only after a long > timeout. Says who? Our hypothetical TCP can become "unsure" as soon as the first retransmission if we want it to. It can even become unsure when handed a packet to send after a long delay with no traffic. There's little delay kicking off the recheck either way. >> And if >> the node gets even moderately good at predicting when it will lose >> availability for each network it connects to and/or when to ask the >> DNS again instead of continuing to try the known IP addresses you can > > What? A node asks DNS IP addresses of its peer, because the node > is changing its IP addresses? A re-verify by name lookup kicks off in a side thread any time the target threshold for a certainty heuristic is hit. Inputs into that heuristic include things like the TTL expiration of the prior lookup, the time since successful communication with the peer and the time spent retrying since the last successful communication with the peer. If you have any communication with the peer on any address pair, he can tell you what addresses should still be on your try-me list. If there's a reasonable chance that you've lost communication with the peer, then you ask the DNS server for the peer's latest information. >>> The only end to end way to handle multiple addresses is to let >>> applications handle them explicitly. >> >> For connection-oriented protocols, that's nonsense. Pick an >> appropriate mapping function and you can handle multiple layer 3 >> addresses just fine at layer 4. > > It will require the applications perform reverse mapping > function, when they require raw IP addresses. No. The application passes the IP address in a string the same way it passes a name. The layer 4 protocol figures out how it's going to map that to a name. It could do a reverse mapping. It could connect to the raw IP and request that the peer provide a name. There are several other strategies which could be used independently or as a group. But you avoid using them at the application level. Keep that operation under layer 4's control. >> For connectionless protocols, maybe. > > I'm afraid you are unaware of connected UDP. Your fears are unfounded. >> However, I'm not >> convinced that can't be reliably accomplished with a hinting process >> where the application tells layer 4 its best guess of which send()'s >> succeeded or failed and lets layer 4 figure out the resulting gory >> details of address selection. > > It's a lot easier for UDP-based applications directly manage > multiple IP addresses. I'll say it's fair to call that correct until disproven. However, it's worth noting that UDP is used to implement a lot of protocols which are connection-oriented but have characteristics (such as error tolerance and timely delivery requirements) which are inconsistent with TCP. Multiple address management for such protocols could almost certainly be handled below the application level, same as with other connection-oriented protocols. Regardless of the above, it might actually be worth defining a streaming data protocol to operate in parallel with UDP and TCP instead of being loaded on top of UDP. We probably know enough now Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Tue Mar 13 12:27:13 2012 From: bill at herrin.us (William Herrin) Date: Tue, 13 Mar 2012 13:27:13 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <20120313134805.GA41217@ussenterprise.ufp.org> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <20120313134805.GA41217@ussenterprise.ufp.org> Message-ID: On Tue, Mar 13, 2012 at 9:48 AM, Leo Bicknell wrote: > I'm hard pressed in my head to rationalize how maintaining software for > the next 50 years on a few billion or so boxes is cheaper in the global > sense than adding memory to perhaps half a million routers. For a one-order of magnitude increase in "routes," (upper bound of $30B/year the BGP way) it may or may not be. For a four orders increase ($30T/year) it's self-evidently cheaper to change software on the billion or so boxes. How many "routes" would a system improvement that radically reduced the cost per route add? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From walter.keen at rainierconnect.net Tue Mar 13 12:54:08 2012 From: walter.keen at rainierconnect.net (Walter Keen) Date: Tue, 13 Mar 2012 10:54:08 -0700 (PDT) Subject: SNMP monitoring of routing tables In-Reply-To: <809518631.1222816.1331661237937.JavaMail.root@zimbra01.rainierconnect.net> Message-ID: <1323786824.1222817.1331661248220.JavaMail.root@zimbra01.rainierconnect.net> Trying to work on an interesting project, where it would be nice to monitor the routing table of a collection of routers, store it, and look at it later, as a snapshot of what the routing table for a particular router looked at a particular time. All the information I'm wanting (route entry, nexthop, etc) is available via snmp on the ip-route mib I believe, and needs to stay fairly generic, or equipment-agnostic. Does anyone know of an existing project to do this before I start trying to make one? Walter Keen From arturo.servin at gmail.com Tue Mar 13 13:17:14 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Tue, 13 Mar 2012 12:17:14 -0600 Subject: SNMP monitoring of routing tables In-Reply-To: <1323786824.1222817.1331661248220.JavaMail.root@zimbra01.rainierconnect.net> References: <1323786824.1222817.1331661248220.JavaMail.root@zimbra01.rainierconnect.net> Message-ID: <7EF9B6DF-37EF-4095-97E4-300DDBD773B6@gmail.com> Try RIS from RIPE NCC or routeviews. regards, as Sent from my mobile device (please excuse typoss and brevit.) On 13 Mar 2012, at 11:54, Walter Keen wrote: > > Trying to work on an interesting project, where it would be nice to monitor the routing table of a collection of routers, store it, and look at it later, as a snapshot of what the routing table for a particular router looked at a particular time. All the information I'm wanting (route entry, nexthop, etc) is available via snmp on the ip-route mib I believe, and needs to stay fairly generic, or equipment-agnostic. > > > Does anyone know of an existing project to do this before I start trying to make one? > > Walter Keen From bicknell at ufp.org Tue Mar 13 13:15:34 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 13 Mar 2012 11:15:34 -0700 Subject: SNMP monitoring of routing tables In-Reply-To: <1323786824.1222817.1331661248220.JavaMail.root@zimbra01.rainierconnect.net> References: <809518631.1222816.1331661237937.JavaMail.root@zimbra01.rainierconnect.net> <1323786824.1222817.1331661248220.JavaMail.root@zimbra01.rainierconnect.net> Message-ID: <20120313181534.GA54670@ussenterprise.ufp.org> In a message written on Tue, Mar 13, 2012 at 10:54:08AM -0700, Walter Keen wrote: > Trying to work on an interesting project, where it would be nice to monitor the routing table of a collection of routers, store it, and look at it later, as a snapshot of what the routing table for a particular router looked at a particular time. All the information I'm wanting (route entry, nexthop, etc) is available via snmp on the ip-route mib I believe, and needs to stay fairly generic, or equipment-agnostic. > > > Does anyone know of an existing project to do this before I start trying to make one? RIPE's RIS and Route-View's both archive BGP tables and you can download them and manipulate them. There are several other services that archive the data, like Renesys, but don't provide raw data downloads. SNMP is really a non-starter for this work. Too slow, the table changes out from under you, plus it's hugely inefficient. -- 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 mike.lyon at gmail.com Tue Mar 13 13:22:59 2012 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 13 Mar 2012 11:22:59 -0700 Subject: Email Integration / Account Migration In-Reply-To: References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <4F5E740E.5040505@paulgraydon.co.uk> <51FDF739-7B10-43C6-949C-06C5802780B9@delong.com> <4F5F670A.8050705@gmail.com> Message-ID: I've successfully used YippieMove in the past migrating from Google Apps to Exchange. http://www.yippiemove.com/ -Mike On Tue, Mar 13, 2012 at 8:36 AM, Mike Rae wrote: > Hi : > > If there is anyone out there that has experience with migrating Email from > one ISP to another at the retail level using products such as the "True > Switch" product from ESAYA, and would be willing to share some > thoughts/experiences, could you please contact me off list ? > > Thanks > mike > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From me at anuragbhatia.com Tue Mar 13 13:30:19 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 14 Mar 2012 00:00:19 +0530 Subject: Email Integration / Account Migration In-Reply-To: References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <4F5E740E.5040505@paulgraydon.co.uk> <51FDF739-7B10-43C6-949C-06C5802780B9@delong.com> <4F5F670A.8050705@gmail.com> Message-ID: Hello Mike You can look for my friends form shuttlecloud.com They are much into hard core data migration. On Tue, Mar 13, 2012 at 9:06 PM, Mike Rae wrote: > Hi : > > If there is anyone out there that has experience with migrating Email from > one ISP to another at the retail level using products such as the "True > Switch" product from ESAYA, and would be willing to share some > thoughts/experiences, could you please contact me off list ? > > Thanks > mike > > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From J.Bontje at cordares.nl Tue Mar 13 13:43:42 2012 From: J.Bontje at cordares.nl (Bontje, Juan Carlos) Date: Tue, 13 Mar 2012 19:43:42 +0100 Subject: SNMP monitoring of routing tables In-Reply-To: <1323786824.1222817.1331661248220.JavaMail.root@zimbra01.rainierconnect.net> References: <1323786824.1222817.1331661248220.JavaMail.root@zimbra01.rainierconnect.net> Message-ID: <6FE91B7F-AEE4-445D-8AE6-83EC620B2A73@cordares.nl> Hi I use bgpmon.net That include among others ripe ris info Might be worth to have look at that Cheers JC Sent from whatever On 13 Mar 2012, at 19:00, "Walter Keen" wrote: > > Trying to work on an interesting project, where it would be nice to monitor the routing table of a collection of routers, store it, and look at it later, as a snapshot of what the routing table for a particular router looked at a particular time. All the information I'm wanting (route entry, nexthop, etc) is available via snmp on the ip-route mib I believe, and needs to stay fairly generic, or equipment-agnostic. > > > Does anyone know of an existing project to do this before I start trying to make one? > > Walter Keen > > De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen. Cordares Holding NV is gevestigd te Amsterdam en is ingeschreven in het handelsregister van de Kamer van Koophandel onder nummer 33276459. The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission. Cordares Holding NV is located in Amsterdam and is registered at the trade register of the Chamber of Commerce with number 33276459. --------------------- From owen at delong.com Tue Mar 13 14:20:23 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 13 Mar 2012 12:20:23 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <20120313134805.GA41217@ussenterprise.ufp.org> Message-ID: <82A51D90-EE9C-433B-B6CD-F8222CAFEED0@delong.com> It's _WAY_ more than a billion boxes at this point. Owen On Mar 13, 2012, at 10:27 AM, William Herrin wrote: > On Tue, Mar 13, 2012 at 9:48 AM, Leo Bicknell wrote: >> I'm hard pressed in my head to rationalize how maintaining software for >> the next 50 years on a few billion or so boxes is cheaper in the global >> sense than adding memory to perhaps half a million routers. > > For a one-order of magnitude increase in "routes," (upper bound of > $30B/year the BGP way) it may or may not be. For a four orders > increase ($30T/year) it's self-evidently cheaper to change software on > the billion or so boxes. How many "routes" would a system improvement > that radically reduced the cost per route add? > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From owen at delong.com Tue Mar 13 14:18:33 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 13 Mar 2012 12:18:33 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> Message-ID: On Mar 13, 2012, at 6:03 AM, Masataka Ohta wrote: > Ryan Malayter wrote: > >>> If the number of routes in DFZ is, say, 100, many routers and >>> hosts will be default free >> >> For quite some time, a sub-$2000 PC running Linux/BSD has been able to >> cope with DFZ table sizes and handle enough packets per second to >> saturate two or more if the prevalent LAN interfaces of the day. > > What if, you run windows? > Why would you want to run windows on a box you're trying to use as a router? That's like trying to invade Fort Knox with a bag of plastic soldiers. Leo's point is that you can build/buy a DFZ capable router for less than $2,000. If you run windows, the box will be more expensive, less capable, and less reliable. If that's what you want, knock yourself out, but, it's hardly relevant to the discussion at hand. >> The reason current routers in the core are so expensive is because of >> the 40 gigabit interfaces, custom ASICs to handle billions of PPS, >> esoteric features, and lack of competition. > > The point of > > http://bill.herrin.us/network/bgpcost.html > > was that routers are more expensive because of bloated routing > table. > > If you deny it, you must deny its conclusion. > To a certain extent you are right. I believe that Bill's analysis and his conclusions are deeply flawed in many ways. However, he is marginally correct in that the high cost of core DFZ routers is the product of the large forwarding table multiplied by the cost per forwarding entry in a high-pps high-data-rate system. Further adding to this is the fact that high-rate (pps,data) routers generally need to distribute copies of the FIB to each line card so the cost per forwarding entry is further multiplied by the number of line cards (and in some cases, the number of modules installed on each line card). >> The fact that long-haul fiber is very expensive to run limits the >> number of DFZ routers more than anything else. > > Given that global routing table is bloated because of site > multihoming, where the site uses multiple ISPs within a city, > costs of long-haul fiber is irrelevant. > Long-haul meaning anything that leaves the building. Yes, it's a poor choice of terminology, but, if you prefer, the costs of last- mile fiber apply equally to Leo's point. >> Why not take a default >> route and simplify life when you're at the end of a single coax link? > > That's fine. > >> If your lucky enough to have access to fiber from multiple providers, >> the cost of a router which can handle a full table is not a major >> concern compared with your monthly recurring charges. > > As it costs less than $100 per month to have fiber from a > local ISP, having them from multiple ISPs costs a lot less > is negligible compared to having routers with a so bloated > routing table. $100/month * 2 = $200/month. $200/month pays for a DFZ capable router every year. That's means that the cost of 2*fiber costs quite a bit more than the cost of the router. There is a difference between a DFZ router and a core router. I personally run a DFZ router for my personal AS. I don't personally own or run a core router for my personal AS. The fact that people conflate the idea of a DFZ router with the idea of a core router is part of the problem and a big part of where Bill's cost structure analysis breaks, as you pointed out. Small to medium businesses that want to multihome can easily do so with relatively small investments in equipment which are actually negligible compared to the telecom costs for the multiple connections. Owen From jgreco at ns.sol.net Tue Mar 13 15:33:37 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 13 Mar 2012 15:33:37 -0500 (CDT) Subject: Programmers with network engineering skills In-Reply-To: <4F5EEE4E.2050807@mompl.net> Message-ID: <201203132033.q2DKXbj5003105@aurora.sol.net> > Joe Greco wrote: > > The ideal world contains a mix of techniques. > > Yes and copying parts of relevant code of an MTA could be one. May actually be one of the few sane ones. > > You cannot just blindly leave it to the MTA to decide what's valid. > > Along that path lies madness. How do you pass the address to the MTA? > > Don't do it as a system() call unless you want someone to own your > > box with a semicolon. > > Well, the whole world can pass whatever it wants to an MTA, it's > supposed to be listening on internet facing port 25 all the time, that's > it's mean reason of existence. An MTA is particularly well suited to > take any kind of abuse, because that's exactly what it's expecting. > > Unless in cases such as Owen mentioned I'd say it's a pretty good > solution. The madness to me lies in making your own email validating code... This is probably one of those things where the spec was good when it was written for reasons that were good at the time, but now many years later in a generally completely FQDN-ified world, there's little valid reason to need to be able to support some of the odd possible syntaxes that we used twenty or thirty years ago. The problem is, current programmers look at the evil spec, say "fooey with that," and then code up something that is too unreasonably restrictive in the opposite direction. ... 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 malayter at gmail.com Tue Mar 13 16:21:27 2012 From: malayter at gmail.com (Ryan Malayter) Date: Tue, 13 Mar 2012 14:21:27 -0700 (PDT) Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> Message-ID: <4e4684f9-1274-4f91-a506-7ceb5651ff9c@g16g2000yqe.googlegroups.com> On Mar 13, 2:18?pm, Owen DeLong wrote: > On Mar 13, 2012, at 6:03 AM, Masataka Ohta wrote: > > > Ryan Malayter wrote: > > >>> If the number of routes in DFZ is, say, 100, many routers and > >>> hosts will be default free > > >> For quite some time, a sub-$2000 PC running Linux/BSD has been able to > >> cope with DFZ table sizes and handle enough packets per second to > >> saturate two or more if the prevalent LAN interfaces of the day. > > > What if, you run windows? > > Why would you want to run windows on a box you're trying to use as a > router? That's like trying to invade Fort Knox with a bag of plastic soldiers. Check your quoting depth... you're attributing Masataka Ohta's comments to me, he brought up running windows. I am the one who brought put forward the notion of a sub-$2000 DFZ router. From david at davidswafford.com Tue Mar 13 16:30:40 2012 From: david at davidswafford.com (David Swafford) Date: Tue, 13 Mar 2012 17:30:40 -0400 Subject: SNMP monitoring of routing tables In-Reply-To: <6FE91B7F-AEE4-445D-8AE6-83EC620B2A73@cordares.nl> References: <1323786824.1222817.1331661248220.JavaMail.root@zimbra01.rainierconnect.net> <6FE91B7F-AEE4-445D-8AE6-83EC620B2A73@cordares.nl> Message-ID: Does anyone know of a similar tool (opensource/low cost) for the IGPs? It would be really cool to have a snapshot for troubleshooting post-mortem. Thanks! David. On Tue, Mar 13, 2012 at 2:43 PM, Bontje, Juan Carlos wrote: > > Hi > I use bgpmon.net > That include among others ripe ris info > Might be worth to have look at that > > Cheers > JC > > Sent from whatever > > On 13 Mar 2012, at 19:00, "Walter Keen" > wrote: > > > > > Trying to work on an interesting project, where it would be nice to > monitor the routing table of a collection of routers, store it, and look at > it later, as a snapshot of what the routing table for a particular router > looked at a particular time. All the information I'm wanting (route entry, > nexthop, etc) is available via snmp on the ip-route mib I believe, and > needs to stay fairly generic, or equipment-agnostic. > > > > > > Does anyone know of an existing project to do this before I start trying > to make one? > > > > Walter Keen > > > > > De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend > bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, > verzoeken wij u contact op te nemen met de afzender per kerende e-mail. > Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de > inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen > aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging > van de inhoud van een verzonden e-mailbericht, noch voor daarbij > overgebrachte virussen. Cordares Holding NV is gevestigd te Amsterdam en is > ingeschreven in het handelsregister van de Kamer van Koophandel onder > nummer 33276459. > > The information contained in this e-mail is confidential and may be > privileged. It may be read, copied and used only by the intended recipient. > If you have received it in error, please contact the sender immediately by > return e-mail; please delete in this case the e-mail and do not disclose > its contents to any person. We don't accept liability for any errors, > omissions, delays of receipt or viruses in the contents of this message > which arise as a result of e-mail transmission. Cordares Holding NV is > located in Amsterdam and is registered at the trade register of the Chamber > of Commerce with number 33276459. > > --------------------- > > > From blake at pfankuch.me Tue Mar 13 16:34:02 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Tue, 13 Mar 2012 21:34:02 +0000 Subject: Xirrus Wireless Message-ID: I know this is a little outside of the traditional NANOG realm but... I have a customer looking at a fair number of Xirrus Wireless Arrays for 802.11a/b/g/n implementations and am looking for some real world insight into them. On the cover they look cool, the white papers look cool, but I am yet to find technical commentary from a real person on these devices. Looking at the XN line, and just curious if anyone has deployed these, supports these or knows anything about them. Thanks! Blake From kc at caida.org Tue Mar 13 16:56:14 2012 From: kc at caida.org (k claffy) Date: Tue, 13 Mar 2012 14:56:14 -0700 Subject: CAIDA's 2012 IPv6 survey -- need network operators to fill out Message-ID: <20120313215614.GA39216@caida.org> [direct link to IPv6 operational deployment [plans] survey if you don't need background: http://www.surveygizmo.com/s3/749797/ipv6survey ] hello folks, we're trying to do some quantitative modeling of the IPv4->IPv6 transition, including the impact of IPv4 markets on likely future trajectories, but really need some empirical data to parametrize our model. with much help from many patient reviewers of the questions, we finally have a survey ready for operators to fill out. below i'll give an extremely terse description of the model just to give you an idea of why we need this granularity. there are another 10 dense pages describing the model pending peer review at NSF, which i can send to anyone interested in giving us feedback on it. but it's not necessary for responding to the survey. also note the checkbox to indicate you're amenable to further followup questions. survey will be available till 12 april 2012. (or tell us if you want to fill it out but need more time.) survey link, again: http://www.surveygizmo.com/s3/749797/ipv6survey thanks much, k, amogh, emile ------------------------------ Most prior work on modeling the adoption of new technologies assumed a binary decision at the organization level -- in the context of IPv6, this decision means switching completely to IPv6 or not at all. We propose to account for the fact that an organization may deploy IPv6 incrementally in its network, meaning that it will continue to have both IPv4 and IPv6 space. A key aspect of our model is that instead of a binary state per organization, we work at the granularity of devices, which are entities that need to be assigned IP addresses. We consider a device to correspond to a single instance of an IP addressing need, which typically corresponds to an interface. Though there can be multiple interfaces (``devices'') on the same computer/router, and multiple addresses (``virtual interfaces'') on a single interface, we will model each need for an independent IP address as an independent device. We define device classes based on the nature of addresses used to number those devices, e.g., public IPv4, IPv6, dual-stack-NATv4, dual-stack-public-IPv4, etc. We model the network growth requirements of each network in terms of the number of additional devices in that network that need to be configured in one of these device classes. ... (then we catalog a list of costs and incentives associated with the decision to adopt IPv6 or satisfy one's addressing needs with IPv4-based technologies. costs parameters include the costs of IPv4 addresses, NAT deployment, renumbering, and translation between IPv4 and IPv6. we will also try to model incentives such as policies and regulations.) We will then model two separate decision processes for a network, based on whether it seeks to add new devices (to expand its network, provision for new customers, deploy new services, etc.), or whether it seeks to optimize the numbering of its existing devices from among the five device classes defined previously. The latter operation may be necessary if external factors and costs have changed such that the network could substantially lower its costs by numbering its devices differently. We want to structure the model (based on feedback from opsfolk like you) to capture both initial costs as well as ongoing operational costs of supporting a given configuration of devices for a specified window following the decision. Iteration of the decision process continues for each network until we reach a state where no network has the incentive to change the numbering of its devices, which represents the equilibrium. .... From malayter at gmail.com Tue Mar 13 17:06:56 2012 From: malayter at gmail.com (Ryan Malayter) Date: Tue, 13 Mar 2012 15:06:56 -0700 (PDT) Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> Message-ID: <386ca181-dbc5-4ce1-9cd7-6af4dbe047ec@s7g2000yqm.googlegroups.com> On Mar 13, 8:03?am, Masataka Ohta wrote: > The point of > ? ? ? ?http://bill.herrin.us/network/bgpcost.html > was that routers are more expensive because of bloated routing > table. > If you deny it, you must deny its conclusion. Bill's analysis is quite interesting, but my initial take is that it is somehwat flawed. It assumes that the difference between what Cisco charges for a 7606 and a 3750G bears some resemblance to the actual bill of materials needed to support the larger routing table. That simply isn't the case: Cisco rightly charges what they think the market will bear for their routers and switches. I think a more realistic approach would be to use the cost differential between a router model X that supports 1M routes the same model configured to support 2M routes. Or perhaps we could look at the street prices for TCAM expansion modules. Either would be a better indicator of the incremental cost attributable to routing table size. The majority of costs in a mid-to-high-end Cisco/Juniper chassis are "sunk" and have nothing to do with the size of the routing table. The expensive routers currently used by providers are expensive because the market isn't that big in quantity, so they are not commodity items. They are designed to maximize the utility of very expensive long-haul fibers and facilities to a service provider. This means providing a high density of high-speed interfaces which can handle millions to billions of packets per second. They also provide lots of features that service providers and large enterprises want, sometimes in custom ASICs. These are features which have nothing to do with the size of the DFZ routing table, but significantly impact the cost of the device. > Given that global routing table is bloated because of site > multihoming, where the site uses multiple ISPs within a city, > costs of long-haul fiber is irrelevant. I suppose smaller multi-homed sites can and often do take a full table, but they don't *need* to do so. What they do need is their routes advertised to the rest of the internet, which means they must be in the fancy-and-currently-expensive routers somewhere upstream. This is where the cost of long-haul fiber becomes relevant: Until we can figure out how dig cheaper ditches and negotiate cheaper rights-of- way, there will not be an explosion of the number of full-table provider edge routers, because there are only so many interconnection points where they are needed. Incremental growth, perhaps, but physical infrastructure cannot follow an exponential growth curve. > As it costs less than $100 per month to have fiber from a > local ISP, having them from multiple ISPs costs a lot less > is negligible compared to having routers with a so bloated > routing table. For consumer connections, a sub-$1000 PC would serve you fine with a full table given the level of over-subscription involved. Even something like Quagga or Vyatta running in a virutal machine would suffice. Or a Linksys with more RAM. Getting your providers to speak BGP with you on such a connection for that same $100/month will be quite a feat. Even in your contrived case, however, the monthly recurring charges exceed a $1000 router cost after a few months. Enterprises pay several thousand dollars per month per link for quality IP transit at Gigabit rates. From randy at psg.com Tue Mar 13 17:14:41 2012 From: randy at psg.com (Randy Bush) Date: Wed, 14 Mar 2012 07:14:41 +0900 Subject: SNMP monitoring of routing tables In-Reply-To: References: <1323786824.1222817.1331661248220.JavaMail.root@zimbra01.rainierconnect.net> <6FE91B7F-AEE4-445D-8AE6-83EC620B2A73@cordares.nl> Message-ID: > Does anyone know of a similar tool (opensource/low cost) for the IGPs? packet design randy From randy at psg.com Tue Mar 13 17:16:20 2012 From: randy at psg.com (Randy Bush) Date: Wed, 14 Mar 2012 07:16:20 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> Message-ID: > Yes, the economics of routing are strange, and the lack of any real > strictures in the routing tables are testament to the observation that > despite more than two decades of tossing the idea around we've yet to > find the equivalent of a "route deaggregation tax" or a "route > advertisement tax" or any other mechanism that effectively turns the > routing space into a form of market that imposes some economic > constraints on the activity. among other things, i suspect that the shadow of telco settlements makes us shy away from this. randy From steve.bertrand at gmail.com Tue Mar 13 17:20:15 2012 From: steve.bertrand at gmail.com (Steve Bertrand) Date: Tue, 13 Mar 2012 18:20:15 -0400 Subject: Programmers with network engineering skills In-Reply-To: <201203132033.q2DKXbj5003105@aurora.sol.net> References: <201203132033.q2DKXbj5003105@aurora.sol.net> Message-ID: <4F5FC81F.4080009@gmail.com> On 2012-03-13 16:33, Joe Greco wrote: >> Joe Greco wrote: >>> The ideal world contains a mix of techniques. >> >> Yes and copying parts of relevant code of an MTA could be one. > > May actually be one of the few sane ones. > >>> You cannot just blindly leave it to the MTA to decide what's valid. >>> Along that path lies madness. How do you pass the address to the MTA? >>> Don't do it as a system() call unless you want someone to own your >>> box with a semicolon. >> >> Well, the whole world can pass whatever it wants to an MTA, it's >> supposed to be listening on internet facing port 25 all the time, that's >> it's mean reason of existence. An MTA is particularly well suited to >> take any kind of abuse, because that's exactly what it's expecting. imo, this discussion of outbound SMTP has been sounding akin to me saying I should let my upstream ensure that all of my BGP announcements are good, instead of filtering my own outbound. >> Unless in cases such as Owen mentioned I'd say it's a pretty good >> solution. The madness to me lies in making your own email validating code... > > This is probably one of those things where the spec was good when it > was written for reasons that were good at the time, but now many years > later in a generally completely FQDN-ified world, there's little valid > reason to need to be able to support some of the odd possible syntaxes > that we used twenty or thirty years ago. > > The problem is, current programmers look at the evil spec, say "fooey > with that," and then code up something that is too unreasonably > restrictive in the opposite direction. There are ready-made solutions that abstract away the need for the programmer to write their own regex or compliance checks to meet the specs. In Perl for example, there is Email::Valid. One line of code and you know whether the address is to RFC or not. Less bugs and changes, I feel it is better to give the remote host known-good data then have to have them tell me it is bad. Steve disclaimer: I've wrote patches for said module over the years, and I named it only for example purposes. From streiner at cluebyfour.org Tue Mar 13 17:26:49 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 13 Mar 2012 18:26:49 -0400 (EDT) Subject: Verizon FiOS - is BGP an option? Message-ID: All: I realize this might be a bit of a fool's errand, but I'm trying to determine if Verizon will speak BGP with FiOS business customers. Their website is relatively lean on details. Everything that mentions BGP points to VZB services, which does not appear to include FiOS. Looking at the routing table, I do see several non-VZ ASNs downstream of AS19262, so it looks like it might be possible. If that is the case, could anyone lend any insight to get past the "what is BGP?" response that likely awaits from their salescritters? jms From pete at altadena.net Tue Mar 13 17:32:15 2012 From: pete at altadena.net (Pete Carah) Date: Tue, 13 Mar 2012 15:32:15 -0700 Subject: Xirrus Wireless In-Reply-To: References: Message-ID: <4F5FCAEF.8060109@altadena.net> On 03/13/2012 02:34 PM, Blake Pfankuch wrote: > I know this is a little outside of the traditional NANOG realm but... > > I have a customer looking at a fair number of Xirrus Wireless Arrays for 802.11a/b/g/n implementations and am looking for some real world insight into them. On the cover they look cool, the white papers look cool, but I am yet to find technical commentary from a real person on these devices. Looking at the XN line, and just curious if anyone has deployed these, supports these or knows anything about them. I can only speak from indirect experience; the rehab place where my wife is staying for a bit uses 4 or 5 of them (older, probably not current, flying-saucer-like boxes suspended from the ceiling at hallway junctions) and there, at least, they appear to work pretty well. The particular ones don't appear to my laptop to do 11a. However, I don't think there is any significant user density just from watching the nifty directional light display, so this may not mean much (I'd guess 3 to 10 users over the whole building including smartphones and a couple of pieces of medical equipment that isn't used much). Also there is no IT (or any real technical maint) guy on-premises to talk to so I can't ask about any other aspect. The local real hospital uses a Cisco system (or at least Cisco APs; don't know about the AP manager box) which really does appear to work well; I'd guess several hundred APs with lots of full-time medical gear, and a "guest" network which is behind a rather draconian firewall (wouldn't let me ssh out to a non-standard port (65k range), for example; I had to fix myself a 443 ssh port for the time we spent there a couple of months ago... Blocked 25 outgoing; I don't blame them for that, however they also blocked 465 (but allowed 587)). I suspect if I wanted 2.4-only I'd go with ubiquiti, but I don't have any experience with them, and their "unifi" boxes don't (yet) come in 5gig. And they don't appear to have independent APs in each box, though I don't know how well the "directional" antennas in the Xirrus actually separate things; even a 100mw transmitter may well overwhelm all the other local receivers unless there is a bunch of shielding inside the enclosure (and maybe even then...) If 802.11 was frequency-split like the cell system it would help such systems a bunch. -- Pete > Thanks! > > Blake > From gih at apnic.net Tue Mar 13 17:41:06 2012 From: gih at apnic.net (Geoff Huston) Date: Wed, 14 Mar 2012 09:41:06 +1100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> Message-ID: <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> On 14/03/2012, at 9:16 AM, Randy Bush wrote: >> Yes, the economics of routing are strange, and the lack of any real >> strictures in the routing tables are testament to the observation that >> despite more than two decades of tossing the idea around we've yet to >> find the equivalent of a "route deaggregation tax" or a "route >> advertisement tax" or any other mechanism that effectively turns the >> routing space into a form of market that imposes some economic >> constraints on the activity. > > among other things, i suspect that the shadow of telco settlements makes > us shy away from this. Agreed. It's all ugly! The shadow of telco settlement nonsense, the entire issue of route pull vs route push, and the spectre of any such payments morphing into a coerced money flow towards to the so-called tier 1 networks all make this untenable. The topic has been coming up pretty regularly every 2 years since about 1994 to my knowledge, and probably earlier, and has never managed to get anywhere useful. Geoff From pete at altadena.net Tue Mar 13 17:46:13 2012 From: pete at altadena.net (Pete Carah) Date: Tue, 13 Mar 2012 15:46:13 -0700 Subject: Xirrus Wireless In-Reply-To: References: <4F5FCAEF.8060109@altadena.net> Message-ID: <4F5FCE35.6020906@altadena.net> On 03/13/2012 03:35 PM, Blake Pfankuch wrote: > Thanks Pete, that does help. Now hopefully I can get someone who has experience with 500+ devices running on a single one in a fairly small area (High School Gym). There was a thread about this a couple of months back, I'm pretty sure it was after last November (but not absolutely sure); lots of discussion about density and Xirrrus was mentioned. My personal experience with Xirrus is certainly not high-density, and the "real" hospital certainly copes with a bunch (though I'm guessing 20-30 users per AP from how many APs they have distributed among rooms. They seem to do a bunch of their device telemetry on 802.11 but there are also some more dedicated frequencies/protocols for medical devices. (even the IV pumps alarm at the nurse's station...) I do have some experience with full-duplex RF transceiver design, though, and the Xirrus configuration can't be easy to make work well. Not impossible, but difficult. -- Pete > > -----Original Message----- > From: Pete Carah [mailto:pete at altadena.net] > Sent: Tuesday, March 13, 2012 4:32 PM > To: nanog at nanog.org > Subject: Re: Xirrus Wireless > > On 03/13/2012 02:34 PM, Blake Pfankuch wrote: >> I know this is a little outside of the traditional NANOG realm but... >> >> I have a customer looking at a fair number of Xirrus Wireless Arrays for 802.11a/b/g/n implementations and am looking for some real world insight into them. On the cover they look cool, the white papers look cool, but I am yet to find technical commentary from a real person on these devices. Looking at the XN line, and just curious if anyone has deployed these, supports these or knows anything about them. > I can only speak from indirect experience; the rehab place where my wife is staying for a bit uses 4 or 5 of them (older, probably not current, flying-saucer-like boxes suspended from the ceiling at hallway > junctions) and there, at least, they appear to work pretty well. The particular ones don't appear to my laptop to do 11a. However, I don't think there is any significant user density just from watching the nifty directional light display, so this may not mean much (I'd guess 3 to 10 users over the whole building including smartphones and a couple of pieces of medical equipment that isn't used much). Also there is no IT (or any real technical maint) guy on-premises to talk to so I can't ask about any other aspect. > > The local real hospital uses a Cisco system (or at least Cisco APs; don't know about the AP manager box) which really does appear to work well; I'd guess several hundred APs with lots of full-time medical gear, and a "guest" network which is behind a rather draconian firewall (wouldn't let me ssh out to a non-standard port (65k range), for example; I had to fix myself a 443 ssh port for the time we spent there a couple of months ago... Blocked 25 outgoing; I don't blame them for that, however they also blocked 465 (but allowed 587)). > > I suspect if I wanted 2.4-only I'd go with ubiquiti, but I don't have any experience with them, and their "unifi" boxes don't (yet) come in 5gig. And they don't appear to have independent APs in each box, though I don't know how well the "directional" antennas in the Xirrus actually separate things; even a 100mw transmitter may well overwhelm all the other local receivers unless there is a bunch of shielding inside the enclosure (and maybe even then...) If 802.11 was frequency-split like the cell system it would help such systems a bunch. > > -- Pete > >> Thanks! >> >> Blake >> > > From randy at psg.com Tue Mar 13 17:58:30 2012 From: randy at psg.com (Randy Bush) Date: Wed, 14 Mar 2012 07:58:30 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> Message-ID: >>> Yes, the economics of routing are strange, and the lack of any real >>> strictures in the routing tables are testament to the observation >>> that despite more than two decades of tossing the idea around we've >>> yet to find the equivalent of a "route deaggregation tax" or a >>> "route advertisement tax" or any other mechanism that effectively >>> turns the routing space into a form of market that imposes some >>> economic constraints on the activity. >> >> among other things, i suspect that the shadow of telco settlements >> makes us shy away from this. > > Agreed. It's all ugly! > > The shadow of telco settlement nonsense, the entire issue of route > pull vs route push, and the spectre of any such payments morphing into > a coerced money flow towards to the so-called tier 1 networks all make > this untenable. > > The topic has been coming up pretty regularly every 2 years since > about 1994 to my knowledge, and probably earlier, and has never > managed to get anywhere useful. so we are left with o name and shame, and we have seen how unsucsessful that has been. the polluters have no shame. o operational incentives. peers' and general routing filters were the classic dis-incentive to deaggregate. but the droids cave in the minute the geeks leave the room (ntt/verio caved within a month or two of my departure). o router hacks. we have had tickets open for many years asking for knob variations on 'if it is covered (from same peer, from same origin, ...), drop it.' none of which seem to move us forward. i guess the lesson is that, as long as we are well below moore, we just keep going down the slippery, and damned expensive, slope. randy From bill at herrin.us Tue Mar 13 18:03:16 2012 From: bill at herrin.us (William Herrin) Date: Tue, 13 Mar 2012 19:03:16 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: On Tue, Mar 13, 2012 at 6:26 PM, Justin M. Streiner wrote: > I realize this might be a bit of a fool's errand, but I'm trying to > determine if Verizon will speak BGP with FiOS business customers. ?Their > website is relatively lean on details. ?Everything that mentions BGP points > to VZB services, which does not appear to include FiOS. ?Looking at the > routing table, I do see several non-VZ ASNs downstream of AS19262, so it > looks like it might be possible. > > If that is the case, could anyone lend any insight to get past the "what is > BGP?" response that likely awaits from their salescritters? No. If you want to do BGP with Verizon, you have to buy a T1 at 10 times the cost and 1/10th of the speed. Though I'd love to discover I'm mistaken about that. :) Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nanogwp at gmail.com Tue Mar 13 18:08:27 2012 From: nanogwp at gmail.com (Robert Lusby) Date: Tue, 13 Mar 2012 23:08:27 +0000 Subject: Telstra contact Message-ID: <4F5FD36B.50405@gmail.com> Anyone from the Telstra NOC lurking - or can pass on a Telstra technical contact? Having no luck through the usual channels. Looking to utilise some data from some cables you have lurking around. Ideally someone with global net ops insight rather than local coverage. Many thanks, Robert. From tknchris at gmail.com Tue Mar 13 18:09:31 2012 From: tknchris at gmail.com (chris) Date: Tue, 13 Mar 2012 19:09:31 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: Haha true that. How else would.they.push their atm and.Ethernet products. chris On Mar 13, 2012 7:04 PM, "William Herrin" wrote: > On Tue, Mar 13, 2012 at 6:26 PM, Justin M. Streiner > wrote: > > I realize this might be a bit of a fool's errand, but I'm trying to > > determine if Verizon will speak BGP with FiOS business customers. Their > > website is relatively lean on details. Everything that mentions BGP > points > > to VZB services, which does not appear to include FiOS. Looking at the > > routing table, I do see several non-VZ ASNs downstream of AS19262, so it > > looks like it might be possible. > > > > If that is the case, could anyone lend any insight to get past the "what > is > > BGP?" response that likely awaits from their salescritters? > > > No. If you want to do BGP with Verizon, you have to buy a T1 at 10 > times the cost and 1/10th of the speed. > > Though I'd love to discover I'm mistaken about that. :) > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From bicknell at ufp.org Tue Mar 13 18:35:24 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 13 Mar 2012 16:35:24 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> Message-ID: <20120313233524.GB65125@ussenterprise.ufp.org> In a message written on Wed, Mar 14, 2012 at 07:58:30AM +0900, Randy Bush wrote: > none of which seem to move us forward. i guess the lesson is that, as > long as we are well below moore, we just keep going down the slippery, > and damned expensive, slope. Bill's model for price is too simple, and it's because the number of devices with a full table change as the price pressure changes, and that causes other costs. Quite simply, if a box that could take a full table were 10x cheaper, more people would take a full table at the edge. More full tables at the edge probably means more BGP speakers. More BGP speakers means more churn, and churn means the core device needs more CPU. TL;DR A savings in ram may result in an increased need for CPU, based on a change in user behavior. I also think the difference in the BOM to a router vendor is small for most boxes. That is the actual cost to manufacture difference between a 1M route box and 2M route box is noise, on the high end the cost of 40 and 100G optics dominate, and on the low end in a CPU switching box RAM is super-cheap. The only "proof" I can offer is the _lack_ of vendors offering different route-holding profiles, and that the few that do are stuck in the mid-range equipment. If the route memory was such a big factor you would see more vendors with route memory options. Indeed, over time, the number of boxes with route-memory options have dropped over time and I think this is due to the fact that memory prices have dropped _much_ faster than CPU or optic prices. TL;DR backbone routers are on a treadmill for faster interfaces, and memory is a small fraction of their cost, edge routers are on a tredmill for more CPU for edge features, and again RAM is a fraction of their cost. It's only boxes in the middle being squeezed. I'll note Bill used the 6509/7600 platform, which is solidly in the middle and does have route-memory options (Sup720-3C Sup720-3CXL). If my theory is right, he used pretty much the _worst_ case to arrive at his $8k per route figure. The list price difference in these two cards is $12,000 to go from 256,000 routes to 1,000,000 routes. $12,000 / 750,000 routes = 1.6 cents per route per box. That matches Bill's number (and I think is where he got it), $8000 route/box / 1.6 cents/route/box = 500,000 boxes. But that box has a 5-7 year time frame, so it's really more like (being generous) $1600 per route per box per year. Priced a 100 Gig optic lately, or long haul DWDM system? I don't think the cost of routes is "damned expensive". -- 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 bill at herrin.us Tue Mar 13 18:37:33 2012 From: bill at herrin.us (William Herrin) Date: Tue, 13 Mar 2012 19:37:33 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: On Tue, Mar 13, 2012 at 7:09 PM, chris wrote: > On Mar 13, 2012 7:04 PM, "William Herrin" wrote: >> On Tue, Mar 13, 2012 at 6:26 PM, Justin M. Streiner >> wrote: >> > I realize this might be a bit of a fool's errand, but I'm trying to >> > determine if Verizon will speak BGP with FiOS business customers. >> >> No. If you want to do BGP with Verizon, you have to buy a T1 at 10 >> times the cost and 1/10th of the speed. > > Haha true that. How else would.they.push their atm and.Ethernet products. A cost I could live with. It's the fact that they won't sell me BGP service in the FiOS product line *at all* that makes me pine for the days of FCC mandated unbundling. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nathan at robotics.net Tue Mar 13 18:42:46 2012 From: nathan at robotics.net (Nathan Stratton) Date: Tue, 13 Mar 2012 18:42:46 -0500 (CDT) Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: On Tue, 13 Mar 2012, William Herrin wrote: > A cost I could live with. It's the fact that they won't sell me BGP > service in the FiOS product line *at all* that makes me pine for the > days of FCC mandated unbundling. Having the same problem with Comcast, even on there business Cable service they wont do BGP with me. -Nathan > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From tknchris at gmail.com Tue Mar 13 18:44:17 2012 From: tknchris at gmail.com (chris) Date: Tue, 13 Mar 2012 19:44:17 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: Comcast same deal ethernet only chris On Mar 13, 2012 7:42 PM, "Nathan Stratton" wrote: > On Tue, 13 Mar 2012, William Herrin wrote: > > A cost I could live with. It's the fact that they won't sell me BGP >> service in the FiOS product line *at all* that makes me pine for the >> days of FCC mandated unbundling. >> > > Having the same problem with Comcast, even on there business Cable service > they wont do BGP with me. > > -Nathan > > Regards, >> Bill Herrin >> >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> > From nathan at robotics.net Tue Mar 13 18:59:59 2012 From: nathan at robotics.net (Nathan Stratton) Date: Tue, 13 Mar 2012 18:59:59 -0500 (CDT) Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: On Tue, 13 Mar 2012, chris wrote: > Comcast same deal ethernet only Yep, I got a quote for that, 7K a month.... yet I can get 100 meg on a gig circuit for $400 bucks from them in a datacenter. Oh, and the 7K is NOT to cover build out, did I forget to mention that node for my area is in MY backyard??? -Nathan From morrowc.lists at gmail.com Tue Mar 13 19:06:31 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 13 Mar 2012 20:06:31 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: On Tue, Mar 13, 2012 at 6:26 PM, Justin M. Streiner wrote: > All: > > I realize this might be a bit of a fool's errand, but I'm trying to > determine if Verizon will speak BGP with FiOS business customers. ?Their > website is relatively lean on details. ?Everything that mentions BGP points > to VZB services, which does not appear to include FiOS. ?Looking at the > routing table, I do see several non-VZ ASNs downstream of AS19262, so it > looks like it might be possible. > > If that is the case, could anyone lend any insight to get past the "what is > BGP?" response that likely awaits from their salescritters? So.... techsupport folks aside.. the product they sell is: A) DHCP only, single address, dynamic B) Single Static address (uplift of 25$/month I believe?) C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the option-B above/month. You can't bring your own space You can't do BGP You can get more than 5 ips (in 5 ip chunks I believe) for 25$/month per chunk... ip address rental, welcome to 1999! Also, I know that on 701 the rate of BGP to non-BGP customers was increasing and was at ~30% or so as of ~2007... You'd think that 19262 would see that, see the business opportunity and offer it? Though, I suppose they DO see the business opportunity: "You want bgp? you want to bring your own ips? you want more than a DHCP address? Pay up, a lot." weee! fun times! At some point there was fairly serious talk of moving the FIOS product into the last-mile offering for 701 customers as well, guess that didn't happen? :( Seems, to me at least, like the PON technology would be a win/win for large ISP customers... easy upgrade paths (dial-on-demand-bandwidth almost?) and simple CPE deployments: "Ethernet? sure it's available!" -chris From tnadeau at lucidvision.com Tue Mar 13 19:12:29 2012 From: tnadeau at lucidvision.com (Thomas Nadeau) Date: Tue, 13 Mar 2012 20:12:29 -0400 Subject: SNMP monitoring of routing tables In-Reply-To: References: <1323786824.1222817.1331661248220.JavaMail.root@zimbra01.rainierconnect.net> <6FE91B7F-AEE4-445D-8AE6-83EC620B2A73@cordares.nl> Message-ID: I concur. Their tool is quite nice. --Tom On Mar 13, 2012, at 6:14 PM, Randy Bush wrote: >> Does anyone know of a similar tool (opensource/low cost) for the IGPs? > > packet design > > randy > > From faisal at snappydsl.net Tue Mar 13 19:20:33 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Tue, 13 Mar 2012 20:20:33 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: <4F5FE451.6040004@snappydsl.net> So I have to ask you the big question... Why do you want to do BGP with Comcast or Verizon ? (Over FIOS or Cable ?) Is the intent to Peer with their network ? (which they will rightfully only allow on bigger fatter connections).. or Are you trying to delivery your IP's to a End Customer behind that FIOS / Cable Connection ? ... (there a ways to accomplish this without needing their cooperation..) Faisal Imtiaz Snappy Internet& Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 3/13/2012 8:06 PM, Christopher Morrow wrote: > On Tue, Mar 13, 2012 at 6:26 PM, Justin M. Streiner > wrote: >> All: >> >> I realize this might be a bit of a fool's errand, but I'm trying to >> determine if Verizon will speak BGP with FiOS business customers. Their >> website is relatively lean on details. Everything that mentions BGP points >> to VZB services, which does not appear to include FiOS. Looking at the >> routing table, I do see several non-VZ ASNs downstream of AS19262, so it >> looks like it might be possible. >> >> If that is the case, could anyone lend any insight to get past the "what is >> BGP?" response that likely awaits from their salescritters? > So.... techsupport folks aside.. the product they sell is: > > > A) DHCP only, single address, dynamic > B) Single Static address (uplift of 25$/month I believe?) > C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the > option-B above/month. > > You can't bring your own space > You can't do BGP > You can get more than 5 ips (in 5 ip chunks I believe) for 25$/month > per chunk... > > ip address rental, welcome to 1999! > > Also, I know that on 701 the rate of BGP to non-BGP customers was > increasing and was at ~30% or so as of ~2007... You'd think that 19262 > would see that, see the business opportunity and offer it? Though, I > suppose they DO see the business opportunity: "You want bgp? you want > to bring your own ips? you want more than a DHCP address? Pay up, a > lot." > > weee! fun times! At some point there was fairly serious talk of moving > the FIOS product into the last-mile offering for 701 customers as > well, guess that didn't happen? :( Seems, to me at least, like the PON > technology would be a win/win for large ISP customers... easy upgrade > paths (dial-on-demand-bandwidth almost?) and simple CPE deployments: > "Ethernet? sure it's available!" > > -chris > > From morrowc.lists at gmail.com Tue Mar 13 19:31:20 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 13 Mar 2012 20:31:20 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <4F5FE451.6040004@snappydsl.net> References: <4F5FE451.6040004@snappydsl.net> Message-ID: On Tue, Mar 13, 2012 at 8:20 PM, Faisal Imtiaz wrote: > So I have to ask you the big question... > > Why do you want to do BGP with Comcast or Verizon ? (Over FIOS or Cable ?) > > Is the intent to Peer with their network ? (which they will rightfully only > allow on bigger fatter connections).. 'peer' has many connotations, I think most of the cases of it over FIOS are just: "I want bgp so I can announce my prefixes, and see yours/default/etc" (which leads to 'multihoming' and other normal (for businesses) activities on the Internet. > > or > Are you trying to delivery your IP's to a End Customer behind that FIOS / > Cable Connection ? ... > (there a ways to accomplish this without needing their cooperation..) or you are multihomed or you want some semblence of 'the internet is down' so other bits of your infrastructure can take over or you want ... a thousand other things. From streiner at cluebyfour.org Tue Mar 13 19:32:53 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 13 Mar 2012 20:32:53 -0400 (EDT) Subject: Verizon FiOS - is BGP an option? In-Reply-To: <4F5FE451.6040004@snappydsl.net> References: <4F5FE451.6040004@snappydsl.net> Message-ID: On Tue, 13 Mar 2012, Faisal Imtiaz wrote: > Why do you want to do BGP with Comcast or Verizon ? (Over FIOS or Cable ?) To gain redundancy for a consulting client. > Is the intent to Peer with their network ? (which they will rightfully only > allow on bigger fatter connections).. I think you mean "higher margin connections" ;) As far as I know, most major carriers will still sell you a T1 for Internet access (and even BGP!) if you want it. > Are you trying to delivery your IP's to a End Customer behind that FIOS / > Cable Connection ? ... > (there a ways to accomplish this without needing their cooperation..) Running BGP over a tunnel is one (albeit sub-optimal) option, but I don't know of any providers that sell such a service. All of the other options have varying degrees of downside, i.e. how much of an outage are you willing to put up with when provider A fails, transferring DNS records, etc. jms From MGauvin at dryden.ca Tue Mar 13 19:35:00 2012 From: MGauvin at dryden.ca (Mark Gauvin) Date: Tue, 13 Mar 2012 19:35:00 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <4F5FE451.6040004@snappydsl.net> Message-ID: <85549E40-B7EC-4853-B7B9-2E956528DC46@dryden.ca> Peering is generally for a comercial endevor to my understandind fios is a residential service so which are you trying to accomplish Sent from my iPhone On 2012-03-13, at 7:32 PM, "Christopher Morrow" wrote: > On Tue, Mar 13, 2012 at 8:20 PM, Faisal Imtiaz > wrote: >> So I have to ask you the big question... >> >> Why do you want to do BGP with Comcast or Verizon ? (Over FIOS or >> Cable ?) >> >> Is the intent to Peer with their network ? (which they will >> rightfully only >> allow on bigger fatter connections).. > > 'peer' has many connotations, I think most of the cases of it over > FIOS are just: "I want bgp so I can announce my prefixes, and see > yours/default/etc" (which leads to 'multihoming' and other normal (for > businesses) activities on the Internet. > >> >> or >> Are you trying to delivery your IP's to a End Customer behind that >> FIOS / >> Cable Connection ? ... >> (there a ways to accomplish this without needing their cooperation..) > > or you are multihomed > or you want some semblence of 'the internet is down' so other bits of > your infrastructure can take over > or you want ... a thousand other things. > From streiner at cluebyfour.org Tue Mar 13 19:43:13 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 13 Mar 2012 20:43:13 -0400 (EDT) Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: On Tue, 13 Mar 2012, Christopher Morrow wrote: > A) DHCP only, single address, dynamic > B) Single Static address (uplift of 25$/month I believe?) I think that might be $40/mo now, but I could be mistaken. > Also, I know that on 701 the rate of BGP to non-BGP customers was > increasing and was at ~30% or so as of ~2007... You'd think that 19262 > would see that, see the business opportunity and offer it? Though, I > suppose they DO see the business opportunity: "You want bgp? you want > to bring your own ips? you want more than a DHCP address? Pay up, a > lot." I wonder if something is cooking there. When I look at a full BGP view, I see quite a few ASNs downstream of 19262, beyond some that appear to be internal VZ ASNs: * 12.195.9.0/24 x.x.x.x 701 19262 30079 * 65.198.73.0/24 x.x.x.x 701 19262 40321 * 68.236.226.0/24 x.x.x.x 701 19262 18762 * 137.71.229.0/24 x.x.x.x 701 19262 20258 * 141.155.220.0/24 x.x.x.x 701 19262 36512 * 143.165.216.0/21 x.x.x.x 701 19262 2923 ..... jms From shortdudey123 at gmail.com Tue Mar 13 20:09:37 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 13 Mar 2012 20:09:37 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: 4 of the 6 downstreams are multihomed. Only 40321 (Emigrant Bank) and 18762 (Dominick & Dominick LLC) are single homed to 19262 (Verizon Online LLC). -Grant On Tue, Mar 13, 2012 at 7:43 PM, Justin M. Streiner wrote: > On Tue, 13 Mar 2012, Christopher Morrow wrote: > > A) DHCP only, single address, dynamic >> B) Single Static address (uplift of 25$/month I believe?) >> > > I think that might be $40/mo now, but I could be mistaken. > > > Also, I know that on 701 the rate of BGP to non-BGP customers was >> increasing and was at ~30% or so as of ~2007... You'd think that 19262 >> would see that, see the business opportunity and offer it? Though, I >> suppose they DO see the business opportunity: "You want bgp? you want >> to bring your own ips? you want more than a DHCP address? Pay up, a >> lot." >> > > I wonder if something is cooking there. When I look at a full BGP view, I > see quite a few ASNs downstream of 19262, beyond some that appear to be > internal VZ ASNs: > > * 12.195.9.0/24 x.x.x.x 701 19262 30079 > * 65.198.73.0/24 x.x.x.x 701 19262 40321 > * 68.236.226.0/24 x.x.x.x 701 19262 18762 > * 137.71.229.0/24 x.x.x.x 701 19262 20258 > * 141.155.220.0/24 x.x.x.x 701 19262 36512 > * 143.165.216.0/21 x.x.x.x 701 19262 2923 > ..... > > jms > > From morrowc.lists at gmail.com Tue Mar 13 20:13:44 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 13 Mar 2012 21:13:44 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: On Tue, Mar 13, 2012 at 9:09 PM, Grant Ridder wrote: > 4 of the 6 downstreams are multihomed. Only?40321?(Emigrant Bank) > and?18762?(Dominick & Dominick LLC) are single homed to 19262 (Verizon > Online LLC). yup... vz had for quite some time actual 'network' customers behind 19262, as part of larger multi-site deals. they also ran a 'private mpls vpn' across that same core for a time (and likely still do...) -chris > On Tue, Mar 13, 2012 at 7:43 PM, Justin M. Streiner > wrote: >> >> On Tue, 13 Mar 2012, Christopher Morrow wrote: >> >>> A) DHCP only, single address, dynamic >>> B) Single Static address (uplift of 25$/month I believe?) >> >> >> I think that might be $40/mo now, but I could be mistaken. >> >> >>> Also, I know that on 701 the rate of BGP to non-BGP customers was >>> increasing and was at ~30% or so as of ~2007... You'd think that 19262 >>> would see that, see the business opportunity and offer it? Though, I >>> suppose they DO see the business opportunity: "You want bgp? you want >>> to bring your own ips? you want more than a DHCP address? Pay up, a >>> lot." >> >> >> I wonder if something is cooking there. ?When I look at a full BGP view, I >> see quite a few ASNs downstream of 19262, beyond some that appear to be >> internal VZ ASNs: >> >> * 12.195.9.0/24 ? ?x.x.x.x ? ? ? ? ? 701 19262 30079 >> * 65.198.73.0/24 ? x.x.x.x ? ? ? ? ? 701 19262 40321 >> * 68.236.226.0/24 ?x.x.x.x ? ? ? ? ? 701 19262 18762 >> * 137.71.229.0/24 ?x.x.x.x ? ? ? ? ? 701 19262 20258 >> * 141.155.220.0/24 x.x.x.x ? ? ? ? ? 701 19262 36512 >> * 143.165.216.0/21 x.x.x.x ? ? ? ? ? 701 19262 2923 >> ..... >> >> jms >> > From morrowc.lists at gmail.com Tue Mar 13 20:15:39 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 13 Mar 2012 21:15:39 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <85549E40-B7EC-4853-B7B9-2E956528DC46@dryden.ca> References: <4F5FE451.6040004@snappydsl.net> <85549E40-B7EC-4853-B7B9-2E956528DC46@dryden.ca> Message-ID: On Tue, Mar 13, 2012 at 8:35 PM, Mark Gauvin wrote: > Peering is generally for a comercial endevor to my understandind fios > is a residential service so which are you trying to accomplish 'peering' really is a loaded term... 'settlement free peering' ? 'bgp peering' ? there are other meanings as well, but I think in the case the person I responded (Faisal?) was asking about he meant 'settlement free peering', which I don't think is what Justin meant, Justin just wants the same as most of the bgp speakers want: "multihoming". -chris From davidpeahi at gmail.com Tue Mar 13 20:31:15 2012 From: davidpeahi at gmail.com (david peahi) Date: Tue, 13 Mar 2012 18:31:15 -0700 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: What is the SLA for FIOS? I believe that FIOS uses either PON or GPON technology where a single data wavelength is split up to 32 times resulting in a shared pipe back to the CO. Does Verizon offer any SLA at all for FIOS? On the other hand Verizon Wireless offers BGP peering for business customers, but lacks geographically-dispersed peering points with their wired network, which results in unusually high round trip latencies. On Tue, Mar 13, 2012 at 3:26 PM, Justin M. Streiner wrote: > All: > > I realize this might be a bit of a fool's errand, but I'm trying to > determine if Verizon will speak BGP with FiOS business customers. Their > website is relatively lean on details. Everything that mentions BGP points > to VZB services, which does not appear to include FiOS. Looking at the > routing table, I do see several non-VZ ASNs downstream of AS19262, so it > looks like it might be possible. > > If that is the case, could anyone lend any insight to get past the "what > is BGP?" response that likely awaits from their salescritters? > > jms > > From faisal at snappydsl.net Tue Mar 13 20:34:19 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Tue, 13 Mar 2012 21:34:19 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <4F5FE451.6040004@snappydsl.net> <85549E40-B7EC-4853-B7B9-2E956528DC46@dryden.ca> Message-ID: <4F5FF59B.8070107@snappydsl.net> Sorry, by saying Peering I mean any kind of direct peering.. As to the other reason for running BGP, there are technical solutions to get around this 'lack of cooperation'. Personally speaking, asking for BGP peering on a 'resi' grade service is like going to McDonalds, and asking for a cooking lesson from their Head Chef. No flame or offense intended. Take us for example, we are an independent service provider, technically, can we do bgp over a DSL connection, the answer is yes, can we 'route' a class 'C' for someone purchasing a resi dsl service, the answer is yes... Now the real question you are asking ... (or complaining about) .... is Do we want to do this ? from a business perspective ..answer is NO..... from a Technical perspective... do we have the desire to support it ? ... answer is NO... .. Complex Routing and resi connections just don't mix ... :) So if we don't want to do this, why do you think or feel that VZ or any other Large provider should do this ? (besides. there is this other minor issue that their infrastructure deployed to serve FIOS / Cable / ADSL / UVerse is not designed nor capable of doing BGP with end-user connection / routers.. ). Regards. Faisal Imtiaz Snappy Internet& Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 3/13/2012 9:15 PM, Christopher Morrow wrote: > On Tue, Mar 13, 2012 at 8:35 PM, Mark Gauvin wrote: >> Peering is generally for a comercial endevor to my understandind fios >> is a residential service so which are you trying to accomplish > 'peering' really is a loaded term... > > 'settlement free peering' ? > 'bgp peering' ? > > there are other meanings as well, but I think in the case the person I > responded (Faisal?) was asking about he meant 'settlement free > peering', which I don't think is what Justin meant, Justin just wants > the same as most of the bgp speakers want: "multihoming". > > -chris > From owen at delong.com Tue Mar 13 22:13:41 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 13 Mar 2012 20:13:41 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <386ca181-dbc5-4ce1-9cd7-6af4dbe047ec@s7g2000yqm.googlegroups.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> <386ca181-dbc5-4ce1-9cd7-6af4dbe047ec@s7g2000yqm.googlegroups.com> Message-ID: <231E08F7-7078-4721-BF5F-569DD99E045F@delong.com> > >> Given that global routing table is bloated because of site >> multihoming, where the site uses multiple ISPs within a city, >> costs of long-haul fiber is irrelevant. > > I suppose smaller multi-homed sites can and often do take a full > table, but they don't *need* to do so. What they do need is their > routes advertised to the rest of the internet, which means they must > be in the fancy-and-currently-expensive routers somewhere upstream. > > This is where the cost of long-haul fiber becomes relevant: Until we > can figure out how dig cheaper ditches and negotiate cheaper rights-of- > way, there will not be an explosion of the number of full-table > provider edge routers, because there are only so many interconnection > points where they are needed. Incremental growth, perhaps, but > physical infrastructure cannot follow an exponential growth curve. > Not entirely accurate. Most of the reduction in cost/mbps that has occurred over the last couple of decades has come not from better digging economics (though there has been some improvement there), but rather from more Mpbs per dig. As technology continues to increase the Mbps/strand, strands/cable, etc., the cost/Mbps will continue to drop. I expect within my lifetime that multi-gigabit ethernet will become commonplace in the household LAN environment and that when that becomes reality, localized IP Multicast over multi-gigabit ethernet will eventually supplant HDMI as the primary transport for audio/video streams between devices (sources such as BD players, DVRs, computers, etc. and destinations such as receivers/amps, monitors, speaker drivers, etc.). There are already hackish efforts at this capability in the form of TiVO's HTTTPs services, Sling Box, and others. >> As it costs less than $100 per month to have fiber from a >> local ISP, having them from multiple ISPs costs a lot less >> is negligible compared to having routers with a so bloated >> routing table. > > For consumer connections, a sub-$1000 PC would serve you fine with a > full table given the level of over-subscription involved. Even > something like Quagga or Vyatta running in a virutal machine would > suffice. Or a Linksys with more RAM. Getting your providers to speak > BGP with you on such a connection for that same $100/month will be > quite a feat. Even in your contrived case, however, the monthly > recurring charges exceed a $1000 router cost after a few months. > Simpler solution, let the providers speak whatever they will sell you. Ideally, find one that will at least sell you a static address. Then use a tunnel to do your real routing. There are several free tunnel services and I know at least one will do BGP. > Enterprises pay several thousand dollars per month per link for > quality IP transit at Gigabit rates. Since this isn't a marketing list, I'll let this one slide by. Owen From owen at delong.com Tue Mar 13 22:20:50 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 13 Mar 2012 20:20:50 -0700 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: <773E9B61-6316-4192-9FFE-D911DC44104A@delong.com> > > C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the > option-B above/month. > And people wonder why Verizon is the first to whine about routing table growth from deaggregation? ;-) In all seriousness, though, I don't think they are routed as /32s. I think that's one for the Verizon CPE, 5 for your devices all routed as a single /29. Owen From Gus.Crichton at digicelgroup.com Tue Mar 13 22:50:28 2012 From: Gus.Crichton at digicelgroup.com (Gus Crichton) Date: Wed, 14 Mar 2012 17:50:28 +1400 Subject: GRX looking glass Message-ID: <095F4877B51D7E44BC5F78803E75615F0222F504@WSEX000.digicelgroup.local> Hello, Any public looking glasses for GRX? Thanks. ________________________________ Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. From morrowc.lists at gmail.com Tue Mar 13 22:57:04 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 13 Mar 2012 23:57:04 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <773E9B61-6316-4192-9FFE-D911DC44104A@delong.com> References: <773E9B61-6316-4192-9FFE-D911DC44104A@delong.com> Message-ID: On Tue, Mar 13, 2012 at 11:20 PM, Owen DeLong wrote: >> >> C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the >> option-B above/month. >> > And people wonder why Verizon is the first to whine about routing table growth from deaggregation? ;-) > eh, these end up (I think) aggregated on the edge router, so you get 5 /32's from a /23 (or the like) routed to the edge layer3 device. not as bloaty for the rest of their network as it at first seems. > In all seriousness, though, I don't think they are routed as /32s. I think that's one for the Verizon CPE, > 5 for your devices all routed as a single /29. > owen, seen the config on a live router, yes they are routed as /32's to the VC you are connected to. I probably have the config for my old link in IM/email somewhere. apparently their automation either doesn't understand CIDR, or it was 'too expensive' to make the automation do CIDR once they started to offer extra ips to the business customers. -chris From bill at herrin.us Tue Mar 13 23:19:16 2012 From: bill at herrin.us (William Herrin) Date: Wed, 14 Mar 2012 00:19:16 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <773E9B61-6316-4192-9FFE-D911DC44104A@delong.com> References: <773E9B61-6316-4192-9FFE-D911DC44104A@delong.com> Message-ID: On Tue, Mar 13, 2012 at 11:20 PM, Owen DeLong wrote: >> >> C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the >> option-B above/month. >> > And people wonder why Verizon is the first to whine about routing table growth from deaggregation? ;-) > > In all seriousness, though, I don't think they are routed as /32s. I think that's one for the Verizon CPE, > 5 for your devices all routed as a single /29. Nope. I have FiOS and the 5 IPs. They are 5 IPs, in sequence, at a completely arbitrary location in a /24 subnet. They're not "routed" to anywhere. I can plug an plain old hub into the FiOS ONT and whatever machine responds to the ARP request gets them. I too expected they were going to be a /29 routed to an exterior interface. I was disappointed since I could have squeezed 9 IPs out of that. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From frnkblk at iname.com Tue Mar 13 23:34:53 2012 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 13 Mar 2012 23:34:53 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: Message-ID: <111901cd019b$cd685d60$68391820$@iname.com> One possible avenue is put a router/computer in a colo and build a GRE tunnel over your FiOS connection to the data center, and then "peer" with folk there. Frank -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Tuesday, March 13, 2012 5:27 PM To: nanog at nanog.org Subject: Verizon FiOS - is BGP an option? All: I realize this might be a bit of a fool's errand, but I'm trying to determine if Verizon will speak BGP with FiOS business customers. Their website is relatively lean on details. Everything that mentions BGP points to VZB services, which does not appear to include FiOS. Looking at the routing table, I do see several non-VZ ASNs downstream of AS19262, so it looks like it might be possible. If that is the case, could anyone lend any insight to get past the "what is BGP?" response that likely awaits from their salescritters? jms -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6517 bytes Desc: not available URL: From tknchris at gmail.com Tue Mar 13 23:40:09 2012 From: tknchris at gmail.com (chris) Date: Wed, 14 Mar 2012 00:40:09 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <111901cd019b$cd685d60$68391820$@iname.com> References: <111901cd019b$cd685d60$68391820$@iname.com> Message-ID: next lets encapsulate bgp over http next so we can run bgp at wifi hotspots :) On Wed, Mar 14, 2012 at 12:34 AM, Frank Bulk wrote: > One possible avenue is put a router/computer in a colo and build a GRE > tunnel over your FiOS connection to the data center, and then "peer" with > folk there. > > Frank > > -----Original Message----- > From: Justin M. Streiner [mailto:streiner at cluebyfour.org] > Sent: Tuesday, March 13, 2012 5:27 PM > To: nanog at nanog.org > Subject: Verizon FiOS - is BGP an option? > > All: > > I realize this might be a bit of a fool's errand, but I'm trying to > determine if Verizon will speak BGP with FiOS business customers. Their > website is relatively lean on details. Everything that mentions BGP > points to VZB services, which does not appear to include FiOS. Looking at > the routing table, I do see several non-VZ ASNs downstream of AS19262, so > it looks like it might be possible. > > If that is the case, could anyone lend any insight to get past the "what > is BGP?" response that likely awaits from their salescritters? > > jms > > > From blake at pfankuch.me Tue Mar 13 23:45:51 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Wed, 14 Mar 2012 04:45:51 +0000 Subject: Xirrus Wireless In-Reply-To: <4F5FCE35.6020906@altadena.net> References: <4F5FCAEF.8060109@altadena.net> <4F5FCE35.6020906@altadena.net> Message-ID: Thanks very much to all of the useful on and off list releases. I would like to also thank Ron Valdez of Vall Technologies for his very prompt sales contact as well. Very unprofessional, but nice try to cover up the contact with the excuse of "simple google searches while reaching out to local IT firms" to find my contact information and directly attempt to market a product which I just recently asked about here, and conveniently he happens to be a Xirrus Gold Partner. Summary of what I have learned, including quotes from a few people who said it better than I can reword it. "Conceptually, it sounds like a good idea to increate spectral bandwidth, but I have a hunch that it falls down somewhat in practice." Several people have mentioned that only a limited number of radios within each device (3) can do 2.4ghz at the same time (which makes sense) due to signal conflict and the specified specs which say 120 degrees of broadcast per antenna. Several people have also stated (as well as math) that a single device can only handle about 90-120 2.4ghz clients before there is noticeable slowdown. 5ghz wise experience holds up to specs as far as client connections. Having 802.11b enabled anywhere has had a very negative on performance of the device as one could expect. In buildings with many smaller rooms, using a single device to cover so many rooms runs you into the problem of interference thanks to walls, refraction and material conflicts. Scaling them back becomes tough because each device with its large number of radios saturates the spectrum, allowing limited overlap... "Xirrus is overkill [...] when doing small gigs and won't scale [to] very big events, compared to a truckload of cisco APs. Mostly because our venues are not stadium sized." "Turn up the AP count, turn down the signal strength fill the building 'til it glows." Thanks for all the input! -----Original Message----- From: Pete Carah [mailto:pete at altadena.net] Sent: Tuesday, March 13, 2012 4:46 PM To: Blake Pfankuch; NANOG Mailing List Subject: Re: Xirrus Wireless On 03/13/2012 03:35 PM, Blake Pfankuch wrote: > Thanks Pete, that does help. Now hopefully I can get someone who has experience with 500+ devices running on a single one in a fairly small area (High School Gym). There was a thread about this a couple of months back, I'm pretty sure it was after last November (but not absolutely sure); lots of discussion about density and Xirrrus was mentioned. My personal experience with Xirrus is certainly not high-density, and the "real" hospital certainly copes with a bunch (though I'm guessing 20-30 users per AP from how many APs they have distributed among rooms. They seem to do a bunch of their device telemetry on 802.11 but there are also some more dedicated frequencies/protocols for medical devices. (even the IV pumps alarm at the nurse's station...) I do have some experience with full-duplex RF transceiver design, though, and the Xirrus configuration can't be easy to make work well. Not impossible, but difficult. -- Pete > > -----Original Message----- > From: Pete Carah [mailto:pete at altadena.net] > Sent: Tuesday, March 13, 2012 4:32 PM > To: nanog at nanog.org > Subject: Re: Xirrus Wireless > > On 03/13/2012 02:34 PM, Blake Pfankuch wrote: >> I know this is a little outside of the traditional NANOG realm but... >> >> I have a customer looking at a fair number of Xirrus Wireless Arrays for 802.11a/b/g/n implementations and am looking for some real world insight into them. On the cover they look cool, the white papers look cool, but I am yet to find technical commentary from a real person on these devices. Looking at the XN line, and just curious if anyone has deployed these, supports these or knows anything about them. > I can only speak from indirect experience; the rehab place where my > wife is staying for a bit uses 4 or 5 of them (older, probably not > current, flying-saucer-like boxes suspended from the ceiling at > hallway > junctions) and there, at least, they appear to work pretty well. The particular ones don't appear to my laptop to do 11a. However, I don't think there is any significant user density just from watching the nifty directional light display, so this may not mean much (I'd guess 3 to 10 users over the whole building including smartphones and a couple of pieces of medical equipment that isn't used much). Also there is no IT (or any real technical maint) guy on-premises to talk to so I can't ask about any other aspect. > > The local real hospital uses a Cisco system (or at least Cisco APs; don't know about the AP manager box) which really does appear to work well; I'd guess several hundred APs with lots of full-time medical gear, and a "guest" network which is behind a rather draconian firewall (wouldn't let me ssh out to a non-standard port (65k range), for example; I had to fix myself a 443 ssh port for the time we spent there a couple of months ago... Blocked 25 outgoing; I don't blame them for that, however they also blocked 465 (but allowed 587)). > > I suspect if I wanted 2.4-only I'd go with ubiquiti, but I don't have any experience with them, and their "unifi" boxes don't (yet) come in 5gig. And they don't appear to have independent APs in each box, though I don't know how well the "directional" antennas in the Xirrus actually separate things; even a 100mw transmitter may well overwhelm all the other local receivers unless there is a bunch of shielding inside the enclosure (and maybe even then...) If 802.11 was frequency-split like the cell system it would help such systems a bunch. > > -- Pete > >> Thanks! >> >> Blake >> > > From owen at delong.com Wed Mar 14 00:00:44 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 13 Mar 2012 22:00:44 -0700 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <773E9B61-6316-4192-9FFE-D911DC44104A@delong.com> Message-ID: <6ED6269C-F3B0-439F-9C95-046220DFD7A3@delong.com> On Mar 13, 2012, at 8:57 PM, Christopher Morrow wrote: > On Tue, Mar 13, 2012 at 11:20 PM, Owen DeLong wrote: >>> >>> C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the >>> option-B above/month. >>> >> And people wonder why Verizon is the first to whine about routing table growth from deaggregation? ;-) >> > > eh, these end up (I think) aggregated on the edge router, so you get 5 > /32's from a /23 (or the like) routed to the edge layer3 device. not > as bloaty for the rest of their network as it at first seems. > >> In all seriousness, though, I don't think they are routed as /32s. I think that's one for the Verizon CPE, >> 5 for your devices all routed as a single /29. >> > > owen, seen the config on a live router, yes they are routed as /32's > to the VC you are connected to. I probably have the config for my old > link in IM/email somewhere. apparently their automation either doesn't > understand CIDR, or it was 'too expensive' to make the automation do > CIDR once they started to offer extra ips to the business customers. > > -chris Interesting. I guess to each their own. Many other providers I know are selling "5 IP" packages done the other way. Owen From morrowc.lists at gmail.com Wed Mar 14 00:13:40 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 14 Mar 2012 01:13:40 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <6ED6269C-F3B0-439F-9C95-046220DFD7A3@delong.com> References: <773E9B61-6316-4192-9FFE-D911DC44104A@delong.com> <6ED6269C-F3B0-439F-9C95-046220DFD7A3@delong.com> Message-ID: On Wed, Mar 14, 2012 at 1:00 AM, Owen DeLong wrote: > Interesting. I guess to each their own. > > Many other providers I know are selling "5 IP" packages done the other way. "many providers are not crazy" yes.... I agree. From tvhawaii at shaka.com Wed Mar 14 00:14:35 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 13 Mar 2012 19:14:35 -1000 Subject: Xirrus Wireless References: <4F5FCAEF.8060109@altadena.net> <4F5FCE35.6020906@altadena.net> Message-ID: <5F2344583D08477EA3CDB768BA7D3634@owner59e1f1502> Blake Pfankuch wrote: > Thanks very much to all of the useful on and off list releases. If you want to try and gleen more info. and get some questions answered, Moonblink is having a webinar next Wednesday and I'm sure they'd love to have you attend. FREE Webinar! The Changing Role of Wi-Fi w/ Xirrus March 21, 2012 @ 10AM PST > Register Today! Wi-Fi is changing. In addition to a desktop or a laptop connecting to a local AP, people have wi-fi enabled smartphones, tablets, and other devices. A new generation of wireless infrastructure is needed. Join Perry Correll, Xirrus' Director of Product Marketing, to learn how Wi-Fi is changing and how Xirrus' Wi-Fi Arrays are the only products capable of accommodating current and future wi-fi requirements. http://www.moonblinkwifi.com/pd_xirrus-wi-fi-array-hardware-xn8.cfm From lorell at hathcock.org Wed Mar 14 00:34:52 2012 From: lorell at hathcock.org (Lorell Hathcock) Date: Wed, 14 Mar 2012 00:34:52 -0500 Subject: Xirrus Wireless In-Reply-To: References: Message-ID: <08e101cd01a4$2e9f0450$8bdd0cf0$@hathcock.org> Blake/NANOGL I just completed the Technical Training with Xirrus at a session in Dallas. The arrays are designed to go way beyond just worrying about signal strength ("coverage") throughout a building or venue. They tackle the problem of how much bandwidth each connected client has available, which is something I have not had the tools to worry about with other WiFi manufacturers. They seem robust and full featured. They have been around for a while too, so going with Xirrus Arrays is not a beta test of their product. They are at least in their third generation of the product now. Cool stuff! Lorell Hathcock MTCRE, MTCWE, MTCTCE OfficeConnect.net lorell at officeconnect.net -----Original Message----- From: Blake Pfankuch [mailto:blake at pfankuch.me] Sent: Tuesday, March 13, 2012 4:34 PM To: NANOG (nanog at nanog.org) Subject: Xirrus Wireless I know this is a little outside of the traditional NANOG realm but... I have a customer looking at a fair number of Xirrus Wireless Arrays for 802.11a/b/g/n implementations and am looking for some real world insight into them. On the cover they look cool, the white papers look cool, but I am yet to find technical commentary from a real person on these devices. Looking at the XN line, and just curious if anyone has deployed these, supports these or knows anything about them. Thanks! Blake From christopher.morrow at gmail.com Wed Mar 14 01:22:04 2012 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 14 Mar 2012 02:22:04 -0400 Subject: shared address space... a reality! Message-ID: NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED From joelja at bogus.com Wed Mar 14 01:29:03 2012 From: joelja at bogus.com (Joel jaeggli) Date: Tue, 13 Mar 2012 23:29:03 -0700 Subject: shared address space... a reality! In-Reply-To: References: Message-ID: <4F603AAF.2070101@bogus.com> On 3/13/12 23:22 , Christopher Morrow wrote: > NetRange: 100.64.0.0 - 100.127.255.255 > CIDR: 100.64.0.0/10 > OriginAS: > NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED Already updated my martians acl and deployed it internally... From joelja at bogus.com Wed Mar 14 01:42:03 2012 From: joelja at bogus.com (Joel jaeggli) Date: Tue, 13 Mar 2012 23:42:03 -0700 Subject: shared address space... a reality! In-Reply-To: <4F603AAF.2070101@bogus.com> References: <4F603AAF.2070101@bogus.com> Message-ID: <4F603DBB.2060807@bogus.com> On 3/13/12 23:29 , Joel jaeggli wrote: > On 3/13/12 23:22 , Christopher Morrow wrote: >> NetRange: 100.64.0.0 - 100.127.255.255 >> CIDR: 100.64.0.0/10 >> OriginAS: >> NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED > > Already updated my martians acl and deployed it internally... this also means you should probably filter the 6to4 mapped address range from 2002:a40::/48 to 2002:a7f:ffff::/48 since those have no chance of making it home. From leigh.porter at ukbroadband.com Wed Mar 14 01:44:58 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 14 Mar 2012 06:44:58 +0000 Subject: shared address space... a reality! In-Reply-To: <4F603AAF.2070101@bogus.com> References: , <4F603AAF.2070101@bogus.com> Message-ID: <7E100187-89E7-4013-9453-C4F7EC4525DC@ukbroadband.com> On 14 Mar 2012, at 06:31, "Joel jaeggli" wrote: > On 3/13/12 23:22 , Christopher Morrow wrote: >> NetRange: 100.64.0.0 - 100.127.255.255 >> CIDR: 100.64.0.0/10 >> OriginAS: >> NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED > > Already updated my martians acl and deployed it internally... There's an app for that! -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From joelja at bogus.com Wed Mar 14 02:17:16 2012 From: joelja at bogus.com (Joel jaeggli) Date: Wed, 14 Mar 2012 00:17:16 -0700 Subject: shared address space... a reality! In-Reply-To: <4F604379.2050803@geier.ne.tz> References: <4F603AAF.2070101@bogus.com> <4F603DBB.2060807@bogus.com> <4F604379.2050803@geier.ne.tz> Message-ID: <4F6045FC.1020407@bogus.com> On 3/14/12 00:06 , Frank Habicht wrote: > Hi, > > On 3/14/2012 9:42 AM, Joel jaeggli wrote: >> On 3/13/12 23:29 , Joel jaeggli wrote: >>> On 3/13/12 23:22 , Christopher Morrow wrote: >>>> NetRange: 100.64.0.0 - 100.127.255.255 >>>> CIDR: 100.64.0.0/10 >>>> OriginAS: >>>> NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED >>> >>> Already updated my martians acl and deployed it internally... >> >> this also means you should probably filter the 6to4 mapped address range >> from 2002:a40::/48 to 2002:a7f:ffff::/48 since those have no chance of >> making it home. > > is my hex going bad...? no mine is, or I'm lapsing into 10/8 > or should it be 2002:6440:: ...... 2002:6440::/48 to 2002:647f:ffff::/48 > is that the funny space for CGN? > > Frank > From mansaxel at besserwisser.org Wed Mar 14 02:47:07 2012 From: mansaxel at besserwisser.org (=?iso-8859-1?Q?M=E5ns?= Nilsson) Date: Wed, 14 Mar 2012 08:47:07 +0100 Subject: shared address space... a reality! In-Reply-To: References: Message-ID: <20120314074707.GZ16111@besserwisser.org> On Wed, Mar 14, 2012 at 02:22:04AM -0400, Christopher Morrow wrote: > NetRange: 100.64.0.0 - 100.127.255.255 > CIDR: 100.64.0.0/10 > OriginAS: > NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED GOOD. Now I can BOTH keep sticking my head in the sand AND get NEW RFC 1918 space to number my devices! Trailing edge WINS! Congrats, all you people who joined the ietf mailing list to get your VOTE through. You can sign off now and continue non-contributing to the developement of the future. -- /M?ns, pissed off. From ml at kenweb.org Wed Mar 14 06:54:41 2012 From: ml at kenweb.org (ML) Date: Wed, 14 Mar 2012 07:54:41 -0400 Subject: shared address space... a reality! In-Reply-To: References: Message-ID: <4F608701.6040203@kenweb.org> On 3/14/2012 2:22 AM, Christopher Morrow wrote: > NetRange: 100.64.0.0 - 100.127.255.255 > CIDR: 100.64.0.0/10 > OriginAS: > NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED > Did IANA have to justify this space to ARIN or was it just given to them no questions asked because a draft RFC specified a need for a /10? From faisal at snappydsl.net Wed Mar 14 07:41:39 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Wed, 14 Mar 2012 08:41:39 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <111901cd019b$cd685d60$68391820$@iname.com> Message-ID: Is that is needed, what is wrong with that ? Isn't MPLS a form of encapsulation ? Don't the enterprise folks run routing protocols on it ? With carriers today it is very common to deliver L2 connectivity over L3 networks. One does not have to like it...and just because someone else (upstream) does it for one, it does not mean it is wrong......just the nature of networks and growth, solving problems with the available set of tools... Faisal On Mar 14, 2012, at 12:40 AM, chris wrote: > next lets encapsulate bgp over http next so we can run bgp at wifi hotspots > :) > > On Wed, Mar 14, 2012 at 12:34 AM, Frank Bulk wrote: > >> One possible avenue is put a router/computer in a colo and build a GRE >> tunnel over your FiOS connection to the data center, and then "peer" with >> folk there. >> >> Frank >> >> -----Original Message----- >> From: Justin M. Streiner [mailto:streiner at cluebyfour.org] >> Sent: Tuesday, March 13, 2012 5:27 PM >> To: nanog at nanog.org >> Subject: Verizon FiOS - is BGP an option? >> >> All: >> >> I realize this might be a bit of a fool's errand, but I'm trying to >> determine if Verizon will speak BGP with FiOS business customers. Their >> website is relatively lean on details. Everything that mentions BGP >> points to VZB services, which does not appear to include FiOS. Looking at >> the routing table, I do see several non-VZ ASNs downstream of AS19262, so >> it looks like it might be possible. >> >> If that is the case, could anyone lend any insight to get past the "what >> is BGP?" response that likely awaits from their salescritters? >> >> jms >> >> >> > From faisal at snappydsl.net Wed Mar 14 08:11:10 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Wed, 14 Mar 2012 09:11:10 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <773E9B61-6316-4192-9FFE-D911DC44104A@delong.com> Message-ID: <4F6098EE.5050103@snappydsl.net> in the DSL world, when we were providing service using Bridge PVC's, it was easier to allocate (as many needed) /32 to a customer CPE, than to route a subnet. This changed when the AT&T/BellSouth infrastructure changed from being able to get ATM PVC's to PPPoE only network. Faisal Imtiaz Snappy Internet& Telecom On 3/13/2012 11:57 PM, Christopher Morrow wrote: > On Tue, Mar 13, 2012 at 11:20 PM, Owen DeLong wrote: >>> C) 5 ips STATICALLY ROUTED AS /32's!! (WTF??) for 25$ above the >>> option-B above/month. >>> >> And people wonder why Verizon is the first to whine about routing table growth from deaggregation? ;-) >> > eh, these end up (I think) aggregated on the edge router, so you get 5 > /32's from a /23 (or the like) routed to the edge layer3 device. not > as bloaty for the rest of their network as it at first seems. > >> In all seriousness, though, I don't think they are routed as /32s. I think that's one for the Verizon CPE, >> 5 for your devices all routed as a single /29. >> > owen, seen the config on a live router, yes they are routed as /32's > to the VC you are connected to. I probably have the config for my old > link in IM/email somewhere. apparently their automation either doesn't > understand CIDR, or it was 'too expensive' to make the automation do > CIDR once they started to offer extra ips to the business customers. > > -chris > > From jra at baylink.com Wed Mar 14 08:13:52 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 14 Mar 2012 09:13:52 -0400 (EDT) Subject: Verizon FiOS - is BGP an option? In-Reply-To: Message-ID: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Faisal Imtiaz" > Is that is needed, what is wrong with that ? Well, we just had FiOS Business 150/65 dropped this week, and my /27 isn't even a /27; we're sharing a /24 with, presumably, a bunch of other customers. Not sure how BGP would handle that... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From faisal at snappydsl.net Wed Mar 14 08:36:05 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Wed, 14 Mar 2012 09:36:05 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> Message-ID: <4F609EC5.4000906@snappydsl.net> I am not familiar with VZ's FIOS network... however I suspect that if they are using a Redback at the Headend, it would allow you to have a 'bridge' network with secure arp settings. (it's a feature that we have seen on Redback's...) Allows you to have a 'flat network' for all your subs, and there is a mechanism built in to allow for assign static ip's and also not allowing for someone to 'fake' / 'steal' someone else assigned IP's. This is nice, because one can be very efficient in their use of IPv4 addresses.... This is why I had said earlier that some of these networks are built with infrastructure that is not designed / meant to run advance routing protocols for an End User customers... too much overhead in running bgp sessions to hand off a single IP or even a /29 ........ Faisal Imtiaz Snappy Internet& Telecom On 3/14/2012 9:13 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Faisal Imtiaz" >> Is that is needed, what is wrong with that ? > Well, we just had FiOS Business 150/65 dropped this week, and my /27 isn't > even a /27; we're sharing a /24 with, presumably, a bunch of other customers. > > Not sure how BGP would handle that... > > Cheers, > -- jra From morrowc.lists at gmail.com Wed Mar 14 09:41:23 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 14 Mar 2012 10:41:23 -0400 Subject: shared address space... a reality! In-Reply-To: <4F608701.6040203@kenweb.org> References: <4F608701.6040203@kenweb.org> Message-ID: On Wed, Mar 14, 2012 at 7:54 AM, ML wrote: > On 3/14/2012 2:22 AM, Christopher Morrow wrote: >> >> NetRange: ? ? ? 100.64.0.0 - 100.127.255.255 >> CIDR: ? ? ? ? ? 100.64.0.0/10 >> OriginAS: >> NetName: ? ? ? ?SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED >> > > > Did IANA have to justify this space to ARIN or was it just given to them no > questions asked because a draft RFC specified a need for a /10? see the discussion in PPML/arin-announce... my recollection is something like this happened (paraphrased for the tl/dr crowd): 1) someone wanted more 1918^H^H^Hshared-transition space 2) a policy proposal came to ARIN's PP meeting 3) the policy proposal ran around for a time making friends 4) the proposal passed and the ARIN BoT essentially got a message from IANA/IESG saying: "Hey, before you leap... lookout, perhaps the IETF should weigh in?" 5) an IETF draft was drafted (which later had a baby... so there are 2 versions/parts flying about) 6) the main draft was finalized and sent along to the RFC editor, and made into a BCP 7) IANA received this /10 from ARIN -chris From Valdis.Kletnieks at vt.edu Wed Mar 14 11:18:28 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 14 Mar 2012 12:18:28 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: Your message of "Tue, 13 Mar 2012 20:13:41 PDT." <231E08F7-7078-4721-BF5F-569DD99E045F@delong.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> <386ca181-dbc5-4ce1-9cd7-6af4dbe047ec@s7g2000yqm.googlegroups.com> <231E08F7-7078-4721-BF5F-569DD99E045F@delong.com> Message-ID: <6288.1331741908@turing-police.cc.vt.edu> On Tue, 13 Mar 2012 20:13:41 PDT, Owen DeLong said: > I expect within my lifetime that multi-gigabit ethernet will become > commonplace in the household LAN environment and that when that > becomes reality, localized IP Multicast over multi-gigabit ethernet > will eventually supplant HDMI as the primary transport for audio/video > streams between devices (sources such as BD players, DVRs, > computers, etc. and destinations such as receivers/amps, monitors, > speaker drivers, etc.). The only reason you got HDMI at all was because the content owners managed to get HDCP included. You won't get a replacement that doesn't do HDCP until we fix the sorry state of copyright in the US. So it's equivalent to asking if we're going to fix copyright within your lifetime... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From leigh.porter at ukbroadband.com Wed Mar 14 11:39:21 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 14 Mar 2012 16:39:21 +0000 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <6288.1331741908@turing-police.cc.vt.edu> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> <386ca181-dbc5-4ce1-9cd7-6af4dbe047ec@s7g2000yqm.googlegroups.com> <231E08F7-7078-4721-BF5F-569DD99E045F@delong.com> <6288.1331741908@turing-police.cc.vt.edu> Message-ID: > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > > The only reason you got HDMI at all was because the content owners > managed to get HDCP included. You won't get a replacement that doesn't > do HDCP until we fix the sorry state of copyright in the US. > > So it's equivalent to asking if we're going to fix copyright within > your lifetime... :) When the revolution comes, all will be fixed. -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From thomas.m.king at gmail.com Wed Mar 14 11:39:17 2012 From: thomas.m.king at gmail.com (Thomas King) Date: Wed, 14 Mar 2012 17:39:17 +0100 Subject: Email Integration / Account Migration In-Reply-To: References: <201203081724.05236.lowen@pari.edu> <4F5E2B55.20604@gmail.com> <4F5E740E.5040505@paulgraydon.co.uk> <51FDF739-7B10-43C6-949C-06C5802780B9@delong.com> <4F5F670A.8050705@gmail.com> Message-ID: Hi all, I suggest to check out www.audriga.com which runs www.email-umzug.de and www.groupware-migration.com. They are from Germany and adhere the EU data privacy regulations. I have to disclose that I am one of the founders of www.audriga.com. :-) So, if you have any questions about www.audriga.com please feel free to contact me. Best regards, Thomas 2012/3/13 Anurag Bhatia : > Hello Mike > > > You can look for my friends form shuttlecloud.com > > They are much into hard core data migration. > > On Tue, Mar 13, 2012 at 9:06 PM, Mike Rae wrote: > >> Hi : >> >> If there is anyone out there that has experience with migrating Email from >> one ISP to another at the retail level using products such as the "True >> Switch" product from ESAYA, and would be willing to share some >> thoughts/experiences, could you please contact me off list ? >> >> Thanks >> mike >> >> >> > > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com From mikea at mikea.ath.cx Wed Mar 14 11:42:25 2012 From: mikea at mikea.ath.cx (Mike Andrews) Date: Wed, 14 Mar 2012 11:42:25 -0500 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> <386ca181-dbc5-4ce1-9cd7-6af4dbe047ec@s7g2000yqm.googlegroups.com> <231E08F7-7078-4721-BF5F-569DD99E045F@delong.com> <6288.1331741908@turing-police.cc.vt.edu> Message-ID: <20120314164225.GG79569@mikea.ath.cx> On Wed, Mar 14, 2012 at 04:39:21PM +0000, Leigh Porter wrote: > > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > > > > The only reason you got HDMI at all was because the content owners > > managed to get HDCP included. You won't get a replacement that doesn't > > do HDCP until we fix the sorry state of copyright in the US. > > So it's equivalent to asking if we're going to fix copyright within > > your lifetime... :) > When the revolution comes, all will be fixed. Mmmmmhmmmmm. Yeah. But until then, it's equivalent to solving the halting problem. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From bonomi at mail.r-bonomi.com Wed Mar 14 11:55:51 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 14 Mar 2012 11:55:51 -0500 (CDT) Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <20120314164225.GG79569@mikea.ath.cx> Message-ID: <201203141655.q2EGtpCc068909@mail.r-bonomi.com> Mike Andrews wrote: > On Wed, Mar 14, 2012 at 04:39:21PM +0000, Leigh Porter wrote: > > > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > > > > > > The only reason you got HDMI at all was because the content owners > > > managed to get HDCP included. You won't get a replacement that doesn't > > > do HDCP until we fix the sorry state of copyright in the US. > > > > So it's equivalent to asking if we're going to fix copyright within > > > your lifetime... :) > > > When the revolution comes, all will be fixed. > > Mmmmmhmmmmm. Yeah. But until then, it's equivalent to solving the > halting problem. "Come the revolution, things will be different." Not necessarily -better-, but _different_. From ndavis at arin.net Wed Mar 14 12:22:24 2012 From: ndavis at arin.net (Nate Davis) Date: Wed, 14 Mar 2012 17:22:24 +0000 Subject: shared address space... a reality! In-Reply-To: Message-ID: Thanks Chris for the update to the list. One minor clarification for the community with regards to: 4) the proposal passed and the ARIN BoT essentially got a message from IANA/IESG saying: "Hey, before you leap... lookout, perhaps the IETF should weigh in?" After the ARIN Advisory Council forwarded the policy to the ARIN Board of Trustees for consideration, the Trustees directed the President, John Curran, to consult with the IAB and IESG on the potential issues of adopting said draft policy prior to taking any further policy action. Regards, Nate Davis Chief Operating Officer American Registry for Internet Numbers From mehmet at akcin.net Wed Mar 14 13:41:01 2012 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 14 Mar 2012 11:41:01 -0700 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <4F609EC5.4000906@snappydsl.net> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> Message-ID: <83A260AA-7580-4220-BDBF-CEB87310AB5D@akcin.net> As far as I know only ISP that will let you do BGP with them on DSL is Sonic and their Fusion service is awesome but very limited to bay area. they rock though. mehmet On Mar 14, 2012, at 6:36 AM, Faisal Imtiaz wrote: > I am not familiar with VZ's FIOS network... > however I suspect that if they are using a Redback at the Headend, it > would allow you to have a 'bridge' network with secure arp settings. > (it's a feature that we have seen on Redback's...) > > Allows you to have a 'flat network' for all your subs, and there is a > mechanism built in to allow for assign static ip's and also not allowing > for someone to 'fake' / 'steal' someone else assigned IP's. This is > nice, because one can be very efficient in their use of IPv4 addresses.... > > This is why I had said earlier that some of these networks are built > with infrastructure that is not designed / meant to run advance routing > protocols for an End User customers... too much overhead in running bgp > sessions to hand off a single IP or even a /29 ........ > > > Faisal Imtiaz > Snappy Internet& Telecom > > > On 3/14/2012 9:13 AM, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Faisal Imtiaz" >>> Is that is needed, what is wrong with that ? >> Well, we just had FiOS Business 150/65 dropped this week, and my /27 isn't >> even a /27; we're sharing a /24 with, presumably, a bunch of other customers. >> >> Not sure how BGP would handle that... >> >> Cheers, >> -- jra > > From owen at delong.com Wed Mar 14 13:41:21 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 14 Mar 2012 11:41:21 -0700 Subject: shared address space... a reality! In-Reply-To: References: <4F608701.6040203@kenweb.org> Message-ID: On Mar 14, 2012, at 7:41 AM, Christopher Morrow wrote: > On Wed, Mar 14, 2012 at 7:54 AM, ML wrote: >> On 3/14/2012 2:22 AM, Christopher Morrow wrote: >>> >>> NetRange: 100.64.0.0 - 100.127.255.255 >>> CIDR: 100.64.0.0/10 >>> OriginAS: >>> NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED >>> >> >> >> Did IANA have to justify this space to ARIN or was it just given to them no >> questions asked because a draft RFC specified a need for a /10? > > see the discussion in PPML/arin-announce... my recollection is > something like this happened (paraphrased for the tl/dr crowd): > 1) someone wanted more 1918^H^H^Hshared-transition space > 2) a policy proposal came to ARIN's PP meeting > 3) the policy proposal ran around for a time making friends > 4) the proposal passed and the ARIN BoT essentially got a message from > IANA/IESG saying: > "Hey, before you leap... lookout, perhaps the IETF should weigh in?" Well, actually, the ARIN board^H^H^H^H^HCEO went to IESG saying "mother may I" would be a more accurate description of the process. > 5) an IETF draft was drafted (which later had a baby... so there are 2 > versions/parts flying about) Actually, draft-weil was floated before the ARIN policy proposal IIRC. The other draft (draft-bdgks) came after, essentially in response to the statement by the ARIN board/CEO that getting the policy implemented would require IESG approval. > 6) the main draft was finalized and sent along to the RFC editor, and > made into a BCP > > 7) IANA received this /10 from ARIN Otherwise, yeah, I think that about sums it up. Owen From owen at delong.com Wed Mar 14 13:45:19 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 14 Mar 2012 11:45:19 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <6288.1331741908@turing-police.cc.vt.edu> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> <386ca181-dbc5-4ce1-9cd7-6af4dbe047ec@s7g2000yqm.googlegroups.com> <231E08F7-7078-4721-BF5F-569DD99E045F@delong.com> <6288.1331741908@turing-police.cc.vt.edu> Message-ID: <61A67CFD-4E63-43AE-9220-3E49198096D5@delong.com> On Mar 14, 2012, at 9:18 AM, wrote: > On Tue, 13 Mar 2012 20:13:41 PDT, Owen DeLong said: >> I expect within my lifetime that multi-gigabit ethernet will become >> commonplace in the household LAN environment and that when that >> becomes reality, localized IP Multicast over multi-gigabit ethernet >> will eventually supplant HDMI as the primary transport for audio/video >> streams between devices (sources such as BD players, DVRs, >> computers, etc. and destinations such as receivers/amps, monitors, >> speaker drivers, etc.). > > The only reason you got HDMI at all was because the content owners managed > to get HDCP included. You won't get a replacement that doesn't do HDCP until > we fix the sorry state of copyright in the US. > > So it's equivalent to asking if we're going to fix copyright within your lifetime... :) I fully expect them to develop an HDCP-or-equivalent enabled protocol to run over IP Multicast. Do you have any reason you believe that won't happen? Owen From faisal at snappydsl.net Wed Mar 14 13:56:04 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Wed, 14 Mar 2012 14:56:04 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <83A260AA-7580-4220-BDBF-CEB87310AB5D@akcin.net> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <83A260AA-7580-4220-BDBF-CEB87310AB5D@akcin.net> Message-ID: <4F60E9C4.9030907@snappydsl.net> Yes, Dane is not only very smart but also a very sharp and savvy business operator.. But I am also sure they are not doing this as a 'no charge' offering for a 'resi' circuit. Most competitive ISP's (such as Sonic and ourselves) a very flexible to customer's needs and are willing to support custom configurations but .. it has to make business sense...and the underlying infrastructure be able to support that configuration. Faisal Imtiaz Snappy Internet& Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 3/14/2012 2:41 PM, Mehmet Akcin wrote: > As far as I know only ISP that will let you do BGP with them on DSL is Sonic and their Fusion service is awesome but very limited to bay area. > > they rock though. > > mehmet > > > On Mar 14, 2012, at 6:36 AM, Faisal Imtiaz wrote: > >> I am not familiar with VZ's FIOS network... >> however I suspect that if they are using a Redback at the Headend, it >> would allow you to have a 'bridge' network with secure arp settings. >> (it's a feature that we have seen on Redback's...) >> >> Allows you to have a 'flat network' for all your subs, and there is a >> mechanism built in to allow for assign static ip's and also not allowing >> for someone to 'fake' / 'steal' someone else assigned IP's. This is >> nice, because one can be very efficient in their use of IPv4 addresses.... >> >> This is why I had said earlier that some of these networks are built >> with infrastructure that is not designed / meant to run advance routing >> protocols for an End User customers... too much overhead in running bgp >> sessions to hand off a single IP or even a /29 ........ >> >> >> Faisal Imtiaz >> Snappy Internet& Telecom >> >> >> On 3/14/2012 9:13 AM, Jay Ashworth wrote: >>> ----- Original Message ----- >>>> From: "Faisal Imtiaz" >>>> Is that is needed, what is wrong with that ? >>> Well, we just had FiOS Business 150/65 dropped this week, and my /27 isn't >>> even a /27; we're sharing a /24 with, presumably, a bunch of other customers. >>> >>> Not sure how BGP would handle that... >>> >>> Cheers, >>> -- jra >> > From jfbeam at gmail.com Wed Mar 14 14:17:59 2012 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 14 Mar 2012 15:17:59 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <773E9B61-6316-4192-9FFE-D911DC44104A@delong.com> Message-ID: On Wed, 14 Mar 2012 00:19:16 -0400, William Herrin wrote: > Nope. I have FiOS and the 5 IPs. They are 5 IPs, in sequence, at a > completely arbitrary location in a /24 subnet. ... Time Warner (TWTC, not TWC) does the same thing... we have 8 addresses from them... 131 - 138; it's a /24 and we get to use those 8 addresses. [Yes, that causes problems trying to access anything else in that /24] I have no clue what's on the other end of that, and really don't care. (it's more or less bridged ethernet over a T1, that's also carrying voice.) From streiner at cluebyfour.org Wed Mar 14 14:32:19 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 14 Mar 2012 15:32:19 -0400 (EDT) Subject: Verizon FiOS - is BGP an option? In-Reply-To: <4F60E9C4.9030907@snappydsl.net> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <83A260AA-7580-4220-BDBF-CEB87310AB5D@akcin.net> <4F60E9C4.9030907@snappydsl.net> Message-ID: On Wed, 14 Mar 2012, Faisal Imtiaz wrote: > Most competitive ISP's (such as Sonic and ourselves) a very flexible to > customer's needs and are willing to support custom configurations but .. it > has to make business sense...and the underlying infrastructure be able to > support that configuration. I don't think anyone is disagreeing with you, or implying otherwise here. The point (and this goes back to my original post) was that VZ is missing out on revenue (and customer service, but let's not get ahead of ourselves...) opportunities by not offering such a thing as an add-on for their business- class FiOS services. If they brand it and bill at as a business-class service, then allowing someone to multihome using FiOS and something else does not seem like such an unreasonable request. As others have mentioned, if 19262 would toss in a few route-reflectors and let their customers EBGP-multihop to them, that would be a step in the right direction. In the scenario I'm working on at the moment, default, or default+customer routes would be perfectly fine. I neither want nor need a full view for this application. jms From bill at herrin.us Wed Mar 14 15:02:29 2012 From: bill at herrin.us (William Herrin) Date: Wed, 14 Mar 2012 16:02:29 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <83A260AA-7580-4220-BDBF-CEB87310AB5D@akcin.net> <4F60E9C4.9030907@snappydsl.net> Message-ID: On Wed, Mar 14, 2012 at 3:32 PM, Justin M. Streiner wrote: > The point (and this goes back to my original post) was that VZ is missing > out on revenue (and customer service, but let's not get ahead of > ourselves...) > opportunities by not offering such a thing as an add-on for their business- > class FiOS services. ?If they brand it and bill at as a business-class > service, then allowing someone to multihome using FiOS and something else > does not seem like such an unreasonable request. Well... they brand it as a SOHO service and AFAICT they refuse to install "business fios" anywhere zoned commercial. If they would actually connect it to a commercial facility, there'd be no shortage of third parties willing to do a fios line pair plus a tunnel and then drive whatever data over it that you wanted. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From keegan.holley at sungard.com Wed Mar 14 15:18:13 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 14 Mar 2012 16:18:13 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <773E9B61-6316-4192-9FFE-D911DC44104A@delong.com> Message-ID: In defense of the tier 1's it's not as easy as it looks to run BGP with the lower end business customers. On the technical side the edge boxes and links to them would be as overloaded with routes and peers and all of the other PE boxes in an ISP network. Not to mention the changes in routing policies and addressing schemes and the general operation of the service. This obviously isn't the case for every ISP, but I can understand why it's not popular. From faisal at snappydsl.net Wed Mar 14 15:24:08 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Wed, 14 Mar 2012 16:24:08 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <83A260AA-7580-4220-BDBF-CEB87310AB5D@akcin.net> <4F60E9C4.9030907@snappydsl.net> Message-ID: <4F60FE68.3000303@snappydsl.net> On 3/14/2012 3:32 PM, Justin M. Streiner wrote: > On Wed, 14 Mar 2012, Faisal Imtiaz wrote: > >> Most competitive ISP's (such as Sonic and ourselves) a very flexible >> to customer's needs and are willing to support custom configurations >> but .. it has to make business sense...and the underlying >> infrastructure be able to support that configuration. > > I don't think anyone is disagreeing with you, or implying otherwise here. That is understood.. > The point (and this goes back to my original post) was that VZ is > missing out on revenue (and customer service, but let's not get ahead > of ourselves...) Our concept of 'revenue' and large provider's concept of 'revenue' is very different .... > opportunities by not offering such a thing as an add-on for their > business- > class FiOS services. It may sound simple to you and I, but the bigger challenge is on the support side how to deal with a more complex issue, and how to justify having more expensive support engineers ... etc.. > If they brand it and bill at as a business-class > service, then allowing someone to multihome using FiOS and something else > does not seem like such an unreasonable request. > On the surface this does not sound unreasonable, until you take into consideration that Support issues now would requires someone (or more like a team of folks) who is running cost is about $100 to $250 / hr (engineers, support structure, etc etc etc) ...... for a service which is approx in the same $ figure for MRR... > As others have mentioned, if 19262 would toss in a few > route-reflectors and let their customers EBGP-multihop to them, that > would be a step in the right direction. In the scenario I'm working > on at the moment, default, or default+customer routes would be > perfectly fine. I neither want nor need a full view for this > application. > while this is reasonable, we all have to keep in mind, that you can I can 'toss' in route-reflectors for a few hundred to a few thousand dollars each... Folks like VZ and AT&T pay top dollars for top capacity equipment to handle stuff.. so you are talking about a few 'route-reflectors' for $50k or $150k each ? .... (Remember these are the folks who are paying full prices on the Cisco / Juniper boxes.....) if you ever looked at the Cisco Top of the line router.. ( I don't remember what it called, but do remember the starting price for a base config is $250K, going up to $750k... was designed to meet the demands of larger network operators such as VZ / AT&T etc...) As for the Cable Companies, most of them out-source network management / upgrade and upkeep to folks like Scientific Atlanta (a division of Cisco).. that is why when you call in for network support issues, you get someone who is not technically proficient with all aspects of networking... because they don't have them.... >>>> In the scenario I'm working on at the moment, default, or default+customer routes would be perfectly fine. I neither want nor need a full view for this >>>>application. There are existing solutions which are very easy to implement, which will allow you to do this, without having to deal too much with the underlying carrier .... so my question becomes.... if you need this, and you can solve this easily from your side... why do you want a behemoth to change and deliver ?.... (Even if they did you are not going to be happy with how they are performing ...). > jms > > From jra at baylink.com Wed Mar 14 15:33:24 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 14 Mar 2012 16:33:24 -0400 (EDT) Subject: Verizon FiOS - is BGP an option? In-Reply-To: Message-ID: <15125992.5937.1331757204363.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > Well... they brand it as a SOHO service and AFAICT they refuse to > install "business fios" anywhere zoned commercial. I have Business FiOS in 2 rented commercial properties; business office space. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From streiner at cluebyfour.org Wed Mar 14 16:16:08 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 14 Mar 2012 17:16:08 -0400 (EDT) Subject: Verizon FiOS - is BGP an option? In-Reply-To: <4F60FE68.3000303@snappydsl.net> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <83A260AA-7580-4220-BDBF-CEB87310AB5D@akcin.net> <4F60E9C4.9030907@snappydsl.net> <4F60FE68.3000303@snappydsl.net> Message-ID: On Wed, 14 Mar 2012, Faisal Imtiaz wrote: > while this is reasonable, we all have to keep in mind, that you can I can > 'toss' in route-reflectors for a few hundred to a few thousand dollars > each... Folks like VZ and AT&T pay top dollars for top capacity equipment to > handle stuff.. so you are talking about a few 'route-reflectors' for $50k or > $150k each ? .... > (Remember these are the folks who are paying full prices on the Cisco / > Juniper boxes.....) I doubt they are paying list price for their gear. If they are, I'd like to find out who from $carrier pulled the trigger on that deal, so I can talk to them about buying some beachfront property in Kansas ;) Still, point taken, and I didn't mean to suggest that any provider should just throw routers on their network on a whim. I've driven big networks for long enough to know that's not such a good idea. > if you ever looked at the Cisco Top of the line router.. ( I don't remember > what it called, but do remember the starting price for a base config is > $250K, going up to $750k... was designed to meet the demands of larger > network operators such as VZ / AT&T etc...) I have a quote for a pair of them sitting on my desk - not for the customer in question. > There are existing solutions which are very easy to implement, which will > allow you to do this, without having to deal too much with the underlying > carrier I have yet to see such a solution that doesn't: 1. require waiting for DNS records to be updated, at which point you're at the mercy of the providers in question and whatever the TTL is on the DNS records. 2. turn 1 single point of failure into >1 single points of failure. 3. require manual intervention (me getting called at 3 AM) to fix (see item 1). > so my question becomes.... if you need this, and you can solve this easily > from your side... why do you want a behemoth to change and deliver ?.... > (Even if they did you are not going to be happy with how they are performing It was more of a point of wishful thinking and inquiry. I completely understand and accept that said behemoth is unlikely to change their product portfolio based on a thread on NANOG :) jms From jared at compuwizz.net Wed Mar 14 16:58:26 2012 From: jared at compuwizz.net (Jared Geiger) Date: Wed, 14 Mar 2012 17:58:26 -0400 Subject: GRX looking glass In-Reply-To: <095F4877B51D7E44BC5F78803E75615F0222F504@WSEX000.digicelgroup.local> References: <095F4877B51D7E44BC5F78803E75615F0222F504@WSEX000.digicelgroup.local> Message-ID: Telia - http://looking-glass.telia.net/ Telecom Italia - http://gambadilegno.noc.seabone.net/lg/ The GRX option is at the very bottom of both. On Tue, Mar 13, 2012 at 11:50 PM, Gus Crichton < Gus.Crichton at digicelgroup.com> wrote: > Hello, > > Any public looking glasses for GRX? > > Thanks. > > ________________________________ > Notice of Confidentiality: > > The information contained in this communication is intended solely for the > use of the individual or entity to whom it is addressed and others > authorized to receive it. It may contain confidential or legally privileged > information. If you are not the intended recipient you are hereby notified > that any disclosure, copying, distribution or taking any action in reliance > on the contents of this information is strictly prohibited and may be > unlawful. If you have received this communication in error, please notify > us immediately by responding to this email and then delete it from your > system. > From egermann at limanews.com Wed Mar 14 18:07:50 2012 From: egermann at limanews.com (Eric Germann) Date: Wed, 14 Mar 2012 16:07:50 -0700 Subject: GRX looking glass In-Reply-To: References: <095F4877B51D7E44BC5F78803E75615F0222F504@WSEX000.digicelgroup.local> Message-ID: <6244CA0E5130B349820CA2E8B24DC2625065CE89@VA3DIAXVSC31.RED001.local> While we're talking Looking Glasses, any pointers to best practices or pointers for securing a public looking glass, besides the obvious such as don't accept announcements originated from the LG. In a greenfield environment, is Zebra the choice? EKG -----Original Message----- From: Jared Geiger [mailto:jared at compuwizz.net] Sent: Wednesday, March 14, 2012 5:58 PM To: nanog at nanog.org Subject: Re: GRX looking glass Telia - http://looking-glass.telia.net/ Telecom Italia - http://gambadilegno.noc.seabone.net/lg/ The GRX option is at the very bottom of both. On Tue, Mar 13, 2012 at 11:50 PM, Gus Crichton < Gus.Crichton at digicelgroup.com> wrote: > Hello, > > Any public looking glasses for GRX? > > Thanks. > > ________________________________ > Notice of Confidentiality: > > The information contained in this communication is intended solely for > the use of the individual or entity to whom it is addressed and others > authorized to receive it. It may contain confidential or legally > privileged information. If you are not the intended recipient you are > hereby notified that any disclosure, copying, distribution or taking > any action in reliance on the contents of this information is strictly > prohibited and may be unlawful. If you have received this > communication in error, please notify us immediately by responding to > this email and then delete it from your system. > From rs at seastrom.com Wed Mar 14 19:14:08 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 14 Mar 2012 20:14:08 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <4F609EC5.4000906@snappydsl.net> (Faisal Imtiaz's message of "Wed, 14 Mar 2012 09:36:05 -0400") References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> Message-ID: <86lin27mb3.fsf@seastrom.com> Faisal Imtiaz writes: > I am not familiar with VZ's FIOS network... > however I suspect that if they are using a Redback at the Headend, it > would allow you to have a 'bridge' network with secure arp > settings. (it's a feature that we have seen on Redback's...) AFAIK Verizon does not use Redback/Ericsson stuff for FIOS and never has. A cursory survey of two (older, BPON, Tellabs) builds found ethernet OUI 00:90:1a, i.e. Juniper ERX. -r From morrowc.lists at gmail.com Wed Mar 14 19:40:01 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 14 Mar 2012 20:40:01 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <86lin27mb3.fsf@seastrom.com> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> Message-ID: On Wed, Mar 14, 2012 at 8:14 PM, Robert E. Seastrom wrote: > > Faisal Imtiaz writes: > >> I am not familiar with VZ's FIOS network... >> however I suspect that if they are using a Redback at the Headend, it >> would allow you to have a 'bridge' network with secure arp >> settings. (it's a feature that we have seen on Redback's...) > > AFAIK Verizon does not use Redback/Ericsson stuff for FIOS and never has. > > A cursory survey of two (older, BPON, Tellabs) builds found ethernet > OUI 00:90:1a, i.e. Juniper ERX. yes, all edge boxes for FIOS are ERX... better support for CALEA there was one of the major drivers. From morrowc.lists at gmail.com Wed Mar 14 19:54:29 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 14 Mar 2012 20:54:29 -0400 Subject: shared address space... a reality! In-Reply-To: References: Message-ID: On Wed, Mar 14, 2012 at 1:22 PM, Nate Davis wrote: > Thanks Chris for the update to the list. ?One minor clarification for the > community with regards to: > > 4) the proposal passed and the ARIN BoT essentially got a message from > IANA/IESG saying: > ? "Hey, before you leap... lookout, perhaps the IETF should weigh in?" > > > After the ARIN Advisory Council forwarded the policy to the ARIN Board of > Trustees for consideration, > the Trustees directed the President, John Curran, to consult with the IAB > and IESG on the potential > issues of adopting said draft policy prior to taking any further policy > action. thanks! history is important here. From rs at seastrom.com Wed Mar 14 20:00:57 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 14 Mar 2012 21:00:57 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: (Christopher Morrow's message of "Wed, 14 Mar 2012 20:40:01 -0400") References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> Message-ID: <8662e61xva.fsf@seastrom.com> Christopher Morrow writes: > On Wed, Mar 14, 2012 at 8:14 PM, Robert E. Seastrom wrote: >> >> Faisal Imtiaz writes: >> >>> I am not familiar with VZ's FIOS network... >>> however I suspect that if they are using a Redback at the Headend, it >>> would allow you to have a 'bridge' network with secure arp >>> settings. (it's a feature that we have seen on Redback's...) >> >> AFAIK Verizon does not use Redback/Ericsson stuff for FIOS and never has. >> >> A cursory survey of two (older, BPON, Tellabs) builds found ethernet >> OUI 00:90:1a, i.e. Juniper ERX. > > yes, all edge boxes for FIOS are ERX... better support for CALEA there > was one of the major drivers. So it was _one_ of the drivers, but was it a more major driver than "for the love of God, not Redback!"? :) -r From morrowc.lists at gmail.com Wed Mar 14 20:13:56 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 14 Mar 2012 21:13:56 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <8662e61xva.fsf@seastrom.com> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> Message-ID: On Wed, Mar 14, 2012 at 9:00 PM, Robert E. Seastrom wrote: > So it was _one_ of the drivers, but was it a more major driver than > "for the love of God, not Redback!"? ?:) I think there were some significant issues with the redback of the time, but ... near as I recall a pile-o-cash was put forth on both 19262 and 701 to do 'upgrades for CALEA' (at least on 701 those upgrades drove other features as well). In 701-land that ended up as 'lots more E3+ linecards!', in 19262 land that ended up being: "ERX for everyone!" (again, there could have been other drivers, but one major one was indeed 'calea monster!' - one wonders if they've ever even had a calea request to date...) -chris From josh.hoppes at gmail.com Wed Mar 14 20:37:16 2012 From: josh.hoppes at gmail.com (Josh Hoppes) Date: Wed, 14 Mar 2012 20:37:16 -0500 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <61A67CFD-4E63-43AE-9220-3E49198096D5@delong.com> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <585c75dd-160a-48f2-8ea1-7ad610ad9856@i5g2000yqo.googlegroups.com> <4F5F45AB.4010907@necom830.hpcl.titech.ac.jp> <386ca181-dbc5-4ce1-9cd7-6af4dbe047ec@s7g2000yqm.googlegroups.com> <231E08F7-7078-4721-BF5F-569DD99E045F@delong.com> <6288.1331741908@turing-police.cc.vt.edu> <61A67CFD-4E63-43AE-9220-3E49198096D5@delong.com> Message-ID: On Wed, Mar 14, 2012 at 1:45 PM, Owen DeLong wrote: > I fully expect them to develop an HDCP-or-equivalent enabled protocol to run over IP Multicast. > > Do you have any reason you believe that won't happen? > > Owen I'm pretty sure it's already in place for IPTV solutions. From cmaurand at xyonet.com Wed Mar 14 21:14:36 2012 From: cmaurand at xyonet.com (Curtis Maurand) Date: Wed, 14 Mar 2012 22:14:36 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <8662e61xva.fsf@seastrom.com> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> Message-ID: <4F61508C.9040703@xyonet.com> On 3/14/2012 9:00 PM, Robert E. Seastrom wrote: > Christopher Morrow writes: > >> On Wed, Mar 14, 2012 at 8:14 PM, Robert E. Seastrom wrote: >>> Faisal Imtiaz writes: >>> >>>> I am not familiar with VZ's FIOS network... >>>> however I suspect that if they are using a Redback at the Headend, it >>>> would allow you to have a 'bridge' network with secure arp >>>> settings. (it's a feature that we have seen on Redback's...) >>> AFAIK Verizon does not use Redback/Ericsson stuff for FIOS and never has. >>> >>> A cursory survey of two (older, BPON, Tellabs) builds found ethernet >>> OUI 00:90:1a, i.e. Juniper ERX. >> yes, all edge boxes for FIOS are ERX... better support for CALEA there >> was one of the major drivers. > So it was _one_ of the drivers, but was it a more major driver than > "for the love of God, not Redback!"? :) > the last I knew, Verizon was an Alcatel house for switching and Alcatel managed to get tcp/ip into their switching gear. so I'm left to wonder. --C From mohta at necom830.hpcl.titech.ac.jp Wed Mar 14 23:18:04 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 15 Mar 2012 13:18:04 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> Message-ID: <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> Randy Bush wrote: > none of which seem to move us forward. i guess the lesson is that, as > long as we are well below moore, we just keep going down the slippery, > and damned expensive, slope. As long as we keep using IPv4, we are mostly stopping at /24 and must stop at /32. But, see the subject. It's well above moore. For high speed (fixed time) routed look up with 1M entries, SRAM is cheap at /24 and is fine at /32 but expensive and power consuming TCAM is required at /48. That's one reason why we should stay away from IPv6. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Wed Mar 14 23:48:37 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 15 Mar 2012 13:48:37 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> Message-ID: <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> William Herrin wrote: > I've been an IRTF RRG participant and in my day job I build backend > systems for mobile messaging devices used in some very challenging and > very global IP and non-IP environments. I know non-IP mobile environment is heavily encumbered. So, I can understand why you insist on using DNS for mobility only to make IP mobility as encumbered as non-IP ones. > Au contraire. Triangle elimination is a problem because the IP address > can't change with session survivability. But that's because TCP and > UDP require it. If A follows from B and B follows from C then A > follows from C: TCP is at fault. If a correspondent host CH send packets to a mobile host MH, it may be tunneled by a home agent HA or, with triangle elimination, tunneled by CH itself, in both of which cases, IP address of internal packets within tunnels are that of CH and MH's home address, which is handled by TCP just normally. >> Ignoring that DNS does not work so fast, TCP becomes "it wasn't >> sure what addresses it should be talking to" only after a long >> timeout. > > Says who? Our hypothetical TCP can become "unsure" as soon as the > first retransmission if we want it to. It can even become unsure when > handed a packet to send after a long delay with no traffic. There's > little delay kicking off the recheck either way. That may be a encumbered way of doing things in non-IP, or bell headed, mobile systems, where 0.05 second of voice loss is acceptable but 0.2 second of voice loss is significant. However, on the Internet, 0.05 second of packet losses can be significant and things work end to end. In this case, your peer, a mobile host, is the proper end, because it is sure when it has lost or are losing a link. Then, the end establishes a new link with a new IP and initiate update messages for triangle elimination at proper timing without unnecessary checking. According to the end to end argument of Saltzer et. al: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. the mobility module of the mobile host has "the knowledge" for proper timing to update triangle elimination "the function in question". Masataka Ohta From joseph.snyder at gmail.com Thu Mar 15 00:48:32 2012 From: joseph.snyder at gmail.com (Joseph Snyder) Date: Thu, 15 Mar 2012 01:48:32 -0400 Subject: Verizon FiOS - is BGP an option? In-Reply-To: <4F61508C.9040703@xyonet.com> References: <6757717.5837.1331730832776.JavaMail.root@benjamin.baylink.com> <4F609EC5.4000906@snappydsl.net> <86lin27mb3.fsf@seastrom.com> <8662e61xva.fsf@seastrom.com> <4F61508C.9040703@xyonet.com> Message-ID: <593d250e-e8e0-48f5-ba2b-0ef06f81f229@email.android.com> I will just say no on all parts of this current part of the conversation and leave it at that. - j Curtis Maurand wrote: On 3/14/2012 9:00 PM, Robert E. Seastrom wrote: > Christopher Morrow writes: > >> On Wed, Mar 14, 2012 at 8:14 PM, Robert E. Seastrom wrote: >>> Faisal Imtiaz writes: >>> >>>> I am not familiar with VZ's FIOS network... >>>> however I suspect that if they are using a Redback at the Headend, it >>>> would allow you to have a 'bridge' network with secure arp >>>> settings. (it's a feature that we have seen on Redback's...) >>> AFAIK Verizon does not use Redback/Ericsson stuff for FIOS and never has. >>> >>> A cursory survey of two (older, BPON, Tellabs) builds found ethernet >>> OUI 00:90:1a, i.e. Juniper ERX. >> yes, all edge boxes for FIOS are ERX... better support for CALEA there >> was one of the major drivers. > So it was _one_ of the drivers, but was it a more major driver than > "for the love of God, not Redback!"? :) > the last I knew, Verizon was an Alcatel house for switching and Alcatel managed to get tcp/ip into their switching gear. so I'm left to wonder. --C From randy at psg.com Thu Mar 15 01:59:01 2012 From: randy at psg.com (Randy Bush) Date: Thu, 15 Mar 2012 02:59:01 -0400 Subject: shared address space... a reality! In-Reply-To: <4F603AAF.2070101@bogus.com> References: <4F603AAF.2070101@bogus.com> Message-ID: >> NetRange: 100.64.0.0 - 100.127.255.255 >> CIDR: 100.64.0.0/10 > Already updated my martians acl and deployed it internally... and i have configured two home LANs to use it randy From bill at herrin.us Thu Mar 15 02:40:30 2012 From: bill at herrin.us (William Herrin) Date: Thu, 15 Mar 2012 03:40:30 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> Message-ID: 2012/3/15 Masataka Ohta : > William Herrin wrote: >> I've been an IRTF RRG participant and in my day job I build backend >> systems for mobile messaging devices used in some very challenging and >> very global IP and non-IP environments. > > I know non-IP mobile environment is heavily encumbered. So, I > can understand why you insist on using DNS for mobility only > to make IP mobility as encumbered as non-IP ones. I don't understand your statement. None of the technologies I work with use the word "encumbered" in a comparable context. Perhaps you could rephrase? >>> Ignoring that DNS does not work so fast, TCP becomes "it wasn't >>> sure what addresses it should be talking to" only after a long >>> timeout. >> >> Says who? Our hypothetical TCP can become "unsure" as soon as the >> first retransmission if we want it to. It can even become unsure when >> handed a packet to send after a long delay with no traffic. There's >> little delay kicking off the recheck either way. > > That may be a encumbered way of doing things in non-IP, or > bell headed, mobile systems, where 0.05 second of voice > loss is acceptable but 0.2 second of voice loss is > significant. > > However, on the Internet, 0.05 second of packet losses can > be significant and things work end to end. Get real. Even EAPS takes 0.05 seconds to recover from an unexpected link failure and that's on a trivial Ethernet ring where knowledge propagation is far less complex than a mobile environment. For expected link failures, you can't get any fewer than zero packets lost, which is exactly what my add/drop approach delivers. > In this case, your peer, a mobile host, is the proper > end, because it is sure when it has lost or are > losing a link. Correct, but... > Then, the end establishes a new link with a new IP and > initiate update messages for triangle elimination at > proper timing without unnecessary checking. This is where the strategy falls apart every time. You know when your address set changes but you don't know the destination endpoint's instant address set unless either (1) he tells you or (2) he tells a 3rd party which you know to ask. Your set and his set are both in motion so there _will_ be times when your address set changes before he can tell you the changes for his set. Hence #1 alone is an _incomplete_ solution. It was incomplete in SCTP, it was incomplete in Shim6 and it'll be incomplete in MPTCP as well. And oh-by-the-way, if you want to avoid being chatty on every idle connection every time an address set changes and you want either endpoint to be able to reacquire the other when it next has data to send then the probability your destination endpoint has lost all the IP addresses you know about goes way up. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cdel at firsthand.net Thu Mar 15 03:51:18 2012 From: cdel at firsthand.net (Christian de Larrinaga) Date: Thu, 15 Mar 2012 08:51:18 +0000 Subject: shared address space... a reality! In-Reply-To: References: <4F603AAF.2070101@bogus.com> Message-ID: ;-) So that is what "very rough consensus" looks like operationally! IESG Note http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09959.html Christian On 15 Mar 2012, at 06:59, Randy Bush wrote: >>> NetRange: 100.64.0.0 - 100.127.255.255 >>> CIDR: 100.64.0.0/10 >> Already updated my martians acl and deployed it internally... > > and i have configured two home LANs to use it > > randy > From joly at punkcast.com Thu Mar 15 05:08:25 2012 From: joly at punkcast.com (Joly MacFie) Date: Thu, 15 Mar 2012 06:08:25 -0400 Subject: Fwd: IGF 2012 / Nov 6-9, to coincide with IETF 85 In-Reply-To: <20120315100218.228b79ec@mr.leenaa.rs> References: <20120315100218.228b79ec@mr.leenaa.rs> Message-ID: FYI, from ISOC Chapter delegates list. ---------- Forwarded message ---------- From: Michiel Leenaars Date: Thu, Mar 15, 2012 at 5:02 AM Dear all, FYI: just wanted to signal to the chapter delegates that I just found out that the next Internet Governance Forum will take place from November 6-9 2012 in Baku, Azerbejdzan. Probably some of you were aware of this already, but at least I was unaware until today that final dates had been published by the IGF secretariat. The chosen dates unfortunately coincide with the 85th IETF taking place in Atlanta, meaning that many people from the technical community that want to attend the event will not be able to do so. There is also a call for workshops, with a submission deadline of April 12th: http://www.intgovforum.org/cms/w2012 Kind regards, Michiel Leenaars Directeur Internet Society Nederland -------- Telefoon +31 (0)70 314 0385 Prins Willem-Alexanderhof 5 -------- Mobiel: +31 6 27 050947 2595 BE Den Haag ------------------- ENUM: +31 6 27 050947 http://isoc.nl/michiel ------------- SIP: michiel at isoc.nl -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From randy at psg.com Thu Mar 15 05:18:29 2012 From: randy at psg.com (Randy Bush) Date: Thu, 15 Mar 2012 06:18:29 -0400 Subject: shared address space... a reality! In-Reply-To: References: <4F603AAF.2070101@bogus.com> Message-ID: > ;-) So that is what "very rough consensus" looks like operationally! seems to be From eugen at leitl.org Thu Mar 15 05:54:15 2012 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 15 Mar 2012 11:54:15 +0100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> References: <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> Message-ID: <20120315105415.GC9891@leitl.org> On Thu, Mar 15, 2012 at 01:18:04PM +0900, Masataka Ohta wrote: > As long as we keep using IPv4, we are mostly stopping at /24 and > must stop at /32. > > But, see the subject. It's well above moore. > > For high speed (fixed time) routed look up with 1M entries, SRAM is > cheap at /24 and is fine at /32 but expensive and power consuming > TCAM is required at /48. > > That's one reason why we should stay away from IPv6. What prevents you from using http://www.nature.com/ncomms/journal/v1/n6/full/ncomms1063.html with IPv6? From mohta at necom830.hpcl.titech.ac.jp Thu Mar 15 07:52:54 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 15 Mar 2012 21:52:54 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> Message-ID: <4F61E626.80603@necom830.hpcl.titech.ac.jp> William Herrin wrote: >> I know non-IP mobile environment is heavily encumbered. So, I >> can understand why you insist on using DNS for mobility only >> to make IP mobility as encumbered as non-IP ones. > > I don't understand your statement. None of the technologies I work > with use the word "encumbered" in a comparable context. Perhaps you > could rephrase? OK. You are bell headed. >> However, on the Internet, 0.05 second of packet losses can >> be significant and things work end to end. > > Get real. Even EAPS takes 0.05 seconds to recover from an unexpected > link failure If you keep two or more links, keep them alive, and let them know their IP addresses each other, which can be coordinated by mobile hosts as the ends, links can cooperate to avoid broken links for a lot faster recovery than 0.05s. > and that's on a trivial Ethernet ring where knowledge > propagation is far less complex than a mobile environment. The previous statement of mine merely assumes radio links with sudden link failure by, say, phasing. Its spatial diversity arranged by the mobile hosts as the ends. If link failure is expected several seconds before, which is usual with radio links, mobile hosts can smoothly migrate to a new link without any packet losses, because it has much time to resend possibly lost control packets. >> In this case, your peer, a mobile host, is the proper >> end, because it is sure when it has lost or are >> losing a link. > > Correct, but... > >> Then, the end establishes a new link with a new IP and >> initiate update messages for triangle elimination at >> proper timing without unnecessary checking. > > This is where the strategy falls apart every time. You know when your > address set changes but you don't know the destination endpoint's > instant address set unless Certainly, if two communicating mobile hosts, two ends, changes their IP addresses simultaneously, they can not communicate *DIRECTLY* each other, because they can not receive new IP addresses of their peers. The proper end for the issue is the home agent. Just send triangle elimination messages to the home agent without triangle eliminations. With the new layer of indirection by the home agent, control messages for triangle elimination are sent reliably (though best effort). The home agent knows reachable foreign addresses of mobile hosts, as long as the mobile hosts can tell the home agent their new foreign addresses before the mobile hosts entirely loses their old links. > either (1) he tells you or (2) he tells a > 3rd party which you know to ask. (3) he tells his home agent, his first party, to which you, his second party, ask packet forwarding. Unlike DNS servers, the first party is responsible for its home agent. > Your set and his set are both in > motion so there _will_ be times when your address set changes before > he can tell you the changes for his set. Hence #1 alone is an > _incomplete_ solution. A difficulty to understand the end to end principle is to properly recognize ends. Here, you failed to recognize home agents as the essential ends to support reliable communication to mobile hosts. > It was incomplete in SCTP, it was incomplete in Shim6 and it'll be > incomplete in MPTCP as well. It is complete though shim6 is utterly incomplete. > And oh-by-the-way, if you want to avoid being chatty on every idle > connection every time an address set changes and you want either > endpoint to be able to reacquire the other when it next has data to > send then the probability your destination endpoint has lost all the > IP addresses you know about goes way up. Idle connections may have timeouts for triangle elimination after which they use home agents of their peers. That's how the end to end Internet is working without any packet losses not caused by congestion nor unexpected sudden link failures. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Mar 15 07:57:10 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 15 Mar 2012 21:57:10 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <20120315105415.GC9891@leitl.org> References: <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> <20120315105415.GC9891@leitl.org> Message-ID: <4F61E726.3060606@necom830.hpcl.titech.ac.jp> Eugen Leitl wrote: >> For high speed (fixed time) routed look up with 1M entries, SRAM is >> cheap at /24 and is fine at /32 but expensive and power consuming >> TCAM is required at /48. >> >> That's one reason why we should stay away from IPv6. > > What prevents you from using > http://www.nature.com/ncomms/journal/v1/n6/full/ncomms1063.html > with IPv6? Though I didn't paid $32 to read the full paper, it's like a proposal of geography based addressing. So, I should ask what prevents you from using it with IPv4? Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Mar 15 08:02:38 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 15 Mar 2012 22:02:38 +0900 Subject: shared address space... a reality! In-Reply-To: References: <4F603AAF.2070101@bogus.com> Message-ID: <4F61E86E.7030001@necom830.hpcl.titech.ac.jp> Christian de Larrinaga wrote: > ;-) So that is what "very rough consensus" looks like operationally! > IESG Note > http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09959.html Instead, I wonder whether the last phrases of the note, "the IETF remain committed to the deployment of IPv6" is the consensus, however rough, or not. It might be so, if people silently ignoring IPv6 are not counted. Masataka Ohta From jerome at ceriz.fr Thu Mar 15 08:21:35 2012 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Thu, 15 Mar 2012 14:21:35 +0100 Subject: IX in France In-Reply-To: <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local> References: <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local> Message-ID: <4F61ECDF.6050901@ceriz.fr> Le 21/02/12 17:46, Ido Szargel a ?crit : > It seems that there are 2 "major" players - FranceIX and Equinix FR, can > anyone share their opinions about those? Equinix-IX is cheaper (free Gig-e port) and has more member (including a few big eyeball players with restrictive or selective policies). France-IX has a robust structure and team, seems more stable according to my logs. Both allow private VLANs and commercial services over the public fabric. Panap and Free-IX are dead, PARIX isn't although their site is down on purpose for the pas two years or so. It's a commercial service from Orange / France Telecom (wich is selling AS3215 transit and peering there). -- J?r?me Nicolle 06 19 31 27 14 From jerome at ceriz.fr Thu Mar 15 08:26:04 2012 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Thu, 15 Mar 2012 14:26:04 +0100 Subject: shared address space... a reality! In-Reply-To: References: <4F603AAF.2070101@bogus.com> Message-ID: <4F61EDEC.5090906@ceriz.fr> Le 15/03/12 07:59, Randy Bush a ?crit : > and i have configured two home LANs to use it Sooooo wrong... -- J?r?me Nicolle From eugen at leitl.org Thu Mar 15 08:58:25 2012 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 15 Mar 2012 14:58:25 +0100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F61E726.3060606@necom830.hpcl.titech.ac.jp> References: <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> <20120315105415.GC9891@leitl.org> <4F61E726.3060606@necom830.hpcl.titech.ac.jp> Message-ID: <20120315135825.GJ9891@leitl.org> On Thu, Mar 15, 2012 at 09:57:10PM +0900, Masataka Ohta wrote: > >> That's one reason why we should stay away from IPv6. > > > > What prevents you from using > > http://www.nature.com/ncomms/journal/v1/n6/full/ncomms1063.html > > with IPv6? > > Though I didn't paid $32 to read the full paper, it's like > a proposal of geography based addressing. You can access the free full text at http://arxiv.org/pdf/1009.0267v2.pdf > So, I should ask what prevents you from using it with IPv4? Because IPv4 will be legacy by the time something like this lands, and because IPv6 needs more bits/route so more pain there. From bill at herrin.us Thu Mar 15 09:25:46 2012 From: bill at herrin.us (William Herrin) Date: Thu, 15 Mar 2012 10:25:46 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <20120315135825.GJ9891@leitl.org> References: <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> <20120315105415.GC9891@leitl.org> <4F61E726.3060606@necom830.hpcl.titech.ac.jp> <20120315135825.GJ9891@leitl.org> Message-ID: On Thu, Mar 15, 2012 at 9:58 AM, Eugen Leitl wrote: > On Thu, Mar 15, 2012 at 09:57:10PM +0900, Masataka Ohta wrote: >> >> That's one reason why we should stay away from IPv6. >> > What prevents you from using >> > http://www.nature.com/ncomms/journal/v1/n6/full/ncomms1063.html >> > with IPv6? >> >> Though I didn't paid $32 to read the full paper, it's like >> a proposal of geography based addressing. > > You can access the free full text at http://arxiv.org/pdf/1009.0267v2.pdf Hi Eugen, Geographic routing strategies have been all but proven to irredeemably violate the recursive commercial payment relationships which create the Internet's topology. In other words, they always end up stealing bandwidth on links for which neither the source of the packet nor it's destination have paid for a right to use. This is documented in a 2008 Routing Research Group thread. http://www.ops.ietf.org/lists/rrg/2008/msg01781.html If you have a new geographic routing strategy you'd like to table for consideration, start by proving it doesn't share the problem. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From eugen at leitl.org Thu Mar 15 09:41:35 2012 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 15 Mar 2012 15:41:35 +0100 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> <20120315105415.GC9891@leitl.org> <4F61E726.3060606@necom830.hpcl.titech.ac.jp> <20120315135825.GJ9891@leitl.org> Message-ID: <20120315144135.GL9891@leitl.org> On Thu, Mar 15, 2012 at 10:25:46AM -0400, William Herrin wrote: > Geographic routing strategies have been all but proven to irredeemably > violate the recursive commercial payment relationships which create > the Internet's topology. In other words, they always end up stealing > bandwidth on links for which neither the source of the packet nor it's > destination have paid for a right to use. > > This is documented in a 2008 Routing Research Group thread. > http://www.ops.ietf.org/lists/rrg/2008/msg01781.html > > If you have a new geographic routing strategy you'd like to table for > consideration, start by proving it doesn't share the problem. I think the problem can be tackled by implementing this in wireless last-mile networks owned and operated by end users. (Obviously the /64 space is enough to carry that information. Long-range could be done via VPN overlay over the Internet). This will reduce the local chatter for route discovery and remove some of the last-mile load on wired connections, which is in ISPs' interest. I think we'll see some 1-10 GBit/s effective bandwidth in sufficiently small wireless cells. If this scenario plays out, this will inch up to low-end gear like Mikrotik and eventually move to the core. I don't think this will initially happen in the network core for the reasons you mentioned. From scott.brim at gmail.com Thu Mar 15 09:44:59 2012 From: scott.brim at gmail.com (Scott Brim) Date: Thu, 15 Mar 2012 10:44:59 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <20120315144135.GL9891@leitl.org> References: <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> <20120315105415.GC9891@leitl.org> <4F61E726.3060606@necom830.hpcl.titech.ac.jp> <20120315135825.GJ9891@leitl.org> <20120315144135.GL9891@leitl.org> Message-ID: On Thu, Mar 15, 2012 at 10:41, Eugen Leitl wrote: > On Thu, Mar 15, 2012 at 10:25:46AM -0400, William Herrin wrote: > >> Geographic routing strategies have been all but proven to irredeemably >> violate the recursive commercial payment relationships which create >> the Internet's topology. In other words, they always end up stealing >> bandwidth on links for which neither the source of the packet nor it's >> destination have paid for a right to use. >> >> This is documented in a 2008 Routing Research Group thread. >> http://www.ops.ietf.org/lists/rrg/2008/msg01781.html > I think the problem can be tackled by implementing this in > wireless last-mile networks owned and operated by end users. Interesting point, and the growth in municipal networks could help. But they are still a vast minority. Scott From jcurran at arin.net Thu Mar 15 10:34:22 2012 From: jcurran at arin.net (John Curran) Date: Thu, 15 Mar 2012 15:34:22 +0000 Subject: shared address space... a reality! In-Reply-To: References: Message-ID: <86B7574E-7917-45C0-8B79-F5EE8C969C79@corp.arin.net> On Mar 14, 2012, at 6:54 PM, Christopher Morrow wrote: > > thanks! history is important here. Policy proposals for "specialized technical allocations" are best considered by the IETF. ARIN was aware of the RFC 2860 (the MOU between ICANN and the IAB) which said as much, and once we confirmed this understanding with the IAB, ARIN directed the community to make use of the IETF process to develop an appropriate RFC for an IANA assignment. ARIN was notified by the IANA that the RFC was approved and was asked if we could assign sufficient resources to them for this purpose. The ARIN Board approved assigning back to the IANA a /10 block out of one of the /8's we received from them in 2010. The IANA registry has been now updated accordingly: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml#note5 Thanks! (and hope this clarifies things) /John John Curran President and CEO ARIN From morrowc.lists at gmail.com Thu Mar 15 10:38:03 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 15 Mar 2012 11:38:03 -0400 Subject: shared address space... a reality! In-Reply-To: <86B7574E-7917-45C0-8B79-F5EE8C969C79@corp.arin.net> References: <86B7574E-7917-45C0-8B79-F5EE8C969C79@corp.arin.net> Message-ID: On Thu, Mar 15, 2012 at 11:34 AM, John Curran wrote: > On Mar 14, 2012, at 6:54 PM, Christopher Morrow wrote: >> >> thanks! history is important here. > reading this this morning, my comment sounds more flippant than I meant. I really did mean that getting the details right was important. > Policy proposals for "specialized technical allocations" > are best considered by the IETF. ?ARIN was aware of the > RFC 2860 (the MOU between ICANN and the IAB) which said > as much, and once we confirmed this understanding with > the IAB, ARIN directed the community to make use of the > IETF process to develop an appropriate RFC for an IANA > assignment. > > ARIN was notified by the IANA that the RFC was approved > and was asked if we could assign sufficient resources to > them for this purpose. ?The ARIN Board approved assigning > back to the IANA a /10 block out of one of the /8's we > received from them in 2010. ?The IANA registry has been > now updated accordingly: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml#note5 > > Thanks! (and hope this clarifies things) does, thanks! > > John Curran > President and CEO > ARIN > > > > > > > From bill at herrin.us Thu Mar 15 12:11:05 2012 From: bill at herrin.us (William Herrin) Date: Thu, 15 Mar 2012 13:11:05 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <20120315144135.GL9891@leitl.org> References: <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> <20120315105415.GC9891@leitl.org> <4F61E726.3060606@necom830.hpcl.titech.ac.jp> <20120315135825.GJ9891@leitl.org> <20120315144135.GL9891@leitl.org> Message-ID: On Thu, Mar 15, 2012 at 10:41 AM, Eugen Leitl wrote: > On Thu, Mar 15, 2012 at 10:25:46AM -0400, William Herrin wrote: >> Geographic routing strategies have been all but proven to irredeemably >> violate the recursive commercial payment relationships which create >> the Internet's topology. In other words, they always end up stealing >> bandwidth on links for which neither the source of the packet nor it's >> destination have paid for a right to use. > > I think the problem can be tackled by implementing this in > wireless last-mile networks owned and operated by end users. > (Obviously the /64 space is enough to carry that information. > Long-range could be done via VPN overlay over the Internet). If an endpoint is allowed to have multiple addresses and allowed to rapidly change addresses then a more optimal last-mile solution is dynamic topological address delegation. Each IP represents a current-best-path coreward through the ISP's network. When the path changes, so do the downstream addresses. Instead of a routing protocol you have an addressing protocol. In theory, such a thing automatically aggregates into very small routing tables. Very much a work in progress: http://bill.herrin.us/network/name/nr1.gif http://bill.herrin.us/network/name/nr2.gif http://bill.herrin.us/network/name/nr3.gif Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Thu Mar 15 12:31:42 2012 From: bill at herrin.us (William Herrin) Date: Thu, 15 Mar 2012 13:31:42 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F61E626.80603@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> Message-ID: 2012/3/15 Masataka Ohta : > William Herrin wrote: >>> I know non-IP mobile environment is heavily encumbered. So, I >>> can understand why you insist on using DNS for mobility only >>> to make IP mobility as encumbered as non-IP ones. >> >> I don't understand your statement. None of the technologies I work >> with use the word "encumbered" in a comparable context. Perhaps you >> could rephrase? > > OK. You are bell headed. If you want to be snippy in English, you should first gain a better command of the language. Neither of your previous statements has a meaning recognized beyond the confines of your own brain. >> Your set and his set are both in >> motion so there _will_ be times when your address set changes before >> he can tell you the changes for his set. Hence #1 alone is an >> _incomplete_ solution. > > A difficulty to understand the end to end principle is to > properly recognize ends. > > Here, you failed to recognize home agents as the essential > ends to support reliable communication to mobile hosts. A device which relays IP packets is not an endpoint, it's a router. It may or may not be a worthy part of a network architecture but it is unambiguously not an endpoint. If that isn't clear to you then don't presume to lecture me about the end to end principle. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From hvgeekwtrvl at gmail.com Thu Mar 15 12:38:05 2012 From: hvgeekwtrvl at gmail.com (james machado) Date: Thu, 15 Mar 2012 10:38:05 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> Message-ID: 2012/3/14 Masataka Ohta : < stuff deleted > > For high speed (fixed time) routed look up with 1M entries, SRAM is > cheap at /24 and is fine at /32 but expensive and power consuming > TCAM is required at /48. > > That's one reason why we should stay away from IPv6. > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Masataka Ohta > I found this bit of research from 2007 ( http://www.cise.ufl.edu/~wlu/papers/tcam.pdf ). It seems to me there are probably more ways to mix and match different types of ram to be able to deal with this beast. james From Valdis.Kletnieks at vt.edu Thu Mar 15 12:48:14 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Mar 2012 13:48:14 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: Your message of "Thu, 15 Mar 2012 13:31:42 EDT." References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> Message-ID: <161600.1331833694@turing-police.cc.vt.edu> On Thu, 15 Mar 2012 13:31:42 EDT, William Herrin said: > 2012/3/15 Masataka Ohta : > > OK. You are bell headed. > > If you want to be snippy in English, you should first gain a better > command of the language. Neither of your previous statements has a > meaning recognized beyond the confines of your own brain. http://www.pcmag.com/encyclopedia_term/0,2542,t=Bellhead&i=38536,00.asp I don't think the term means what Masataka thinks it means, because nobody in this discussion is talking in terms of circuits rather than packet routing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From tim at pelican.org Thu Mar 15 13:23:13 2012 From: tim at pelican.org (Tim Franklin) Date: Thu, 15 Mar 2012 18:23:13 -0000 (GMT) Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <161600.1331833694@turing-police.cc.vt.edu> Message-ID: <28d6bb97-361f-42bd-a25a-b22074da10a0@mail.pelican.org> > I don't think the term means what Masataka thinks it means, because nobody > in this discussion is talking in terms of circuits rather than packet routing. Geographical addressing can tend towards "bellhead thinking", in the sense that it assumes a small number (one?) of suppliers servicing all end users in a geographical area, low mobility, higher traffic volumes towards other end-users in the same or a close geography, relative willingness to renumber when a permanent change of location does occur, and simple, tightly defined interconnects where these single-suppliers can connect to the neighbouring single-supplier and their block of geography. I'm not sure he's right, but I think I understand what he's getting at. Regards, Tim. From mark at viviotech.net Thu Mar 15 13:36:54 2012 From: mark at viviotech.net (Mark Keymer) Date: Thu, 15 Mar 2012 11:36:54 -0700 Subject: Anyone have experience with Adconion Direct? Message-ID: <4F6236C6.4020509@viviotech.net> I was wondering if anyone has any experience with Adconion Direct? It is the standard we want a server with lots of IP's. And I am thinking he is probably a spammer or what not. However unlike most of the requests we get like this, they look to have the most legit looking profile I have seen. I am thinking they are a company I don't want to host. But I thought I would check with the community here and see what others might know about these guys. Also along the lines of spammers and or similar activities is there a good resource for looking up people/companies that might be not so legit? I know of the ROKSO that spamhaus has but from what I have seen it is hard to even report spammer to them and wasn't sure how active that was getting updated these days. Sincerely, Mark From Valdis.Kletnieks at vt.edu Thu Mar 15 14:03:02 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Mar 2012 15:03:02 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: Your message of "Thu, 15 Mar 2012 21:52:54 +0900." <4F61E626.80603@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> Message-ID: <165336.1331838182@turing-police.cc.vt.edu> On Thu, 15 Mar 2012 21:52:54 +0900, Masataka Ohta said: > > Get real. Even EAPS takes 0.05 seconds to recover from an unexpected > > link failure > > If you keep two or more links, keep them alive, and let them > know their IP addresses each other, which can be coordinated > by mobile hosts as the ends, links can cooperate to avoid > broken links for a lot faster recovery than 0.05s. May work for detecting a dead access point in a wireless mesh, but it doesn't scale to WAN sized connections. Standard systems control theory tells us that you can't control a system in less than 2*RTT across the network. There's *plenty* of network paths where endpoint-homebase-endpoint will be over 50ms. Consider the case where one endpoint is in Austria, the other is in Boston, and the node handling the mobility is in Japan. Now a router fails in Seattle. How long will it take for the endpoints to notice? (Alternatively, explain how you locate a suitable home base node closer than Japan. Remember in your explanation to consider that you may not have a business relationship with the carrier that would be an optimum location) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From andy-nanog at bash.sh Thu Mar 15 15:23:37 2012 From: andy-nanog at bash.sh (Andrew Mulholland) Date: Thu, 15 Mar 2012 16:23:37 -0400 Subject: Anyone have experience with Adconion Direct? In-Reply-To: <4F6236C6.4020509@viviotech.net> References: <4F6236C6.4020509@viviotech.net> Message-ID: Hi I do. I know their head of Ops (Hal) quite well as I used to work with him at a previous company. They are an advertising delivery network, rather than spammers. I've pinged him on Skype to ask more. thanks Andrew On Thu, Mar 15, 2012 at 2:36 PM, Mark Keymer wrote: > I was wondering if anyone has any experience with Adconion Direct? > > It is the standard we want a server with lots of IP's. And I am thinking > he is probably a spammer or what not. However unlike most of the requests > we get like this, they look to have the most legit looking profile I have > seen. > > I am thinking they are a company I don't want to host. But I thought I > would check with the community here and see what others might know about > these guys. > > Also along the lines of spammers and or similar activities is there a good > resource for looking up people/companies that might be not so legit? I know > of the ROKSO that spamhaus has but from what I have seen it is hard to even > report spammer to them and wasn't sure how active that was getting updated > these days. > > Sincerely, > > Mark > > From george.herbert at gmail.com Thu Mar 15 15:35:13 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 15 Mar 2012 13:35:13 -0700 Subject: shared address space... a reality! In-Reply-To: <4F61EDEC.5090906@ceriz.fr> References: <4F603AAF.2070101@bogus.com> <4F61EDEC.5090906@ceriz.fr> Message-ID: What, senior network people testing out new test/transitional space at home before they test it at work is bad? On Thu, Mar 15, 2012 at 6:26 AM, J?r?me Nicolle wrote: > Le 15/03/12 07:59, Randy Bush a ?crit : >> and i have configured two home LANs to use it > > Sooooo wrong... > > -- > J?r?me Nicolle > -- -george william herbert george.herbert at gmail.com From rs at seastrom.com Thu Mar 15 15:57:44 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 15 Mar 2012 16:57:44 -0400 Subject: shared address space... a reality! In-Reply-To: (George Herbert's message of "Thu, 15 Mar 2012 13:35:13 -0700") References: <4F603AAF.2070101@bogus.com> <4F61EDEC.5090906@ceriz.fr> Message-ID: <86vcm5y43b.fsf@seastrom.com> More like "wasting no time in fulfilling the prophesy that people will treat it like just another rfc1918 space and deploy it wherever they want". not that randy is likely to get bitten because he's not behind a cgn nor is he planning to be, but still, that took all of what, 72 hours? -r George Herbert writes: > What, senior network people testing out new test/transitional space at > home before they test it at work is bad? > > On Thu, Mar 15, 2012 at 6:26 AM, J?r?me Nicolle wrote: >> Le 15/03/12 07:59, Randy Bush a ?crit : >>> and i have configured two home LANs to use it >> >> Sooooo wrong... >> >> -- >> J?r?me Nicolle >> > > > > -- > -george william herbert > george.herbert at gmail.com From Valdis.Kletnieks at vt.edu Thu Mar 15 16:03:46 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Mar 2012 17:03:46 -0400 Subject: shared address space... a reality! In-Reply-To: Your message of "Thu, 15 Mar 2012 13:35:13 PDT." References: <4F603AAF.2070101@bogus.com> <4F61EDEC.5090906@ceriz.fr> Message-ID: <244371.1331845426@turing-police.cc.vt.edu> On Thu, 15 Mar 2012 13:35:13 PDT, George Herbert said: > What, senior network people testing out new test/transitional space at > home before they test it at work is bad? Either that, or Randy was being snarky about how long the promise to *only* use the address space for numbering CGN interfaces and not as additional RFC1918 space was going to last in reality.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bensons at queuefull.net Thu Mar 15 16:08:01 2012 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 15 Mar 2012 16:08:01 -0500 Subject: shared address space... a reality! In-Reply-To: <86vcm5y43b.fsf@seastrom.com> References: <4F603AAF.2070101@bogus.com> <4F61EDEC.5090906@ceriz.fr> <86vcm5y43b.fsf@seastrom.com> Message-ID: I'm sure it happened much sooner than 72 hours post allocation. In fact, there were probably folks already squatting on that space long before any of this. Maybe their life just got a little easier. :) Cheers, -Benson On Mar 15, 2012, at 3:57 PM, Robert E. Seastrom wrote: > > More like "wasting no time in fulfilling the prophesy that people will > treat it like just another rfc1918 space and deploy it wherever they want". > > not that randy is likely to get bitten because he's not behind a cgn > nor is he planning to be, but still, that took all of what, 72 hours? > > -r > > George Herbert writes: > >> What, senior network people testing out new test/transitional space at >> home before they test it at work is bad? >> >> On Thu, Mar 15, 2012 at 6:26 AM, J?r?me Nicolle wrote: >>> Le 15/03/12 07:59, Randy Bush a ?crit : >>>> and i have configured two home LANs to use it >>> >>> Sooooo wrong... >>> >>> -- >>> J?r?me Nicolle >>> >> >> >> >> -- >> -george william herbert >> george.herbert at gmail.com > From george.herbert at gmail.com Thu Mar 15 16:08:34 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 15 Mar 2012 14:08:34 -0700 Subject: shared address space... a reality! In-Reply-To: <86vcm5y43b.fsf@seastrom.com> References: <4F603AAF.2070101@bogus.com> <4F61EDEC.5090906@ceriz.fr> <86vcm5y43b.fsf@seastrom.com> Message-ID: On Thu, Mar 15, 2012 at 1:57 PM, Robert E. Seastrom wrote: > > More like "wasting no time in fulfilling the prophesy that people will > treat it like just another rfc1918 space and deploy it wherever they want". > > not that randy is likely to get bitten because he's not behind a cgn > nor is he planning to be, but still, that took all of what, 72 hours? > > -r I think this is people reading their preconceived notions onto the situation. I understand the policy disagreement about having the space in the first place. That said... Your and Jerome's reactions seem to amount to "Not only should you never have done this, actually testing it in the normal informal operational area once it's here and approved is a further insult." My counterargument is - if you are suggesting people should be less professional about testing out the new space than they are for any other new thing, then you're being political and not operational. Operationally this is exactly the right thing to have Randy do. He certainly didn't need to do this because he's exhausted 1918 space at home (well, I hope not... 8-). -- -george william herbert george.herbert at gmail.com From bill at herrin.us Thu Mar 15 16:24:23 2012 From: bill at herrin.us (William Herrin) Date: Thu, 15 Mar 2012 17:24:23 -0400 Subject: shared address space... a reality! In-Reply-To: <86vcm5y43b.fsf@seastrom.com> References: <4F603AAF.2070101@bogus.com> <4F61EDEC.5090906@ceriz.fr> <86vcm5y43b.fsf@seastrom.com> Message-ID: On Thu, Mar 15, 2012 at 4:57 PM, Robert E. Seastrom wrote: >> Le 15/03/12 07:59, Randy Bush a ?crit : >>> and i have configured two home LANs to use it > > More like "wasting no time in fulfilling the prophesy that people will > treat it like just another rfc1918 space and deploy it wherever they want". > > not that randy is likely to get bitten because he's not behind a cgn > nor is he planning to be, but still, that took all of what, 72 hours? That's OK. I've configured two home LANs to use 147.28.0.0/16 and I'm not expecting any problems either. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rs at seastrom.com Thu Mar 15 16:25:01 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 15 Mar 2012 17:25:01 -0400 Subject: shared address space... a reality! In-Reply-To: (George Herbert's message of "Thu, 15 Mar 2012 14:08:34 -0700") References: <4F603AAF.2070101@bogus.com> <4F61EDEC.5090906@ceriz.fr> <86vcm5y43b.fsf@seastrom.com> Message-ID: <86k42lwo9e.fsf@seastrom.com> George Herbert writes: > On Thu, Mar 15, 2012 at 1:57 PM, Robert E. Seastrom wrote: >> >> More like "wasting no time in fulfilling the prophesy that people will >> treat it like just another rfc1918 space and deploy it wherever they want". >> >> not that randy is likely to get bitten because he's not behind a cgn >> nor is he planning to be, but still, that took all of what, 72 hours? >> >> -r > > I think this is people reading their preconceived notions onto the situation. > > I understand the policy disagreement about having the space in the > first place. That said... > > Your and Jerome's reactions seem to amount to "Not only should you > never have done this, actually testing it in the normal informal > operational area once it's here and approved is a further insult." > > My counterargument is - if you are suggesting people should be less > professional about testing out the new space than they are for any > other new thing, then you're being political and not operational. > Operationally this is exactly the right thing to have Randy do. > > He certainly didn't need to do this because he's exhausted 1918 space > at home (well, I hope not... 8-). In the unlikely but not impossible event that Randy is on 1918 space at home and has the external address of his consumer home gateway configured into this space, and thence to a CGN appliance or blade in the Big Router at his perimeter where he gets NATted into a globally unique address (i.e., the meat in a NAT444 sandwich), or something similar, then I certainly stand corrected. I encourage this sort of testing. I'm not reading "my preconceived notions" of anything other than Randy's personality and very vocal assertions of what people would do with this space if it got assigned into my assessment of what's going on here. Inasmuch as I am pretty sure I'm in Randy's .procmailrc, y'all will have to ask him directly; don't expect him to chime in replying to my mail. -r From mohta at necom830.hpcl.titech.ac.jp Thu Mar 15 17:56:09 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 16 Mar 2012 07:56:09 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <20120315135825.GJ9891@leitl.org> References: <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> <20120315105415.GC9891@leitl.org> <4F61E726.3060606@necom830.hpcl.titech.ac.jp> <20120315135825.GJ9891@leitl.org> Message-ID: <4F627389.1080008@necom830.hpcl.titech.ac.jp> Eugen Leitl wrote: >> So, I should ask what prevents you from using it with IPv4? > > Because IPv4 will be legacy by the time something like this lands, Maybe. But, IPv6 will be so before IPv4 (or, is already IMHO). > and because IPv6 needs more bits/route so more pain there. Feel free to propose filter everything beyond /32 and get accepted by the community. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Mar 15 18:31:07 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 16 Mar 2012 08:31:07 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> Message-ID: <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> William Herrin wrote: >> A difficulty to understand the end to end principle is to >> properly recognize ends. >> >> Here, you failed to recognize home agents as the essential >> ends to support reliable communication to mobile hosts. > > A device which relays IP packets is not an endpoint, it's a router. If you want to call something which may not participate in routing protocol exchanges a router, that's fine, it's your terminology. But, as far as HA has "the knowledge" obtained through control packet exchanges with MH, it is the end that can give "the help" to make mobile IP correct and complete. > It > may or may not be a worthy part of a network architecture but it is > unambiguously not an endpoint. Even ordinary routers are ends w.r.t. routing protocols, though they also behave as intermediate systems to other routers. As LS requires less intelligence than DV, it converges faster. > If that isn't clear to you then don't presume to lecture me about the > end to end principle. Here is an exercise for you insisting on DNS, an intermediate system. What if DNS servers, including root ones, are mobile? Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Mar 15 19:05:41 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 16 Mar 2012 09:05:41 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <5315F5C7-280C-4BA1-83DC-A4CDBE04EAE4@apnic.net> <2647999A-2351-4437-B7BB-1F1D7703B002@apnic.net> <4F616D7C.7030307@necom830.hpcl.titech.ac.jp> Message-ID: <4F6283D5.5050101@necom830.hpcl.titech.ac.jp> james machado wrote: >> For high speed (fixed time) routed look up with 1M entries, SRAM is >> cheap at /24 and is fine at /32 but expensive and power consuming >> TCAM is required at /48. >> >> That's one reason why we should stay away from IPv6. > I found this bit of research from 2007 ( > http://www.cise.ufl.edu/~wlu/papers/tcam.pdf ). It seems to me there > are probably more ways to mix and match different types of ram to be > able to deal with this beast. But it's not fixed time. Worse, it synthesis IPv6 table from the current IPv4 ones, which means the number of routing table entries is a lot less than 1M. Masataka Ohta From Valdis.Kletnieks at vt.edu Thu Mar 15 19:08:37 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Mar 2012 20:08:37 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: Your message of "Fri, 16 Mar 2012 08:31:07 +0900." <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> Message-ID: <259017.1331856517@turing-police.cc.vt.edu> On Fri, 16 Mar 2012 08:31:07 +0900, Masataka Ohta said: > Here is an exercise for you insisting on DNS, an intermediate > system. > > What if DNS servers, including root ones, are mobile? So, is this question more like: What if computers worked in trinary? or What if people show criminal negligence in misdesigning their networks? You're asking a "what if" for a usage case that nobody sane has suggested. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Thu Mar 15 19:25:35 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 16 Mar 2012 09:25:35 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <165336.1331838182@turing-police.cc.vt.edu> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> <165336.1331838182@turing-police.cc.vt.edu> Message-ID: <4F62887F.9070909@necom830.hpcl.titech.ac.jp> Valdis.Kletnieks at vt.edu wrote: >> If you keep two or more links, keep them alive, and let them >> know their IP addresses each other, which can be coordinated >> by mobile hosts as the ends, links can cooperate to avoid >> broken links for a lot faster recovery than 0.05s. > > May work for detecting a dead access point in a wireless mesh, That's not my point. My point is to avoid dead links. Base stations try sending packets to a MH and if it fails a few times, they forward the packet to other base stations which may have live links to the MH. > but > it doesn't scale to WAN sized connections. Regardless of whether links are wireless or wired, the coordination is necessary only within (small number of) links to which MH, the end, is attached, which means the coordination is a local coordination if coordinated by the end. There is no WAN involved for the coordination. > Consider the case where one endpoint is in Austria, the other is in Boston, > and the node handling the mobility is in Japan. Now a router fails in > Seattle. How long will it take for the endpoints to notice? Huh? > (Alternatively, explain how you locate a suitable home base node No home agent is involved for the recovery. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Mar 15 19:29:44 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 16 Mar 2012 09:29:44 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <259017.1331856517@turing-police.cc.vt.edu> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> <259017.1331856517@turing-police.cc.vt.edu> Message-ID: <4F628978.5010007@necom830.hpcl.titech.ac.jp> Valdis.Kletnieks at vt.edu wrote: > You're asking a "what if" for a usage case that nobody sane has suggested. If you are saying it's insane to use DNS to manage frequently changing locations of mobile hosts instead of relying on immobile home agents, I fully agree with you. Masataka Ohta From mysidia at gmail.com Thu Mar 15 19:49:22 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 15 Mar 2012 19:49:22 -0500 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F628978.5010007@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> <259017.1331856517@turing-police.cc.vt.edu> <4F628978.5010007@necom830.hpcl.titech.ac.jp> Message-ID: 2012/3/15 Masataka Ohta : > Valdis.Kletnieks at vt.edu wrote: >> You're asking a "what if" for a usage case that nobody sane has suggested. > > If you are saying it's insane to use DNS to manage frequently > changing locations of mobile hosts instead of relying on > immobile home agents, I fully agree with you. > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Masataka Ohta Non sequitur. Mobile root DNS servers are what is insane, because the queries must terminate somewhere, and ultimately there must be something that doesn't have a circular dependency -- requiring working DNS to get DNS. As for using DNS to manage frequently changing locations of mobile hosts, DNS is almost perfect for that -- it's just the sort of thing DNS is designed for, depending on how frequent you mean by "frequently changing". -- -JH From Valdis.Kletnieks at vt.edu Thu Mar 15 19:55:43 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Mar 2012 20:55:43 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: Your message of "Fri, 16 Mar 2012 09:29:44 +0900." <4F628978.5010007@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> <259017.1331856517@turing-police.cc.vt.edu> <4F628978.5010007@necom830.hpcl.titech.ac.jp> Message-ID: <261409.1331859343@turing-police.cc.vt.edu> On Fri, 16 Mar 2012 09:29:44 +0900, Masataka Ohta said: > Valdis.Kletnieks at vt.edu wrote: > > > You're asking a "what if" for a usage case that nobody sane has suggested. > > If you are saying it's insane to use DNS to manage frequently > changing locations of mobile hosts instead of relying on > immobile home agents, I fully agree with you. I'm specifically saying that "what if the root servers are mobile?" is a stupid question, because nobody sane has proposed that they be mobile. Hope that makes it clearer for you. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Mar 15 20:10:13 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Mar 2012 21:10:13 -0400 Subject: Clueful security contact at humana.com? Message-ID: <262119.1331860213@turing-police.cc.vt.edu> Anybody know somebody with actual clue at humana.com? The security address I have bounces with "no such user", and their website is sufficiently screwed up that "supported browsers" is hidden under "Legal information". I've identified multiple issues that their infosec team probably wants to deal with... From tknchris at gmail.com Thu Mar 15 20:31:44 2012 From: tknchris at gmail.com (chris) Date: Thu, 15 Mar 2012 21:31:44 -0400 Subject: Clueful security contact at humana.com? In-Reply-To: <262119.1331860213@turing-police.cc.vt.edu> References: <262119.1331860213@turing-police.cc.vt.edu> Message-ID: clue is hard to find these days :( most people seem to not have any clue at all not even a little On Thu, Mar 15, 2012 at 9:10 PM, wrote: > Anybody know somebody with actual clue at humana.com? The security > address I > have bounces with "no such user", and their website is sufficiently > screwed up > that "supported browsers" is hidden under "Legal information". I've > identified > multiple issues that their infosec team probably wants to deal with... > > > From mysidia at gmail.com Thu Mar 15 20:32:09 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 15 Mar 2012 20:32:09 -0500 Subject: shared address space... a reality! In-Reply-To: <86vcm5y43b.fsf@seastrom.com> References: <4F603AAF.2070101@bogus.com> <4F61EDEC.5090906@ceriz.fr> <86vcm5y43b.fsf@seastrom.com> Message-ID: On Thu, Mar 15, 2012 at 3:57 PM, Robert E. Seastrom wrote: > > More like "wasting no time in fulfilling the prophesy that people will > treat it like just another rfc1918 space and deploy it wherever they want". The draft indicates you can deploy it anywhere as long as you meet the special requirement: You have a router capable of performing address translation across router interfaces when addresses are identical on two different interfaces. The other option is that you are a service provider If you meet the router capability requirement you don't have to be a SP. -- -JH From mohta at necom830.hpcl.titech.ac.jp Thu Mar 15 20:36:18 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 16 Mar 2012 10:36:18 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> <259017.1331856517@turing-police.cc.vt.edu> <4F628978.5010007@necom830.hpcl.titech.ac.jp> Message-ID: <4F629912.9030209@necom830.hpcl.titech.ac.jp> Jimmy Hess wrote: >> If you are saying it's insane to use DNS to manage frequently >> changing locations of mobile hosts instead of relying on >> immobile home agents, I fully agree with you. > and ultimately there must be something that > doesn't have a circular dependency It means there is no reason to deny to have immobile home agents. > As for using DNS to manage frequently changing locations of mobile hosts, > DNS is almost perfect for that -- it's just the sort of thing DNS is > designed for, Not at all, because a DNS client has no idea when its peer, a mobile host, changes its location. > depending on how frequent you mean by "frequently changing". Assuming a mobile host changes base stations every 5 seconds (moving at 144km/h with cell diameters of 200m) and old base stations are still usable within 1 second after the changes, a DNS client must check DNS servers every 0.5 second (reserving 0.5 second for RTT and possible retry). Can you still say it almost perfect? Masataka Ohta From frnkblk at iname.com Thu Mar 15 21:15:47 2012 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 15 Mar 2012 21:15:47 -0500 Subject: Verizon FiOS - is BGP an option? In-Reply-To: References: <773E9B61-6316-4192-9FFE-D911DC44104A@delong.com> Message-ID: <006501cd031a$b34bba50$19e32ef0$@iname.com> We have the same problem in our FTTH access network (due to L2 isolation CPE can't directly ARP those in the same subnet), hence the vendor's move towards MAC force forwarding (MACFF). Frank -----Original Message----- From: Ricky Beam [mailto:jfbeam at gmail.com] Sent: Wednesday, March 14, 2012 2:18 PM To: William Herrin Cc: nanog at nanog.org Subject: Re: Verizon FiOS - is BGP an option? On Wed, 14 Mar 2012 00:19:16 -0400, William Herrin wrote: > Nope. I have FiOS and the 5 IPs. They are 5 IPs, in sequence, at a > completely arbitrary location in a /24 subnet. ... Time Warner (TWTC, not TWC) does the same thing... we have 8 addresses from them... 131 - 138; it's a /24 and we get to use those 8 addresses. [Yes, that causes problems trying to access anything else in that /24] I have no clue what's on the other end of that, and really don't care. (it's more or less bridged ethernet over a T1, that's also carrying voice.) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6517 bytes Desc: not available URL: From bill at herrin.us Thu Mar 15 21:40:54 2012 From: bill at herrin.us (William Herrin) Date: Thu, 15 Mar 2012 22:40:54 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> Message-ID: 2012/3/15 Masataka Ohta : > Even ordinary routers are ends w.r.t. routing protocols, though > they also behave as intermediate systems to other routers. > > As LS requires less intelligence than DV, it converges faster. I do believe that's the first time I've heard anybody suggest that a link state routing protocol requires "less intelligence" than a distance vector protocol. >> If that isn't clear to you then don't presume to lecture me about the >> end to end principle. > > Here is an exercise for you insisting on DNS, an intermediate > system. > > ? ? ? ?What if DNS servers, including root ones, are mobile? DNS' basic bootstrapping issues don't change, nor do the solutions. The resovlers find the roots via a set of static well-known layer 3 address which, more and more these days, are actually anycast destinations matching diverse pieces of equipment. It makes no particular sense to enhance their mobility beyond this level. Before you jump up and down and yell "Ah ha!" realize that this is true of a mapping function at any level of the stack. ARP doesn't work without knowing the layer 2 broadcast address and IPv6's ND doesn't work without knowing a static set of multicast addresses. Below the roots, the authoritative zone servers are no different than any other node. If you're willing to tolerate the lowered TTL for your NS server's A and AAAA records then when IP address changes and your parent zone is willing to tolerate dynamic updates for any glue, then you can make DNS updates to the parent zone like any other mobile node. The clients find the recursing resovlers via whatever process assigns the client's IP address, e.g. DHCP or PPP. If it is for some reason useful for the server's base address to change then assign a set of VIPs to the DNS service and route them at layer 3. On the other side of the wall, the recursing resolvers don't particularly care about their source addresses for originating queries to the authoritative servers and will move to the newly favored address with nary a hitch. If you want an actually hard question, try this one: what do you do when fewer than all of the authoritative DNS servers for your node's name are available to receive an update? What do you do when those servers suffer a split brain where each is reachable to some clients but they can't talk to each other? How do you stop bog standard outages from escalating into major network partitions? For that matter, how do you solve the problem with your home agent approach? Is it even capable of having multiple home agents active for each node? How do you keep them in sync? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmaimon at ttec.com Thu Mar 15 21:41:18 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 15 Mar 2012 22:41:18 -0400 Subject: Flexible BGP liist? Message-ID: <4F62A84E.6010208@ttec.com> So we have a wiki list of 1U rack hosting. How about a list of SP's willing to configure BGP over whatever you got, including tunnels? And willing to allocate you space for same? Put me down there. Joe From lsc at prgmr.com Thu Mar 15 22:11:28 2012 From: lsc at prgmr.com (Luke S. Crawford) Date: Thu, 15 Mar 2012 23:11:28 -0400 Subject: Flexible BGP liist? In-Reply-To: <4F62A84E.6010208@ttec.com> References: <4F62A84E.6010208@ttec.com> Message-ID: <20120316031128.GA25702@luke.xen.prgmr.com> On Thu, Mar 15, 2012 at 10:41:18PM -0400, Joe Maimon wrote: > So we have a wiki list of 1U rack hosting. We do? where? all I see on http://nanog.cluepon.net is spam > How about a list of SP's willing to configure BGP over whatever you got, > including tunnels? And willing to allocate you space for same? > > Put me down there. me too. From mohta at necom830.hpcl.titech.ac.jp Thu Mar 15 23:04:04 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 16 Mar 2012 13:04:04 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> Message-ID: <4F62BBB4.8000401@necom830.hpcl.titech.ac.jp> William Herrin wrote: >> As LS requires less intelligence than DV, it converges faster. > > I do believe that's the first time I've heard anybody suggest that a > link state routing protocol requires "less intelligence" than a > distance vector protocol. I mean "intelligence as intermediate systems". DV is a distributed computation by intelligent intermediate systems, whereas, with LS, intermediate systems just flood and computation is by each end. >> Here is an exercise for you insisting on DNS, an intermediate >> system. >> >> What if DNS servers, including root ones, are mobile? > > DNS' basic bootstrapping issues don't change, nor do the solutions. > > The resovlers find the roots via a set of static well-known layer 3 > address You failed to deny MH know layer 3 address of its private HA. It's waste of resource for MH have well known IP address of root servers and domain names of its private DNS server and security keys for dynamic update only to avoid to know IP address of its private HA. > For that matter, how do you solve the problem with your home agent > approach? Is it even capable of having multiple home agents active for > each node? How do you keep them in sync? I actually designed and implemented such a system. Multiple home agents each may have multiple addresses. If some address of HA does not work, MH tries other addresses of HA. If some HA can not communicate with MH, CH may try to use other HA. There is nothing mobility specific. Mobile protocols are modified just as other protocols are modified for multiple addresses. In practice, however, handling multiple addresses is not very useful because selection of the best working address is time consuming unless hosts have default free routing tables. Masataka Ohta From tjc at ecs.soton.ac.uk Fri Mar 16 02:18:14 2012 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 16 Mar 2012 07:18:14 +0000 Subject: shared address space... a reality! In-Reply-To: <244371.1331845426@turing-police.cc.vt.edu> References: <4F603AAF.2070101@bogus.com> <4F61EDEC.5090906@ceriz.fr> <244371.1331845426@turing-police.cc.vt.edu> <3EFF964A-C921-4F9B-9AC3-4EC9026DEB1D@ecs.soton.ac.uk> Message-ID: On 15 Mar 2012, at 21:03, Valdis.Kletnieks at vt.edu wrote: > On Thu, 15 Mar 2012 13:35:13 PDT, George Herbert said: >> What, senior network people testing out new test/transitional space at >> home before they test it at work is bad? > > Either that, or Randy was being snarky about how long the promise to *only* use > the address space for numbering CGN interfaces and not as additional RFC1918 > space was going to last in reality.... So where is that new /10 leaking to already? ;). Tim From ops.lists at gmail.com Fri Mar 16 04:51:03 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 16 Mar 2012 15:21:03 +0530 Subject: Anyone have experience with Adconion Direct? In-Reply-To: <4F6236C6.4020509@viviotech.net> References: <4F6236C6.4020509@viviotech.net> Message-ID: If a company has a ROKSO record, you don't want to host them. And spamhaus IS responsive. Yes they don't take spam reports from people - they got their own traps. They ARE responsive to requests for removal where the request checks out and meets their criteria. On Fri, Mar 16, 2012 at 12:06 AM, Mark Keymer wrote: > > Also along the lines of spammers and or similar activities is there a good > resource for looking up people/companies that might be not so legit? I know > of the ROKSO that spamhaus has but from what I have seen it is hard to even > report spammer to them and wasn't sure how active that was getting updated > these days. -- Suresh Ramasubramanian (ops.lists at gmail.com) From bill at herrin.us Fri Mar 16 08:39:21 2012 From: bill at herrin.us (William Herrin) Date: Fri, 16 Mar 2012 09:39:21 -0400 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: <4F62BBB4.8000401@necom830.hpcl.titech.ac.jp> References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> <4F62BBB4.8000401@necom830.hpcl.titech.ac.jp> Message-ID: 2012/3/16 Masataka Ohta : > William Herrin wrote: >>> As LS requires less intelligence than DV, it converges faster. >> >> I do believe that's the first time I've heard anybody suggest that a >> link state routing protocol requires "less intelligence" than a >> distance vector protocol. > > I mean "intelligence as intermediate systems". > > DV is a distributed computation by intelligent intermediate > systems, whereas, with LS, intermediate systems just flood > and computation is by each end. That's basically wrong. Both systems perform computation on each router. Link State performs much more complex computation to arrive at its export to the forwarding information base. In fact, Distance Vector's calculation is downright trivial in comparison. The difference is that Link State shares the original knowledge, which it can do before recomputing its own tables. Distance Vector recomputes its own state first and then shares each router's state with the neighbors rather than sharing the original knowledge. The result is that the knowledge propagates faster with Link State and each router recomputes only once for each change. In some cases, distance vector will have to recompute several times before the system settles into a new stable state, delaying the process even further. >>> Here is an exercise for you insisting on DNS, an intermediate >>> system. >>> >>> ? ? ?What if DNS servers, including root ones, are mobile? >> >> DNS' basic bootstrapping issues don't change, nor do the solutions. >> >> The resovlers find the roots via a set of static well-known layer 3 >> address > > You failed to deny MH know layer 3 address of its private HA. Here's a tip for effective written communication: the first time in any document that you use an abbreviation that isn't well known, spell it out. > It's waste of resource for MH have well known IP address of > root servers and domain names of its private DNS server and > security keys for dynamic update only to avoid to know IP > address of its private HA. There's no reason for the Mobile Host to know the IP addresses of the root servers. Like any other host, including MH in your plan, it already knows its domain name and the IP addresses of its private DNS servers. That leaves only the security key. So, by your own accounting I swap knowledge of a topology-independent element (the security key) for a topology-dependent element (an IP address) which may change any time you adjust your home agent's required-to-be-landed network with all of today's vagaries around the renumbering problem. >> For that matter, how do you solve the problem with your home agent >> approach? Is it even capable of having multiple home agents active for >> each node? How do you keep them in sync? > > I actually designed and implemented such a system. Multiple > home agents each may have multiple addresses. > > If some address of HA does not work, MH tries other addresses > of HA. > > If some HA can not communicate with MH, CH may try to use other > HA. > > There is nothing mobility specific. Mobile protocols are > modified just as other protocols are modified for multiple > addresses. > > In practice, however, handling multiple addresses is not > very useful because selection of the best working address > is time consuming unless hosts have default free routing > tables. In your home agent architecture, it doesn't matter if they can have multiple addresses. It matters if they can have the same address. Otherwise you're pushing off the generalized continuity of operations problem. One which my DNS add/drop approach handles seamlessly and at a granularity of the individual services on the mobile host. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nanog at rsle.net Fri Mar 16 10:52:32 2012 From: nanog at rsle.net (R. Scott Evans) Date: Fri, 16 Mar 2012 11:52:32 -0400 Subject: Flexible BGP =?UTF-8?Q?liist=3F?= In-Reply-To: <4F62A84E.6010208@ttec.com> References: <4F62A84E.6010208@ttec.com> Message-ID: <86ef215129298dd0d470719fd4432cf7@rsle.net> On Thu, 15 Mar 2012 22:41:18 -0400, Joe Maimon wrote: > So we have a wiki list of 1U rack hosting. > > How about a list of SP's willing to configure BGP over whatever you got, > including tunnels? And willing to allocate you space for same? > > Put me down there. > > Joe I can't speak for IPv4, but I know Hurricane Electric is doing BGP with me for my IPv6 block over a tunnel, free, through their tunnelbroker.net site. -Scott From jerome at ceriz.fr Fri Mar 16 11:00:28 2012 From: jerome at ceriz.fr (=?ISO-8859-1?Q?J=E9r=F4me_Nicolle?=) Date: Fri, 16 Mar 2012 17:00:28 +0100 Subject: Flexible BGP liist? In-Reply-To: <4F62A84E.6010208@ttec.com> References: <4F62A84E.6010208@ttec.com> Message-ID: <4F63639C.60103@ceriz.fr> Le 16/03/12 03:41, Joe Maimon a ?crit : > How about a list of SP's willing to configure BGP over whatever you got, > including tunnels? Depends on what you're looking for : transit over tunnels is prety rare because it's generally a bad idea (MTU issues, BW cost over transits). If you just want to get a BGP feed for studies and statistics, with no forwarding involved, I guess I'd be willing to participate (AS197422). But an eBGP multihop session is enough, no need for a tunnel there. > And willing to allocate you space for same? Isn't any RIR memeber list sufficient ? -- J?r?me Nicolle 06 19 31 27 14 From mikea at mikea.ath.cx Fri Mar 16 11:03:37 2012 From: mikea at mikea.ath.cx (Mike Andrews) Date: Fri, 16 Mar 2012 11:03:37 -0500 Subject: Iowa outage(s)? Message-ID: <20120316160337.GA14227@mikea.ath.cx> Anyone else seeing outages/partitions in Iowa? I'm seeing stuff back up in my outbound mailqueues for places that get their DNS from at least one provider (rdi1.com) in Iowa, and their phonetwinkie reports that the outage is "statewide". -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From darin.herteen at netins.com Fri Mar 16 11:08:37 2012 From: darin.herteen at netins.com (Darin Herteen) Date: Fri, 16 Mar 2012 16:08:37 +0000 Subject: Iowa outage(s)? In-Reply-To: <20120316160337.GA14227@mikea.ath.cx> References: <20120316160337.GA14227@mikea.ath.cx> Message-ID: <28E008EAA20BAA4BB5221FF29FF3452B311047@dtnmailbox.iowanetworkservices.net> FYI Darin Herteen CCNA Lead Network Technician Packet Networking Group Iowa Network Services Inc http://www.iowanetworkservices.com -----Original Message----- From: Mike Andrews [mailto:mikea at mikea.ath.cx] Sent: Friday, March 16, 2012 11:04 AM To: nanog at nanog.org Subject: Iowa outage(s)? Anyone else seeing outages/partitions in Iowa? I'm seeing stuff back up in my outbound mailqueues for places that get their DNS from at least one provider (rdi1.com) in Iowa, and their phonetwinkie reports that the outage is "statewide". -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From mikea at mikea.ath.cx Fri Mar 16 11:25:56 2012 From: mikea at mikea.ath.cx ('Mike Andrews') Date: Fri, 16 Mar 2012 11:25:56 -0500 Subject: Iowa outage(s)? In-Reply-To: <28E008EAA20BAA4BB5221FF29FF3452B311047@dtnmailbox.iowanetworkservices.net> References: <20120316160337.GA14227@mikea.ath.cx> <28E008EAA20BAA4BB5221FF29FF3452B311047@dtnmailbox.iowanetworkservices.net> Message-ID: <20120316162556.GB14227@mikea.ath.cx> On Fri, Mar 16, 2012 at 04:08:37PM +0000, Darin Herteen wrote: > FYI > > Darin Herteen CCNA > Lead Network Technician > Packet Networking Group > Iowa Network Services Inc > http://www.iowanetworkservices.com > > > -----Original Message----- > From: Mike Andrews [mailto:mikea at mikea.ath.cx] > Sent: Friday, March 16, 2012 11:04 AM > To: nanog at nanog.org > Subject: Iowa outage(s)? > > Anyone else seeing outages/partitions in Iowa? I'm seeing stuff back up in my outbound mailqueues for places that get their DNS from at least one provider (rdi1.com) in Iowa, and their phonetwinkie reports that the outage is "statewide". > > -- > Mike Andrews, W5EGO > mikea at mikea.ath.cx Appears to have been resolved: ;; QUESTION SECTION: ;dns1.rdi1.com. IN A ;; ANSWER SECTION: dns1.rdi1.com. 3600 IN A 67.55.143.251 ;; AUTHORITY SECTION: rdi1.com. 164094 IN NS dns1.rdi1.com. rdi1.com. 164094 IN NS dns2.rdi1.com. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From caldcv at gmail.com Fri Mar 16 12:28:33 2012 From: caldcv at gmail.com (Chris) Date: Fri, 16 Mar 2012 13:28:33 -0400 Subject: [Full-disclosure] is my ISP lying or stupid? In-Reply-To: References: Message-ID: You can name Comcast by name. They are used to being associated with stupidity. On Fri, Mar 16, 2012 at 12:30 PM, Jerry dePriest wrote: > They had a?DoS of mail, www and shell. They state a switch went out. who > runs mail, www and shell on the same switch? > > (This might be a trick question, think it thru...) > > bma > -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From mark at viviotech.net Fri Mar 16 12:44:19 2012 From: mark at viviotech.net (Mark Keymer) Date: Fri, 16 Mar 2012 10:44:19 -0700 Subject: Anyone have experience with Adconion Direct? In-Reply-To: References: <4F6236C6.4020509@viviotech.net> Message-ID: <4F637BF3.1030901@viviotech.net> Hi, I guess I should clarify a bit more on my comments about ROKSO at Spamhaus. Spamhaus says here http://www.spamhaus.org/faq/section/ROKSO%20FAQ#159 that people that have been thrown off 3 ISP due to spamming or providing spam services get on the ROKSO. So I tried to contact them to see what the process was for reporting that. If someone here knows how to do that and would like to share that would be great. I do agree that to get delisted in the RBL etc they are responsive. Also per my main point I wanted to thank those of you that got back with me about Adconion Direct. Sincerely, Mark On 3/16/2012 2:51 AM, Suresh Ramasubramanian wrote: > If a company has a ROKSO record, you don't want to host them. And > spamhaus IS responsive. > > Yes they don't take spam reports from people - they got their own > traps. They ARE responsive to requests for removal where the request > checks out and meets their criteria. > > On Fri, Mar 16, 2012 at 12:06 AM, Mark Keymer > wrote: > > > Also along the lines of spammers and or similar activities is > there a good resource for looking up people/companies that might > be not so legit? I know of the ROKSO that spamhaus has but from > what I have seen it is hard to even report spammer to them and > wasn't sure how active that was getting updated these days. > > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com ) From bkain1 at ford.com Fri Mar 16 12:51:26 2012 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Fri, 16 Mar 2012 17:51:26 +0000 Subject: [Full-disclosure] is my ISP lying or stupid? In-Reply-To: References: Message-ID: <7DB845D64966DC44A1CC592780539B4B07CE5C@naembx40.exchange.ford.com> I would have guess WOW cable. They lost their dns servers so many times, their recording on the help line was "if you know the number address of the site you're going to, you can type that into your web browser" -becki -----Original Message----- From: Chris [mailto:caldcv at gmail.com] Sent: Friday, March 16, 2012 1:29 PM To: NANOG list Subject: Re: [Full-disclosure] is my ISP lying or stupid? You can name Comcast by name. They are used to being associated with stupidity. On Fri, Mar 16, 2012 at 12:30 PM, Jerry dePriest wrote: > They had a?DoS of mail, www and shell. They state a switch went out. who > runs mail, www and shell on the same switch? > > (This might be a trick question, think it thru...) > > bma > -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From alvarezp at alvarezp.ods.org Fri Mar 16 13:01:58 2012 From: alvarezp at alvarezp.ods.org (Octavio Alvarez) Date: Fri, 16 Mar 2012 11:01:58 -0700 Subject: shared address space... a reality! In-Reply-To: References: Message-ID: On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow wrote: > NetRange: 100.64.0.0 - 100.127.255.255 > CIDR: 100.64.0.0/10 > OriginAS: > NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED Weren't we supposed to *solve* the end-to-end connectivity problem, instead of just letting it live? Sure, this lets CGN to be more organized for operators, but those that already have RFC5735 addresses implemented will not switch to 100.64/10 just because there's a new block. Only new players will actually benefit from this. It will only make it easier for new players to play in IPv4 instead of being pushed to IPv6. -- Octavio. From sh.vahabzadeh at gmail.com Fri Mar 16 13:03:02 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Fri, 16 Mar 2012 21:33:02 +0330 Subject: nfsen and protocol analysing plugin Message-ID: Hi everybody, Does any body know any plugin for nfsen which can analyse protocols and give out report for us? ( using netflow ) By default nfsen only shows TCP, UDP and ICMP traffic not detail. For example I want to show me how much "YMessenger" traffic I have, or how much "IMAP" traffic I have. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From streiner at cluebyfour.org Fri Mar 16 13:06:06 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 16 Mar 2012 14:06:06 -0400 (EDT) Subject: nfsen and protocol analysing plugin In-Reply-To: References: Message-ID: On Fri, 16 Mar 2012, Shahab Vahabzadeh wrote: > Hi everybody, > Does any body know any plugin for nfsen which can analyse protocols and > give out report for us? ( using netflow ) > By default nfsen only shows TCP, UDP and ICMP traffic not detail. > For example I want to show me how much "YMessenger" traffic I have, or how > much "IMAP" traffic I have. I think you want the PortTracker plugin. Goog for "nfsen plugins" and you'll find it. jms From sh.vahabzadeh at gmail.com Fri Mar 16 13:14:55 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Fri, 16 Mar 2012 21:44:55 +0330 Subject: nfsen and protocol analysing plugin In-Reply-To: References: Message-ID: Its a port tracker and traffic analyser, the plugin I want can gather valuable data from netflow. For example "GTalk" is on port 80 and this plugin can not detect it ;) Thanks On Fri, Mar 16, 2012 at 9:36 PM, Justin M. Streiner wrote: > On Fri, 16 Mar 2012, Shahab Vahabzadeh wrote: > > Hi everybody, >> Does any body know any plugin for nfsen which can analyse protocols and >> give out report for us? ( using netflow ) >> By default nfsen only shows TCP, UDP and ICMP traffic not detail. >> For example I want to show me how much "YMessenger" traffic I have, or how >> much "IMAP" traffic I have. >> > > I think you want the PortTracker plugin. Goog for "nfsen plugins" and > you'll find it. > > jms > > -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From ops.lists at gmail.com Fri Mar 16 13:25:57 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 16 Mar 2012 23:55:57 +0530 Subject: Spamhaus - Re: Anyone have experience with Adconion Direct? Message-ID: They do read nanog I believe. So just changed the subject to tag it "spamhaus" On Fri, Mar 16, 2012 at 11:14 PM, Mark Keymer wrote: > > Spamhaus says here http://www.spamhaus.org/faq/section/ROKSO%20FAQ#159that people that have been thrown off 3 ISP due to spamming or providing > spam services get on the ROKSO. So I tried to contact them to see what the > process was for reporting that. If someone here knows how to do that and > would like to share that would be great. -- Suresh Ramasubramanian (ops.lists at gmail.com) From streiner at cluebyfour.org Fri Mar 16 13:30:21 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 16 Mar 2012 14:30:21 -0400 (EDT) Subject: nfsen and protocol analysing plugin In-Reply-To: References: Message-ID: On Fri, 16 Mar 2012, Shahab Vahabzadeh wrote: > Its a port tracker and traffic analyser, the plugin I want can gather > valuable data from netflow. > For example "GTalk" is on port 80 and this plugin can not detect it ;) You're not going to get that kind of detail from Netflow. It doesn't have the visibility into application layer to tell you GTalk from straight HTTP, from any other traffic that might be riding on destination socket tcp/80. You need something with visibility and intelligence higher up in the stack (sniffer, packet inspection engine, etc). jms From morrowc.lists at gmail.com Fri Mar 16 13:33:53 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 16 Mar 2012 14:33:53 -0400 Subject: shared address space... a reality! In-Reply-To: References: Message-ID: On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez wrote: > On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow > wrote: > >> NetRange: ? ? ? 100.64.0.0 - 100.127.255.255 >> CIDR: ? ? ? ? ? 100.64.0.0/10 >> OriginAS: >> NetName: ? ? ? ?SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED > > > Weren't we supposed to *solve* the end-to-end connectivity problem, > instead of just letting it live? ha! > Sure, this lets CGN to be more organized for operators, but those that ghuston has a great presentation about CGN deployments, and how they essentially become permanent (or could, according to his chickenbone-readings)... It's an interesting thought experiment/discussion, and one I'm curious to see play out. > already have RFC5735 addresses implemented will not switch to 100.64/10 > just because there's a new block. Only new players will actually benefit > from this. It will only make it easier for new players to play in > IPv4 instead of being pushed to IPv6. are you really asking: "Why on why did we go through all this hard work for something with basically no easy to quantify return?" hell, this may get more use than SCTP does, and sctp took a LOT longer to do... -chris From ml at kenweb.org Fri Mar 16 13:46:29 2012 From: ml at kenweb.org (ML) Date: Fri, 16 Mar 2012 14:46:29 -0400 Subject: Anyone have experience with Adconion Direct? In-Reply-To: References: <4F6236C6.4020509@viviotech.net> Message-ID: <4F638A85.3020106@kenweb.org> On 03/16/2012 05:51 AM, Suresh Ramasubramanian wrote: > If a company has a ROKSO record, you don't want to host them. And spamhaus > IS responsive. > > Yes they don't take spam reports from people - they got their own traps. > They ARE responsive to requests for removal where the request checks out > and meets their criteria. > > On Fri, Mar 16, 2012 at 12:06 AM, Mark Keymer wrote: > >> >> Also along the lines of spammers and or similar activities is there a good >> resource for looking up people/companies that might be not so legit? I know >> of the ROKSO that spamhaus has but from what I have seen it is hard to even >> report spammer to them and wasn't sure how active that was getting updated >> these days. I'll be honest and maybe I'm blowing off some steam but I didn't find them responsive the last few times I tried to contact them. I wasn't even trying to get my IPs off one their lists. While working for a previous employer I found out we had a customer that was just a d/b/a for a known ROKSO offender. I tried to give as much info as I could so Spamhaus could get their name out there and poison their reputation better than we could. All I ever got was maybe a reply once and then nothing. After the second time of no action I figured they didn't care. And the ROKSO info is still out of date. From cscora at apnic.net Fri Mar 16 13:57:39 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Mar 2012 04:57:39 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201203161857.q2GIvdfO030134@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 17 Mar, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 401129 Prefixes after maximum aggregation: 170803 Deaggregation factor: 2.35 Unique aggregates announced to Internet: 194695 Total ASes present in the Internet Routing Table: 40373 Prefixes per ASN: 9.94 Origin-only ASes present in the Internet Routing Table: 32891 Origin ASes announcing only one prefix: 15486 Transit ASes present in the Internet Routing Table: 5406 Transit-only ASes present in the Internet Routing Table: 141 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 407 Unregistered ASNs in the Routing Table: 187 Number of 32-bit ASNs allocated by the RIRs: 2322 Number of 32-bit ASNs visible in the Routing Table: 2076 Prefixes from 32-bit ASNs in the Routing Table: 5015 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 687 Number of addresses announced to Internet: 2526912912 Equivalent to 150 /8s, 157 /16s and 161 /24s Percentage of available address space announced: 68.2 Percentage of allocated address space announced: 68.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 92.1 Total number of prefixes smaller than registry allocations: 170384 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 98366 Total APNIC prefixes after maximum aggregation: 31927 APNIC Deaggregation factor: 3.08 Prefixes being announced from the APNIC address blocks: 94757 Unique aggregates announced from the APNIC address blocks: 39280 APNIC Region origin ASes present in the Internet Routing Table: 4667 APNIC Prefixes per ASN: 20.30 APNIC Region origin ASes announcing only one prefix: 1233 APNIC Region transit ASes present in the Internet Routing Table: 728 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 165 Number of APNIC addresses announced to Internet: 640873312 Equivalent to 38 /8s, 50 /16s and 243 /24s Percentage of available APNIC address space announced: 81.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 148801 Total ARIN prefixes after maximum aggregation: 75607 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 120341 Unique aggregates announced from the ARIN address blocks: 49824 ARIN Region origin ASes present in the Internet Routing Table: 14938 ARIN Prefixes per ASN: 8.06 ARIN Region origin ASes announcing only one prefix: 5674 ARIN Region transit ASes present in the Internet Routing Table: 1573 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 15 Number of ARIN addresses announced to Internet: 806524160 Equivalent to 48 /8s, 18 /16s and 149 /24s Percentage of available ARIN address space announced: 64.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 100879 Total RIPE prefixes after maximum aggregation: 52925 RIPE Deaggregation factor: 1.91 Prefixes being announced from the RIPE address blocks: 92343 Unique aggregates announced from the RIPE address blocks: 57046 RIPE Region origin ASes present in the Internet Routing Table: 16347 RIPE Prefixes per ASN: 5.65 RIPE Region origin ASes announcing only one prefix: 7976 RIPE Region transit ASes present in the Internet Routing Table: 2618 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1415 Number of RIPE addresses announced to Internet: 502120968 Equivalent to 29 /8s, 237 /16s and 194 /24s Percentage of available RIPE address space announced: 80.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 39029 Total LACNIC prefixes after maximum aggregation: 8078 LACNIC Deaggregation factor: 4.83 Prefixes being announced from the LACNIC address blocks: 38752 Unique aggregates announced from the LACNIC address blocks: 19591 LACNIC Region origin ASes present in the Internet Routing Table: 1572 LACNIC Prefixes per ASN: 24.65 LACNIC Region origin ASes announcing only one prefix: 438 LACNIC Region transit ASes present in the Internet Routing Table: 289 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 18 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 476 Number of LACNIC addresses announced to Internet: 98357384 Equivalent to 5 /8s, 220 /16s and 208 /24s Percentage of available LACNIC address space announced: 65.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8782 Total AfriNIC prefixes after maximum aggregation: 2113 AfriNIC Deaggregation factor: 4.16 Prefixes being announced from the AfriNIC address blocks: 6876 Unique aggregates announced from the AfriNIC address blocks: 2175 AfriNIC Region origin ASes present in the Internet Routing Table: 522 AfriNIC Prefixes per ASN: 13.17 AfriNIC Region origin ASes announcing only one prefix: 165 AfriNIC Region transit ASes present in the Internet Routing Table: 116 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 31557120 Equivalent to 1 /8s, 225 /16s and 134 /24s Percentage of available AfriNIC address space announced: 47.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2492 11110 994 Korea Telecom (KIX) 17974 1744 503 36 PT TELEKOMUNIKASI INDONESIA 7545 1652 303 87 TPG Internet Pty Ltd 4755 1569 386 160 TATA Communications formerly 9583 1202 91 509 Sify Limited 9829 1189 1001 30 BSNL National Internet Backbo 7552 1162 1062 11 Vietel Corporation 4808 1095 2048 312 CNCGROUP IP network: China169 24560 1012 384 166 Bharti Airtel Ltd., Telemedia 18101 948 130 160 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3395 1006 158 Windstream Communications Inc 6389 3384 3807 198 bellsouth.net, inc. 18566 2091 382 177 Covad Communications 1785 1882 680 127 PaeTec Communications, Inc. 20115 1631 1558 628 Charter Communications 4323 1603 1060 382 Time Warner Telecom 22773 1547 2910 111 Cox Communications, Inc. 30036 1396 252 747 Mediacom Communications Corp 7018 1275 9776 835 AT&T WorldNet Services 11492 1164 212 415 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1779 544 16 Corbina telecom 2118 1427 97 13 EUnet/RELCOM Autonomous Syste 15557 1089 2247 55 LDCOM NETWORKS 34984 664 188 172 BILISIM TELEKOM 6830 641 1943 412 UPC Distribution Services 12479 638 653 67 Uni2 Autonomous System 20940 628 201 487 Akamai Technologies European 8551 575 360 81 Bezeq International 31148 539 37 9 FreeNet ISP 3320 533 8442 399 Deutsche Telekom AG Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1789 328 143 TVCABLE BOGOTA 28573 1721 1094 58 NET Servicos de Comunicao S.A 8151 1484 3015 348 UniNet S.A. de C.V. 7303 1330 823 185 Telecom Argentina Stet-France 26615 900 676 30 Tim Brasil S.A. 27947 680 68 108 Telconet S.A 11172 635 91 73 Servicios Alestra S.A de C.V 22047 584 326 15 VTR PUNTO NET S.A. 3816 559 240 89 Empresa Nacional de Telecomun 6503 559 418 65 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1258 958 13 TEDATA 24863 842 274 37 LINKdotNET AS number 6713 489 649 18 Itissalat Al-MAGHRIB 3741 271 923 228 The Internet Solution 15706 227 32 6 Sudatel Internet Exchange Aut 12258 197 28 62 Vodacom Internet Company 24835 182 80 8 RAYA Telecom - Egypt 33776 158 12 25 Starcomms Nigeria Limited 36923 157 20 4 Swift Networks Limited 29571 153 15 16 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3395 1006 158 Windstream Communications Inc 6389 3384 3807 198 bellsouth.net, inc. 4766 2492 11110 994 Korea Telecom (KIX) 18566 2091 382 177 Covad Communications 1785 1882 680 127 PaeTec Communications, Inc. 10620 1789 328 143 TVCABLE BOGOTA 8402 1779 544 16 Corbina telecom 17974 1744 503 36 PT TELEKOMUNIKASI INDONESIA 28573 1721 1094 58 NET Servicos de Comunicao S.A 7545 1652 303 87 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3384 3186 bellsouth.net, inc. 18566 2091 1914 Covad Communications 8402 1779 1763 Corbina telecom 1785 1882 1755 PaeTec Communications, Inc. 17974 1744 1708 PT TELEKOMUNIKASI INDONESIA 28573 1721 1663 NET Servicos de Comunicao S.A 10620 1789 1646 TVCABLE BOGOTA 7545 1652 1565 TPG Internet Pty Ltd 4766 2492 1498 Korea Telecom (KIX) 22773 1547 1436 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 23.27.0.0/20 54500 EGIHosting 23.27.16.0/20 54500 EGIHosting 23.27.32.0/20 54500 EGIHosting Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:28 /11:81 /12:235 /13:458 /14:821 /15:1475 /16:12185 /17:6236 /18:10418 /19:20518 /20:28618 /21:29535 /22:40003 /23:37293 /24:209464 /25:1218 /26:1453 /27:794 /28:169 /29:60 /30:17 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 3051 3395 Windstream Communications Inc 6389 2092 3384 bellsouth.net, inc. 18566 2040 2091 Covad Communications 8402 1756 1779 Corbina telecom 10620 1686 1789 TVCABLE BOGOTA 30036 1345 1396 Mediacom Communications Corp 11492 1127 1164 Cable One 8452 1068 1258 TEDATA 1785 1065 1882 PaeTec Communications, Inc. 7011 1038 1152 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:531 2:798 4:14 6:3 8:394 12:1972 13:1 14:599 15:11 16:3 17:7 20:8 23:144 24:1753 27:1239 31:956 32:62 33:2 34:2 36:8 37:259 38:777 40:122 41:3013 42:128 44:3 46:1421 47:3 49:342 50:515 52:13 54:5 55:10 56:3 57:38 58:953 59:495 60:278 61:1191 62:978 63:2014 64:4163 65:2285 66:4487 67:2000 68:1159 69:3170 70:900 71:389 72:1779 74:2583 75:490 76:319 77:968 78:979 79:497 80:1218 81:891 82:633 83:547 84:596 85:1186 86:726 87:910 88:335 89:1565 90:288 91:4598 92:517 93:1454 94:1393 95:1125 96:375 97:316 98:818 99:38 100:6 101:203 103:901 106:64 107:173 108:204 109:1531 110:746 111:881 112:441 113:562 114:617 115:776 116:868 117:723 118:906 119:1203 120:336 121:690 122:1626 123:1088 124:1364 125:1274 128:547 129:190 130:263 131:595 132:170 133:21 134:239 135:63 136:212 137:185 138:275 139:145 140:493 141:241 142:389 143:418 144:500 145:69 146:490 147:240 148:724 149:300 150:158 151:176 152:455 153:171 154:7 155:430 156:213 157:379 158:163 159:521 160:327 161:246 162:341 163:185 164:533 165:393 166:563 167:462 168:803 169:148 170:842 171:121 172:4 173:1715 174:596 175:434 176:416 177:553 178:1286 180:1132 181:73 182:793 183:284 184:445 185:1 186:2114 187:843 188:1060 189:1208 190:5534 192:5989 193:5588 194:4562 195:3639 196:1280 197:170 198:3616 199:4453 200:5750 201:1646 202:8431 203:8592 204:4347 205:2458 206:2720 207:2797 208:4073 209:3586 210:2764 211:1463 212:1966 213:1877 214:861 215:105 216:5053 217:1522 218:540 219:339 220:1231 221:552 222:324 223:325 End of report From jeroen at mompl.net Fri Mar 16 14:04:04 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 16 Mar 2012 12:04:04 -0700 Subject: dell switch config export Message-ID: <4F638EA4.8060204@mompl.net> Does anyone know if these crappy dell powerconnect switches (in my case a 3448p) have a convenient or at least working way of exporting/backing up the configuration to a different place? The only thing I can find is using a tftp server but it's not working... Thanks, Jeroen -- Earthquake Magnitude: 4.9 Date: Friday, March 16, 2012 11:36:40 UTC Location: Pacific-Antarctic Ridge Latitude: -55.2298; Longitude: -128.8988 Depth: 10.20 km From houdini+nanog at clanspum.net Fri Mar 16 14:34:26 2012 From: houdini+nanog at clanspum.net (Bill Weiss) Date: Fri, 16 Mar 2012 14:34:26 -0500 Subject: dell switch config export In-Reply-To: <4F638EA4.8060204@mompl.net> References: <4F638EA4.8060204@mompl.net> Message-ID: <20120316193426.GK17809@clanspum.net> Jeroen van Aart(jeroen at mompl.net)@Fri, Mar 16, 2012 at 12:04:04PM -0700: > Does anyone know if these crappy dell powerconnect switches (in my > case a 3448p) have a convenient or at least working way of > exporting/backing up the configuration to a different place? The > only thing I can find is using a tftp server but it's not working... I'm using RANCID against a few 54xx PowerConnect switches, and it's working well enough. I'm pretty sure my dlogin and drancid came from http://web.rickyninja.net:81/rancid/drancid and http://web.rickyninja.net:81/rancid/dlogin . -- Bill Weiss From gbonser at seven.com Fri Mar 16 14:35:28 2012 From: gbonser at seven.com (George Bonser) Date: Fri, 16 Mar 2012 19:35:28 +0000 Subject: shared address space... a reality! In-Reply-To: References: Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D2E63A@RWC-MBX1.corp.seven.com> > From: Octavio Alvarez > Sure, this lets CGN to be more organized for operators, but those that > already have RFC5735 addresses implemented will not switch to 100.64/10 > just because there's a new block. Only new players will actually > benefit from this. It will only make it easier for new players to play > in > IPv4 instead of being pushed to IPv6. > > > -- > Octavio. This is yet one more moving parts in the growing assemblage of moving parts that is required to make v4 work going forward. At some point (soon) we will reach a point of diminishing return and people are simply going to realize that it is easier to deploy v6 native than it is to attempt to keep v4 limping along. A new player is probably going to buy new gear. New gear isn't going to have the problems with v6 that older networks might have who could still be using ancient gear and can't afford to "forklift" their stuff out. A new player entering the market these days looking to use this for a native v4 deployment going forward any significant period of time ... is probably not making the wisest choice. And with every additional moving part there is something else that impacts performance, something else to break, something else to become CPU or memory bound ... performance over v4 will become increasingly poor, increasingly unreliable, and people are just going to realize that any pain of v6 migration is a lot less than keeping the bailing wire, super glue, and rubber bands around v4. This will be true of their own networks and the networks they are communicating with. V4 performance in general from here on out is simply going to go south. Umpteen NATs, routing table bloat as the nets shatter into smaller and smaller blocks, at some point v4 isn't worth it. Maybe we should just propose more and more and more Band-Aids. Many choose not to migrate to v6 out of simple laziness (if it ain't broken, don't fix it). At some point it will take so much more work to keep v4 going that the path of least phone calls in the middle of the night will be IPv6. From bill at herrin.us Fri Mar 16 14:35:42 2012 From: bill at herrin.us (William Herrin) Date: Fri, 16 Mar 2012 15:35:42 -0400 Subject: shared address space... a reality! In-Reply-To: References: Message-ID: On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez wrote: > On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow > wrote: >> NetRange: ? ? ? 100.64.0.0 - 100.127.255.255 >> CIDR: ? ? ? ? ? 100.64.0.0/10 >> OriginAS: >> NetName: ? ? ? ?SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED > > Weren't we supposed to *solve* the end-to-end connectivity problem, > instead of just letting it live? "We" forgot to ask if all the stakeholders wanted it solved. Most self-styled "enterprise" operators don't: they want a major control point at the network border. Deliberately breaking end to end makes that control more certain. Which is why they deployed IPv4 NAT boxen long before address scarcity became an impactful issue. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeroen at mompl.net Fri Mar 16 14:37:04 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 16 Mar 2012 12:37:04 -0700 Subject: Programmers with network engineering skills In-Reply-To: <4F5FC81F.4080009@gmail.com> References: <201203132033.q2DKXbj5003105@aurora.sol.net> <4F5FC81F.4080009@gmail.com> Message-ID: <4F639660.8040203@mompl.net> Steve Bertrand wrote: > imo, this discussion of outbound SMTP has been sounding akin to me > saying I should let my upstream ensure that all of my BGP announcements > are good, instead of filtering my own outbound. > know whether the address is to RFC or not. Less bugs and changes, I feel > it is better to give the remote host known-good data then have to have > them tell me it is bad. I don't think it's comparable. Because you would not use a remote MTA to validate your email address. You would use the MTA that listens on localhost on the server your code is running. It's really trivial to install an MTA that only listens on localhost and submits email to a smarthost. I mean, if you have code on a webserver that gets form data and sends out emails you best run an MTA locally to which you submit the email and be done with it. The local MTA will take care of queuing and all that for you and submits your email to a smarthost, und so weiter. > In Perl for example, there is Email::Valid. One line of code and you Of course use something like that if it's available to you. Regards, Jeroen -- Earthquake Magnitude: 4.9 Date: Friday, March 16, 2012 11:36:40 UTC Location: Pacific-Antarctic Ridge Latitude: -55.2298; Longitude: -128.8988 Depth: 10.20 km From owen at delong.com Fri Mar 16 14:47:45 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 16 Mar 2012 12:47:45 -0700 Subject: shared address space... a reality! In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D2E63A@RWC-MBX1.corp.seven.com> References: <596B74B410EE6B4CA8A30C3AF1A155EA09D2E63A@RWC-MBX1.corp.seven.com> Message-ID: In my perception, this is primarily a moving part that will be used by providers deploying IPv6 as a mechanism to compensate for things on the internet their customers want to reach that have not yet deployed IPv6. If deploying IPv6 on your own network qualified as a complete solution to the problem, I suspect we'd actually be much further along in the process. Unfortunately, deploying IPv6 locally does not change the fact that you use the internet to talk to things not under your control and until they deploy IPv6, you cannot depend entirely on IPv6 to do that. I don't think any sane provider will use this as yet another way to avoid deploying IPv4. OTOH, the number of not sane providers is somewhat scary, but, hopefully not of sufficient critical mass as to be meaningful in the long term. Owen From jeroen at mompl.net Fri Mar 16 15:10:22 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 16 Mar 2012 13:10:22 -0700 Subject: dell switch config export In-Reply-To: <20120316193426.GK17809@clanspum.net> References: <4F638EA4.8060204@mompl.net> <20120316193426.GK17809@clanspum.net> Message-ID: <4F639E2E.9040305@mompl.net> Bill Weiss wrote: > I'm using RANCID against a few 54xx PowerConnect switches, and it's > working well enough. I'm pretty sure my dlogin and drancid came from > http://web.rickyninja.net:81/rancid/drancid and > http://web.rickyninja.net:81/rancid/dlogin . A number of people suggested that, thanks. I will look into that. Thanks, Jeroen -- Earthquake Magnitude: 4.9 Date: Friday, March 16, 2012 11:36:40 UTC Location: Pacific-Antarctic Ridge Latitude: -55.2298; Longitude: -128.8988 Depth: 10.20 km From cdel at firsthand.net Fri Mar 16 15:21:19 2012 From: cdel at firsthand.net (cdel.firsthand.net) Date: Fri, 16 Mar 2012 20:21:19 +0000 Subject: shared address space... a reality! In-Reply-To: References: Message-ID: <0FD4AD4C-88BE-4C7E-BDBC-D177A911A36A@firsthand.net> NAT at the edge is one thing as it gives an easy to sell security proposition for the board. But CGN controlled by whoever sitting between their NATs does the opposite. Christian de Larrinaga On 16 Mar 2012, at 19:35, William Herrin wrote: > On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez > wrote: >> On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow >> wrote: >>> NetRange: 100.64.0.0 - 100.127.255.255 >>> CIDR: 100.64.0.0/10 >>> OriginAS: >>> NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED >> >> Weren't we supposed to *solve* the end-to-end connectivity problem, >> instead of just letting it live? > > "We" forgot to ask if all the stakeholders wanted it solved. Most > self-styled "enterprise" operators don't: they want a major control > point at the network border. Deliberately breaking end to end makes > that control more certain. Which is why they deployed IPv4 NAT boxen > long before address scarcity became an impactful issue. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From Jason_Livingood at cable.comcast.com Fri Mar 16 15:26:10 2012 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Fri, 16 Mar 2012 20:26:10 +0000 Subject: [Full-disclosure] is my ISP lying or stupid? In-Reply-To: Message-ID: My team at Comcast is responsible for our mail platform and I'm not aware that we had an outage, Chris. If you have information to the contrary, please share it and I'll track it down. - Jason On 3/16/12 1:28 PM, "Chris" > wrote: You can name Comcast by name. They are used to being associated with stupidity. On Fri, Mar 16, 2012 at 12:30 PM, Jerry dePriest > wrote: They had a DoS of mail, www and shell. They state a switch went out. who runs mail, www and shell on the same switch? (This might be a trick question, think it thru...) bma -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From owen at delong.com Fri Mar 16 16:17:38 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 16 Mar 2012 14:17:38 -0700 Subject: shared address space... a reality! In-Reply-To: <0FD4AD4C-88BE-4C7E-BDBC-D177A911A36A@firsthand.net> References: <0FD4AD4C-88BE-4C7E-BDBC-D177A911A36A@firsthand.net> Message-ID: <62BECEF4-68A0-4E44-9E5D-87CD42531037@delong.com> It may be easy to sell, but it's also fictitious. NAT is antithetical to security, not beneficial to it. Owen On Mar 16, 2012, at 1:21 PM, cdel.firsthand.net wrote: > NAT at the edge is one thing as it gives an easy to sell security proposition for the board. But CGN controlled by whoever sitting between their NATs does the opposite. > > > > Christian de Larrinaga > > > On 16 Mar 2012, at 19:35, William Herrin wrote: > >> On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez >> wrote: >>> On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow >>> wrote: >>>> NetRange: 100.64.0.0 - 100.127.255.255 >>>> CIDR: 100.64.0.0/10 >>>> OriginAS: >>>> NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED >>> >>> Weren't we supposed to *solve* the end-to-end connectivity problem, >>> instead of just letting it live? >> >> "We" forgot to ask if all the stakeholders wanted it solved. Most >> self-styled "enterprise" operators don't: they want a major control >> point at the network border. Deliberately breaking end to end makes >> that control more certain. Which is why they deployed IPv4 NAT boxen >> long before address scarcity became an impactful issue. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> From Valdis.Kletnieks at vt.edu Fri Mar 16 16:44:46 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 16 Mar 2012 17:44:46 -0400 Subject: shared address space... a reality! In-Reply-To: Your message of "Fri, 16 Mar 2012 14:17:38 PDT." <62BECEF4-68A0-4E44-9E5D-87CD42531037@delong.com> References: <0FD4AD4C-88BE-4C7E-BDBC-D177A911A36A@firsthand.net> <62BECEF4-68A0-4E44-9E5D-87CD42531037@delong.com> Message-ID: <19340.1331934286@turing-police.cc.vt.edu> On Fri, 16 Mar 2012 14:17:38 PDT, Owen DeLong said: > It may be easy to sell, but it's also fictitious. > > NAT is antithetical to security, not beneficial to it. Anybody want to hazard a guess what % of Vint Cerf's famous 140M compromised boxes were behind a NAT and still got pwned by a drive-by fruiting? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From cidr-report at potaroo.net Fri Mar 16 17:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Mar 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201203162200.q2GM01ZP079788@wattle.apnic.net> BGP Update Report Interval: 08-Mar-12 -to- 15-Mar-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS24863 115152 4.6% 101.3 -- LINKdotNET-AS 2 - AS8402 62241 2.5% 29.9 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS7029 35548 1.4% 12.6 -- WINDSTREAM - Windstream Communications Inc 4 - AS5800 31822 1.3% 106.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 5 - AS9829 31131 1.2% 31.3 -- BSNL-NIB National Internet Backbone 6 - AS55515 28472 1.1% 1186.3 -- ONE-NET-HK INTERNET-SOLUTION -HK 7 - AS12479 28087 1.1% 52.4 -- UNI2-AS France Telecom Espana SA 8 - AS28683 27278 1.1% 462.3 -- BENINTELECOM 9 - AS32528 22751 0.9% 2275.1 -- ABBOTT Abbot Labs 10 - AS24560 19840 0.8% 19.6 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 11 - AS8452 16225 0.7% 12.8 -- TE-AS TE-AS 12 - AS2118 15478 0.6% 10.8 -- RELCOM-AS OOO "NPO Relcom" 13 - AS9583 14368 0.6% 11.8 -- SIFY-AS-IN Sify Limited 14 - AS7552 14026 0.6% 12.3 -- VIETEL-AS-AP Vietel Corporation 15 - AS6066 12624 0.5% 6312.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 16 - AS41843 12134 0.5% 153.6 -- ERTH-OMSK-AS CJSC "ER-Telecom Holding" 17 - AS2578 12110 0.5% 25.2 -- DEMOS-AS Demos, Moscow, Russia 18 - AS6849 11858 0.5% 179.7 -- UKRTELNET JSC UKRTELECOM, 19 - AS13277 11262 0.5% 5631.0 -- HP-MS HP-MS Autonomous System 20 - AS26615 10977 0.4% 12.2 -- Tim Celular S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6066 12624 0.5% 6312.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 2 - AS13277 11262 0.5% 5631.0 -- HP-MS HP-MS Autonomous System 3 - AS8657 2514 0.1% 2514.0 -- CPRM CPRM Autonomous System 4 - AS32528 22751 0.9% 2275.1 -- ABBOTT Abbot Labs 5 - AS4 3643 0.1% 60.0 -- Maria Irma Salazar 6 - AS55515 28472 1.1% 1186.3 -- ONE-NET-HK INTERNET-SOLUTION -HK 7 - AS29933 3326 0.1% 1108.7 -- OFF-CAMPUS-TELECOMMUNICATIONS - Off Campus Telecommunications 8 - AS13314 1023 0.0% 1023.0 -- TEMA-AS - Toyota Motor Engineering and Manufacturing North America, Inc. 9 - AS55665 1016 0.0% 1016.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 10 - AS26779 2911 0.1% 970.3 -- PANDO-NETWORKS - Pando Networks 11 - AS32438 883 0.0% 883.0 -- GRO-UCFUSM-1N - Michigan State University Federal Credit Union 12 - AS53362 869 0.0% 869.0 -- MIXIT-AS - Mixit, Inc. 13 - AS49072 860 0.0% 860.0 -- APSUARA-AS TCA Apsuara Ltd. 14 - AS22386 1535 0.1% 767.5 -- SARB 15 - AS57858 729 0.0% 729.0 -- FIBERGRID Fiber Grid OU 16 - AS26646 2678 0.1% 669.5 -- TRAVELCLICKCORP1 - TravelCLICK Inc. 17 - AS3 510 0.0% 1756.0 -- DONAIR-AS Municipal Enterprise "International Airport Donetsk" 18 - AS37396 465 0.0% 465.0 -- ocean-five 19 - AS28683 27278 1.1% 462.3 -- BENINTELECOM 20 - AS13224 2736 0.1% 456.0 -- NAIROBINET TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/24 11356 0.4% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/24 11354 0.4% AS32528 -- ABBOTT Abbot Labs 3 - 122.161.0.0/16 10732 0.4% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 4 - 62.36.252.0/22 8498 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 5 - 62.36.249.0/24 6410 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 6 - 204.29.239.0/24 6315 0.2% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 7 - 150.225.0.0/16 6309 0.2% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 8 - 204.234.0.0/17 6178 0.2% AS7029 -- WINDSTREAM - Windstream Communications Inc 9 - 62.36.241.0/24 5908 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 194.209.13.0/24 5631 0.2% AS13277 -- HP-MS HP-MS Autonomous System 11 - 194.209.211.0/24 5631 0.2% AS13277 -- HP-MS HP-MS Autonomous System 12 - 62.36.210.0/24 5625 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 13 - 194.63.9.0/24 4800 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 14 - 217.15.120.0/22 4354 0.2% AS56696 -- ASLIQUID-MPLS Liquid Telecommunications Ltd 15 - 202.153.174.0/24 3493 0.1% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 16 - 67.214.235.0/24 3322 0.1% AS29933 -- OFF-CAMPUS-TELECOMMUNICATIONS - Off Campus Telecommunications 17 - 109.124.113.0/24 3031 0.1% AS20632 -- PETERSTAR-AS OJSC MegaFon 18 - 182.64.0.0/16 2974 0.1% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 19 - 70.42.86.0/24 2672 0.1% AS26646 -- TRAVELCLICKCORP1 - TravelCLICK Inc. 20 - 197.159.80.0/20 2514 0.1% AS8657 -- CPRM CPRM Autonomous System Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 16 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Mar 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201203162200.q2GM00kP079783@wattle.apnic.net> This report has been generated at Fri Mar 16 21:13:00 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 09-03-12 402647 233826 10-03-12 403162 233741 11-03-12 402883 233818 12-03-12 402926 233844 13-03-12 403415 233943 14-03-12 403852 234198 15-03-12 403734 234609 16-03-12 403663 234447 AS Summary 40494 Number of ASes in routing system 16931 Number of ASes announcing only one prefix 3402 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 111321632 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'). --- 16Mar12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 404191 234511 169680 42.0% All ASes AS6389 3375 201 3174 94.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3402 1864 1538 45.2% WINDSTREAM - Windstream Communications Inc AS4766 2498 1017 1481 59.3% KIXS-AS-KR Korea Telecom AS22773 1547 120 1427 92.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS2118 1427 14 1413 99.0% RELCOM-AS OOO "NPO Relcom" AS18566 2091 703 1388 66.4% COVAD - Covad Communications Co. AS28573 1721 477 1244 72.3% NET Servicos de Comunicao S.A. AS4323 1604 384 1220 76.1% TWTC - tw telecom holdings, inc. AS4755 1568 416 1152 73.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1885 800 1085 57.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 1792 787 1005 56.1% Telmex Colombia S.A. AS8402 1718 739 979 57.0% CORBINA-AS OJSC "Vimpelcom" AS7552 1162 195 967 83.2% VIETEL-AS-AP Vietel Corporation AS7303 1331 440 891 66.9% Telecom Argentina S.A. AS26615 900 30 870 96.7% Tim Celular S.A. AS8151 1484 687 797 53.7% Uninet S.A. de C.V. AS18101 949 164 785 82.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1095 343 752 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9498 917 230 687 74.9% BBIL-AP BHARTI Airtel Ltd. AS9394 885 208 677 76.5% CRNET CHINA RAILWAY Internet(CRNET) AS7545 1652 993 659 39.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS24560 1012 363 649 64.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17974 1744 1100 644 36.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS3356 1092 452 640 58.6% LEVEL3 Level 3 Communications AS30036 1396 776 620 44.4% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS17676 685 75 610 89.1% GIGAINFRA Softbank BB Corp. AS19262 996 401 595 59.7% VZGNI-TRANSIT - Verizon Online LLC AS15557 1089 501 588 54.0% LDCOMNET Societe Francaise du Radiotelephone S.A AS3549 998 432 566 56.7% GBLX Global Crossing Ltd. AS22561 966 401 565 58.5% DIGITAL-TELEPORT - Digital Teleport Inc. Total 44981 15313 29668 66.0% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 37.157.240.0/21 AS35662 REDSTATION Redstation Limited 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 66.129.0.0/19 AS3901 ARRAKIS - Higher Technology Services 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS14208 74.91.49.0/24 AS14208 74.91.50.0/24 AS14208 74.91.51.0/24 AS14208 74.91.52.0/24 AS14208 74.91.53.0/24 AS14208 74.91.54.0/24 AS14208 74.91.55.0/24 AS14208 74.91.56.0/24 AS14208 74.91.57.0/24 AS14208 74.91.58.0/24 AS14208 74.91.59.0/24 AS14208 74.91.60.0/24 AS14208 74.91.61.0/24 AS14208 74.91.62.0/24 AS14208 74.91.63.0/24 AS14208 98.159.96.0/20 AS46975 109.233.240.0/21 AS50400 EST-ASN Elite System Technics LTD. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 131.117.216.0/21 AS19667 HOSTEROV-AS OOO "Hosterov" 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 195.93.199.0/24 AS8708 RDSNET RCS & RDS S.A. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.86.32.0/20 AS18255 BRISBANE-AP Brisbane City Council 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.122.134.0/24 AS38615 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.133.224.0/19 AS4323 TWTC - tw telecom holdings, inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From malayter at gmail.com Fri Mar 16 17:02:55 2012 From: malayter at gmail.com (Ryan Malayter) Date: Fri, 16 Mar 2012 15:02:55 -0700 (PDT) Subject: dell switch config export In-Reply-To: <4F638EA4.8060204@mompl.net> References: <4F638EA4.8060204@mompl.net> Message-ID: <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> On Friday, March 16, 2012 2:04:04 PM UTC-5, Jeroen van Aart wrote: > > Does anyone know if these crappy dell powerconnect switches (in my case > a 3448p) have a convenient or at least working way of exporting/backing > up the configuration to a different place? The only thing I can find is > using a tftp server but it's not working... > > Thanks, > Jeroen > We have a few 6248s, and as I recall the web UI is confusing and clearly not designed or coded by a native English speaker. You have to use the "upload" link to export config, and put in the address of your TFTP server, since you are "uploading" from the switch to the tftp server. It's a bit more sane from the cli (which is actually decent in the recent firmware for the 6248s at least). It is of course possible the software is entirely different on the 3400-series though. Despite the terrible GUI and passable CLI, we're found the our 6248s to be remarkable stable and bug free. Some have been up for more than 3 years, and all the things you expect to be problematic on cheap switches (cross-stack LACP, multicast, MSTP, QoS) work perfectly. From iain.t.morris at gmail.com Fri Mar 16 17:55:58 2012 From: iain.t.morris at gmail.com (Iain Morris) Date: Fri, 16 Mar 2012 15:55:58 -0700 Subject: dell switch config export In-Reply-To: <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> References: <4F638EA4.8060204@mompl.net> <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> Message-ID: On Fri, Mar 16, 2012 at 3:02 PM, Ryan Malayter wrote: > > as I recall the web UI is confusing and clearly not designed or coded by a > native English speaker. It's as if the web ui was coded up to just _barely_ work, and shipped out the door. It felt like I was using someone's high school project. I agree though, if you can survive the initial config nightmare, they (54xx 62xx series here) keep on trucking. -Iain From gbonser at seven.com Fri Mar 16 17:59:12 2012 From: gbonser at seven.com (George Bonser) Date: Fri, 16 Mar 2012 22:59:12 +0000 Subject: shared address space... a reality! In-Reply-To: References: <596B74B410EE6B4CA8A30C3AF1A155EA09D2E63A@RWC-MBX1.corp.seven.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D2E8F8@RWC-MBX1.corp.seven.com> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > > In my perception, this is primarily a moving part that will be used by > providers deploying IPv6 as a mechanism to compensate for things on the > internet their customers want to reach that have not yet deployed IPv6. I think it will be used mostly as the middle 4 in NAT444 and in links between networks where there are RFC1918 network assignment collisions. My gut tells me we will see that net block being used for NAT on a lot of VPNs between RFC1918 networks. > I don't think any sane provider will use this as yet another way to > avoid deploying IPv4. I hope you're right. > OTOH, the number of not sane providers is > somewhat scary, but, hopefully not of sufficient critical mass as to be > meaningful in the long term. From tom at ninjabadger.net Fri Mar 16 18:08:04 2012 From: tom at ninjabadger.net (Tom Hill) Date: Fri, 16 Mar 2012 23:08:04 +0000 Subject: dell switch config export In-Reply-To: <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> References: <4F638EA4.8060204@mompl.net> <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> Message-ID: <4F63C7D4.1000401@ninjabadger.net> On 16/03/12 22:02, Ryan Malayter wrote: > Despite the terrible GUI and passable CLI, we're found the our 6248s to be > remarkable stable and bug free. Some have been up for more than 3 years, > and all the things you expect to be problematic on cheap switches > (cross-stack LACP, multicast, MSTP, QoS) work perfectly. +1, MSTP/VRRP inter-op with both Cisco 3650-X & Brocade CER worked without fault (well, at a previous position). tl;dr dlogin worked a goddamn treat for me. Props to the guy that wrote it and also Brightbox for helping him out with their 6200's. As I recall it also worked for our 5400's :) never, EVER, let your 62xx's do any routing. Even a little bit. Push 500Mbit of traffic through it for a few days (or 30Mbit for a few months) and watch it forget how to re-learn ARP entries. ARP timers default to 1200s, so it would learn all address for 20 minutes, refuse for the next 20, then learn again for 20 minutes... Had to pull it down to 60s to make it slightly more obvious. The work-around was to configure "arp dynamicrenew", which fixed it totally. Is it on by default? Is it obvious that you should ask it to do this? Hell no. Dell cared; one guy (Piotr Majunka) from the UK/IE PowerConnect team spent ages helping me diagnose the fault after I'd pulled it out of service. Broadcom on the other hand, couldn't give a shit and to my knowledge it was never fixed (I'm not sure if the 70xx "spiritual successors" still do it) so buyer beware. :) Tom From owen at delong.com Fri Mar 16 18:19:07 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 16 Mar 2012 16:19:07 -0700 Subject: shared address space... a reality! In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D2E8F8@RWC-MBX1.corp.seven.com> References: <596B74B410EE6B4CA8A30C3AF1A155EA09D2E63A@RWC-MBX1.corp.seven.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D2E8F8@RWC-MBX1.corp.seven.com> Message-ID: On Mar 16, 2012, at 3:59 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> >> In my perception, this is primarily a moving part that will be used by >> providers deploying IPv6 as a mechanism to compensate for things on the >> internet their customers want to reach that have not yet deployed IPv6. > > I think it will be used mostly as the middle 4 in NAT444 and in links between networks where there are RFC1918 network assignment collisions. My gut tells me we will see that net block being used for NAT on a lot of VPNs between RFC1918 networks. > I would agree with both of those statements. > >> I don't think any sane provider will use this as yet another way to >> avoid deploying IPv4. > > I hope you're right. > Certainly of the providers I have spoken with about the subject, that seems to be the prevailing attitude. So there is some hope. Owen From bill at herrin.us Fri Mar 16 18:22:04 2012 From: bill at herrin.us (William Herrin) Date: Fri, 16 Mar 2012 19:22:04 -0400 Subject: shared address space... a reality! In-Reply-To: References: <596B74B410EE6B4CA8A30C3AF1A155EA09D2E63A@RWC-MBX1.corp.seven.com> Message-ID: On Fri, Mar 16, 2012 at 3:47 PM, Owen DeLong wrote: > I don't think any sane provider will use this as yet another way to avoid deploying IPv4. I'm sure that's correct, but if you fix the typo it may not be. ;-) Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeroen at mompl.net Fri Mar 16 18:36:09 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 16 Mar 2012 16:36:09 -0700 Subject: dell switch config export In-Reply-To: <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> References: <4F638EA4.8060204@mompl.net> <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> Message-ID: <4F63CE69.3000909@mompl.net> Ryan Malayter wrote: > not designed or coded by a native English speaker. You have to use the > "upload" link to export config, and put in the address of your TFTP server, > since you are "uploading" from the switch to the tftp server. Yes I tried that. However the switch complains with an error about file not found. That's funny because I am uploading a file that's present on the switch to an tftp server. And I supposedly can give it any name for the destination. > Despite the terrible GUI and passable CLI, we're found the our 6248s to be > remarkable stable and bug free. Some have been up for more than 3 years, > and all the things you expect to be problematic on cheap switches > (cross-stack LACP, multicast, MSTP, QoS) work perfectly. Yeah they're stable, but then we barely use it for more then 2 or 3 vlans. Nothing else fancy going on. The cli is weird though and the help texts are useless, you need a manual. Reason I want to backup the config is that some time ago after a power outage the thing reset to its default configuration... Greetings, Jeroen -- Earthquake Magnitude: 4.9 Date: Friday, March 16, 2012 11:36:40 UTC Location: Pacific-Antarctic Ridge Latitude: -55.2298; Longitude: -128.8988 Depth: 10.20 km From jeroen at mompl.net Fri Mar 16 21:05:24 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 16 Mar 2012 19:05:24 -0700 Subject: dell switch config export In-Reply-To: <4F63CE69.3000909@mompl.net> References: <4F638EA4.8060204@mompl.net> <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> <4F63CE69.3000909@mompl.net> Message-ID: <4F63F164.2020207@mompl.net> Jeroen van Aart wrote: > Ryan Malayter wrote: >> not designed or coded by a native English speaker. You have to use the >> "upload" link to export config, and put in the address of your TFTP >> server, since you are "uploading" from the switch to the tftp server. > > Yes I tried that. However the switch complains with an error about file I got that figured out. My experience with tftp is a bit limited. I had to create the file first and then change permissions to 666. Then run this on the switch: copy running-config tftp://x.x.x.x/name I first thought I also had to add a path. Thanks, Jeroen -- Earthquake Magnitude: 4.4 Date: Saturday, March 17, 2012 01:38:06 UTC Location: Banda Sea Latitude: -7.0373; Longitude: 123.4202 Depth: 621.60 km From mysidia at gmail.com Fri Mar 16 22:20:00 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 16 Mar 2012 22:20:00 -0500 Subject: Programmers with network engineering skills In-Reply-To: <201203131341.q2DDfLd1098884@aurora.sol.net> References: <20120313031812.EFD301E6E4AB@drugs.dv.isc.org> <201203131341.q2DDfLd1098884@aurora.sol.net> Message-ID: On Tue, Mar 13, 2012 at 8:41 AM, Joe Greco wrote: >> > box with a semicolon. >> Only if you don't properly quote/escape the arguments you are passing. You're going to run into a big mess when trying to combine the rules for escaping e-mail addresses that contain special characters with the shell-specifc rules for escaping when invoking system. When invoking system() you may need different logic for safe execution when the user's shell is /bin/bash than when it's /bin/zsh. > That's a great theory that's been a disaster in practice, as "properly" > is difficult and mistakes often turn into exploits. The disaster in practice is invoking system() with user provided data into a shell that interprets special characters. The semantics of system() are not your end user's problem. It's a similar disaster to attempting to embed a SQL query into an application, but failing to utilize named parameters for untrusted user inputs -- again, the SQL language is not your end user's problem, Just because ";" "--", "/*" or "DROP" may have special meaning to SQL, does not mean strings that contain these patterns won't be part of a legitimate e-mail address. If you must execute a program to validate an e-mail address from its parameters, make sure to range check the length, fork, and exec(), preferably after chroot()'ing to an unwritable path and setuid'ing to an unprivileged GID, UID, and EUID, after fwapping yourself for not passing a file descriptor to the child process in order to exchange the e-mail address data, and as a result of this -- you made potentially private data available to anyone who happens to enter the right 'ps' command and see command line arguments at the moment an address is being validated. -- -JH From jay at miscreant.org Fri Mar 16 22:52:45 2012 From: jay at miscreant.org (Jay Mitchell) Date: Sat, 17 Mar 2012 14:52:45 +1100 Subject: dell switch config export In-Reply-To: <4F63F164.2020207@mompl.net> References: <4F638EA4.8060204@mompl.net> <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> <4F63CE69.3000909@mompl.net> <4F63F164.2020207@mompl.net> Message-ID: If it's tftp on Linux there's a flag you can pass tftpd at startup to allow creation of files, can't remember off the top of my head what it is, it may be -s. --jm Sent from my iPhone On 17/03/2012, at 1:05 PM, Jeroen van Aart wrote: > Jeroen van Aart wrote: >> Ryan Malayter wrote: >>> not designed or coded by a native English speaker. You have to use the "upload" link to export config, and put in the address of your TFTP server, since you are "uploading" from the switch to the tftp server. >> Yes I tried that. However the switch complains with an error about file > > I got that figured out. My experience with tftp is a bit limited. I had to create the file first and then change permissions to 666. Then run this on the switch: > > copy running-config tftp://x.x.x.x/name > > I first thought I also had to add a path. > > Thanks, > Jeroen > > -- > Earthquake Magnitude: 4.4 > Date: Saturday, March 17, 2012 01:38:06 UTC > Location: Banda Sea > Latitude: -7.0373; Longitude: 123.4202 > Depth: 621.60 km > From jay at miscreant.org Fri Mar 16 23:10:48 2012 From: jay at miscreant.org (Jay Mitchell) Date: Sat, 17 Mar 2012 15:10:48 +1100 Subject: dell switch config export In-Reply-To: References: <4F638EA4.8060204@mompl.net> <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> <4F63CE69.3000909@mompl.net> <4F63F164.2020207@mompl.net> Message-ID: <72B36FB5-9DF0-4F6C-A7D9-BF6F6184E9E7@miscreant.org> -c for create :) On 17/03/2012, at 2:52 PM, Jay Mitchell wrote: > If it's tftp on Linux there's a flag you can pass tftpd at startup to allow creation of files, can't remember off the top of my head what it is, it may be -s. > > --jm > > Sent from my iPhone > > On 17/03/2012, at 1:05 PM, Jeroen van Aart wrote: > >> Jeroen van Aart wrote: >>> Ryan Malayter wrote: >>>> not designed or coded by a native English speaker. You have to use the "upload" link to export config, and put in the address of your TFTP server, since you are "uploading" from the switch to the tftp server. >>> Yes I tried that. However the switch complains with an error about file >> >> I got that figured out. My experience with tftp is a bit limited. I had to create the file first and then change permissions to 666. Then run this on the switch: >> >> copy running-config tftp://x.x.x.x/name >> >> I first thought I also had to add a path. >> >> Thanks, >> Jeroen >> >> -- >> Earthquake Magnitude: 4.4 >> Date: Saturday, March 17, 2012 01:38:06 UTC >> Location: Banda Sea >> Latitude: -7.0373; Longitude: 123.4202 >> Depth: 621.60 km >> > From mohta at necom830.hpcl.titech.ac.jp Sat Mar 17 01:41:01 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 17 Mar 2012 15:41:01 +0900 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> <20120312153155.GA85481@ussenterprise.ufp.org> <4F5E86D0.3080707@necom830.hpcl.titech.ac.jp> <4F5EF56D.6070609@necom830.hpcl.titech.ac.jp> <4F6174A5.5040307@necom830.hpcl.titech.ac.jp> <4F61E626.80603@necom830.hpcl.titech.ac.jp> <4F627BBB.6020003@necom830.hpcl.titech.ac.jp> <4F62BBB4.8000401@necom830.hpcl.titech.ac.jp> Message-ID: <4F6431FD.5010201@necom830.hpcl.titech.ac.jp> William Herrin wrote: >> DV is a distributed computation by intelligent intermediate >> systems, whereas, with LS, intermediate systems just flood >> and computation is by each end. > > That's basically wrong. Please, don't demonstrate your lack of basic knowledge. > Both systems perform computation on each router. The difference, as you can see in the above sentence of mine, is whether the computation is done as an intermediate system or an end. > Link State performs > much more complex computation to arrive at its export to the > forwarding information base. In fact, Distance Vector's calculation is > downright trivial in comparison. FYI, DV uses Bellman-Ford while LS can use Dijkstra, which is faster than Bellman-Ford. http://en.wikipedia.org/wiki/Routing Distance vector algorithms use the Bellman-Ford algorithm. http://en.wikipedia.org/wiki/Bellman-Ford The Bellman?Ford algorithm computes single-source shortest paths in a weighted digraph. For graphs with only non-negative edge weights, the faster Dijkstra's algorithm also solves the problem. should help you a lot to have basic knowledge. > The difference is that Link State shares the original knowledge, which > it can do before recomputing its own tables. Distance Vector > recomputes its own state first and then shares each router's state > with the neighbors rather than sharing the original knowledge. The > result is that the knowledge propagates faster with Link State and > each router recomputes only once for each change. In some cases, > distance vector will have to recompute several times before the system > settles into a new stable state, delaying the process even further. That is implied in my statements. So, don't repeat it in such verbose way only to reduce clarity. >> You failed to deny MH know layer 3 address of its private HA. > > Here's a tip for effective written communication: the first time in > any document that you use an abbreviation that isn't well known, spell > it out. In this case, the document is the thread. And a tip for you is to remember the past mails in a thread before sending mails to the thread. > Like any other host, including MH in your plan, it > already knows its domain name and the IP addresses of its private DNS > servers. And, to deny HA, your assumption must be that the private DNS servers may be mobile. > In your home agent architecture, it doesn't matter if they can have > multiple addresses. It matters if they can have the same address. That's totally insane operation. There is no reason to have anycast HA only to bloat the global routing table. Masataka Ohta From me at anuragbhatia.com Sat Mar 17 05:12:18 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 17 Mar 2012 15:42:18 +0530 Subject: [apnic-talk] Concern about gTLD servers in India In-Reply-To: <7B0A3622-87CF-4C36-8956-F448DCC9D501@ieee.org> References: <5611D482-8564-4B81-8758-79CB1713037F@isc.org> <72442ECD-AD48-4CD3-8DC6-947C9007EB65@isc.org> <1FEB0783-9C97-4C7E-A3FC-274BDEAEB31B@isc.org> <7B0A3622-87CF-4C36-8956-F448DCC9D501@ieee.org> Message-ID: Thanks everyone for your replies. I found those really insightful (specially the offlist ones) ;) I got fairly decent image on why things are looking so bad here. On Mon, Mar 12, 2012 at 3:15 PM, Che-Hoo CHENG wrote: > J root should be j.root-servers.net (192.58.128.30). > > Che-Hoo > > > On 12 Mar, 2012, at 5:09 PM, Anurag Bhatia wrote: > > Just looked at j root in detail. > > > Unfortunately not much of traffic is going to J root. BSNL along with its > main upstream providers Tata & Airtel - all picking outside routes. Tata > AS4755 is taking directly to AS6453 while AS6453 is passing to NTT in > London which is next taking back to Japan and then going to HK anycasted > node (yeah head shake routing!). > > > Here's a view: > > traceroute to j.gtld-servers.net (192.48.79.30), 30 hops max, 60 byte > packets > 1 router.local (192.168.1.1) [AS8151/AS28513] 1.180 ms 1.621 ms 2.121 > ms > 2 117.207.48.1 (117.207.48.1) [AS9829] 26.935 ms 29.328 ms 31.956 ms > 3 218.248.173.46 (218.248.173.46) [AS9829] 34.393 ms 37.093 ms * > 4 115.114.57.165.static-Mumbai.vsnl.net.in (115.114.57.165) > [AS4755] 74.623 ms 78.281 ms 82.352 ms > 5 if-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) [*] 299.987 ms > 300.397 ms 314.175 ms > 6 if-6-2.tcore1.L78-London.as6453.net (80.231.130.5) [AS6453] 314.573 > ms 264.576 ms 261.030 ms > 7 Vlan704.icore1.LDN-London.as6453.net > (80.231.130.10) [AS6453] 279.896 ms 280.312 ms * > 8 Vlan522.icore1.LDN-London.as6453.net (195.219.83.22) > [AS6453] 333.651 ms 326.233 ms 330.307 ms > 9 ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) [AS2914] 323.084 > ms 324.204 ms 329.300 ms > 10 as-0.r22.osakjp01.jp.bb.gin.ntt.net (129.250.5.35) [AS2914] 457.845 > ms 459.011 ms 456.842 ms > 11 as-0.r20.newthk02.hk.bb.gin.ntt.net (129.250.2.7) [AS2914] 495.869 > ms 495.615 ms 496.840 ms > 12 ae-1.r02.chwahk02.hk.bb.gin.ntt.net (129.250.3.131) [AS2914] 476.471 > ms 478.525 ms 478.104 ms > 13 * * * > 14 * * * > 15 * * * > > > > > *Router:* gin-mlv-core1 > *Site:* IN, Mumbai - MLV, VSNL > *Command:* show ip bgp 192.48.79.30 > > > BGP routing table entry for *192.48.79.0/24* > Bestpath Modifiers: deterministic-med > Paths: (3 available, best #2) > Multipath: eBGP > 2914 36631 36631, (aggregated by 36631 203.131.245.40) > ldn-icore1. (metric 2991) from mlv-tcore1. (66.110.10.202) > Origin IGP, valid, internal > Community: > Originator: ldn-icore1. 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from cxr-tcore1. (66.110.10.113) Origin IGP, valid, internal, best Community: Originator: ldn-icore1. > 2914 36631 36631, (aggregated by 36631 203.131.245.40) > ldn-icore1. (metric 2991) from mlv-tcore2. (66.110.10.215) > Origin IGP, valid, internal > Community: > Originator: ldn-icore1. > > > > Path via NTT in all cases. > > So Mumbai - London - Japan - HongKong. Very likely because of same old > problem I mentioned - Tata peers with NTT in London but not Japan. > > anurag at laptop:~$ dig j.gtld-servers.net a +short > 192.48.79.30 > > > anurag at laptop:~$ awhois 192.48.79.30 > AS | IP | BGP Prefix | CC | AS Name > 36631 | 192.48.79.30 | 192.48.79.0/24 | US | ZGTLD - VeriSign > Global Registry Services > > > http://bgp.he.net/AS36631#_peers > > > > > And situation for Airtel isn't better at all for J root. Instead of > picking NTT, they are using Packnet/AsiaNetcom because Packnet is likely a > client of Hurricane Electric and Airtel peers with HE. > > Mon Mar 12 14:22:49 GMT+05:30 2012 > traceroute 192.48.79.30 > > Type escape sequence to abort. > Tracing the route to j.gtld-servers.net (192.48.79.30) > > 1 59.145.6.149 [MPLS: Label 800 Exp 0] 288 msec > 59.145.6.145 [MPLS: Label 800 Exp 0] 284 msec > 59.145.0.181 [MPLS: Label 1668 Exp 0] 260 msec > 2 202.56.223.50 [MPLS: Label 308480 Exp 0] 256 msec 256 msec > 202.56.223.205 [MPLS: Label 311696 Exp 0] 276 msec > 3 182.79.220.198 [MPLS: Label 1795 Exp 0] 276 msec 276 msec > 182.79.252.161 [MPLS: Label 1795 Exp 0] 272 msec > 4 AES-Static-122.36.144.59.airtel.in (59.144.36.122) > 272 msec 272 msec 288 msec > 5 he.net.coresite.com (206.223.143.122) 288 msec 292 msec 272 msec > 6 10gigabitethernet2-1.core1.lax1.he.net (72.52.92.121) [AS 6939] 272 > msec 276 msec 288 msec > 7 pacnet.10gigabitethernet2-3.core1.lax1.he.net (216.218.223.206) [AS > 6939] 288 msec 288 msec 272 msec > 8 te0-1-0-0.wr1.nrt0.asianetcom.net (61.14.157.89) [AS 10026] 264 msec > 264 msec 284 msec > 9 te0-0-4-0.wr2.nrt0.asianetcom.net (61.14.157.14) [AS 10026] [MPLS: > Label 16191 Exp 0] 288 msec 292 msec 276 msec > 10 te0-0-0-0.wr2.osa0.asianetcom.net (61.14.157.2) [AS 10026] [MPLS: > Label 16002 Exp 0] 276 msec 300 msec 292 msec > 11 te0-0-4-0.wr1.osa0.asianetcom.net (61.14.157.21) [AS 10026] 292 msec > 292 msec 276 msec > 12 te0-1-0-0.wr1.hkg0.asianetcom.net (61.14.157.57) [AS 10026] 272 msec > 268 msec 288 msec > 13 ge-4-1-0-0.cr4.hkg3.asianetcom.net (61.14.157.142) [AS 10026] 284 > msec 288 msec 264 msec > 14 te3-2.gw1.hkg4.asianetcom.net (202.147.16.198) [AS 10026] 336 msec > 264 msec 284 msec > 15 VNB-0025.gw1.hkg4.asianetcom.net (203.192.137.78) > [AS 10026] 284 msec 288 msec 268 msec > 16 * * * > > > > Same problem applies on J gTLD server too. It might be having an instance > in India but since no link to local ISPs or niXi...everyone hears J root in > Hong Kong. > > > > Anyone from Verisign or Indian ISPs here for onlist or offlist comments? > > Again, I apologize for any wrong conclusions. I am still learning all this > stuff. Please excuse my ignorance and correct me if you find something. > > > Thanks > > On Sun, Mar 11, 2012 at 4:57 PM, Peter Losher wrote: > >> On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote: >> >> > Btw coming back to original question - can you put some light on gTLDs >> in India? Are there any instances? Just to clarify - with gTLD I am >> refering to .com/net/org primarily. >> >> You would have to ask Verisign as operators of the com/net gTLD servers >> and Afilias for .org about their DNS deployments. I can only speak for ISC >> as we operate F.ROOT-SERVERS.NET. >> >> Best Wishes - Peter >> -- >> [ plosher at isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] >> >> > > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Twitter: @anurag_bhatia > Linkedin: http://linkedin.anuragbhatia.com > > _______________________________________________ > apnic-talk mailing list > apnic-talk at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-talk > > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From dedelman at iname.com Sat Mar 17 12:33:34 2012 From: dedelman at iname.com (Dave Edelman) Date: Sat, 17 Mar 2012 13:33:34 -0400 Subject: shared address space... a reality! In-Reply-To: <0FD4AD4C-88BE-4C7E-BDBC-D177A911A36A@firsthand.net> References: <0FD4AD4C-88BE-4C7E-BDBC-D177A911A36A@firsthand.net> Message-ID: <84D1C749-F0C0-41FE-9F87-F680D6046F66@iname.com> Some major stakeholders are under legal or regulatory obligation to supervise and control. A small number of control points makes this less awful to effect. Dave Edelman On Mar 16, 2012, at 16:21, "cdel.firsthand.net" wrote: > NAT at the edge is one thing as it gives an easy to sell security proposition for the board. But CGN controlled by whoever sitting between their NATs does the opposite. > > > > Christian de Larrinaga > > > On 16 Mar 2012, at 19:35, William Herrin wrote: > >> On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez >> wrote: >>> On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow >>> wrote: >>>> NetRange: 100.64.0.0 - 100.127.255.255 >>>> CIDR: 100.64.0.0/10 >>>> OriginAS: >>>> NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED >>> >>> Weren't we supposed to *solve* the end-to-end connectivity problem, >>> instead of just letting it live? >> >> "We" forgot to ask if all the stakeholders wanted it solved. Most >> self-styled "enterprise" operators don't: they want a major control >> point at the network border. Deliberately breaking end to end makes >> that control more certain. Which is why they deployed IPv4 NAT boxen >> long before address scarcity became an impactful issue. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> > From cdl at asgaard.org Sat Mar 17 12:42:34 2012 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Sat, 17 Mar 2012 10:42:34 -0700 Subject: shared address space... a reality! In-Reply-To: <84D1C749-F0C0-41FE-9F87-F680D6046F66@iname.com> References: <0FD4AD4C-88BE-4C7E-BDBC-D177A911A36A@firsthand.net> <84D1C749-F0C0-41FE-9F87-F680D6046F66@iname.com> Message-ID: <2558733D-EA6A-4585-B2BC-0C14A6E4354F@asgaard.org> Greetings Dave, Having been one of the authors of this, and, at the time, unfortunately looking down the barrel of a CGN deployment (in AU). I can say, at least in our case, it had nothing to do with monitoring or intercept. In fact, CGN actually made that more difficult in some circumstances. And this was a carrier that definitely had that requirement. Chris On 17Mar2012, at 10.33, Dave Edelman wrote: > Some major stakeholders are under legal or regulatory obligation to supervise and control. A small number of control points makes this less awful to effect. > > Dave Edelman > > > On Mar 16, 2012, at 16:21, "cdel.firsthand.net" wrote: > >> NAT at the edge is one thing as it gives an easy to sell security proposition for the board. But CGN controlled by whoever sitting between their NATs does the opposite. >> >> >> >> Christian de Larrinaga >> >> >> On 16 Mar 2012, at 19:35, William Herrin wrote: >> >>> On Fri, Mar 16, 2012 at 2:01 PM, Octavio Alvarez >>> wrote: >>>> On Tue, 13 Mar 2012 23:22:04 -0700, Christopher Morrow >>>> wrote: >>>>> NetRange: 100.64.0.0 - 100.127.255.255 >>>>> CIDR: 100.64.0.0/10 >>>>> OriginAS: >>>>> NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED >>>> >>>> Weren't we supposed to *solve* the end-to-end connectivity problem, >>>> instead of just letting it live? >>> >>> "We" forgot to ask if all the stakeholders wanted it solved. Most >>> self-styled "enterprise" operators don't: they want a major control >>> point at the network border. Deliberately breaking end to end makes >>> that control more certain. Which is why they deployed IPv4 NAT boxen >>> long before address scarcity became an impactful issue. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> -- >>> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >>> 3005 Crane Dr. ...................... Web: >>> Falls Church, VA 22042-3004 >>> >> > -- ??? Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf Check my calendar availability: https://tungle.me/cdl From jgreco at ns.sol.net Sun Mar 18 09:01:18 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 18 Mar 2012 09:01:18 -0500 (CDT) Subject: dell switch config export In-Reply-To: <4F63F164.2020207@mompl.net> Message-ID: <201203181401.q2IE1ITQ087347@aurora.sol.net> > Jeroen van Aart wrote: > > Ryan Malayter wrote: > >> not designed or coded by a native English speaker. You have to use the > >> "upload" link to export config, and put in the address of your TFTP > >> server, since you are "uploading" from the switch to the tftp server. > > > > Yes I tried that. However the switch complains with an error about file > > I got that figured out. My experience with tftp is a bit limited. I had > to create the file first and then change permissions to 666. Then run > this on the switch: > > copy running-config tftp://x.x.x.x/name > > I first thought I also had to add a path. That, just to be clear, is not the TFTP device's fault, it's the TFTP server's fault. Not even really a fault, exactly, but a bit of security paranoia on the part of the typical tftpd implementation, plus a lack of a robust means of propagating the server administrator's configuration error back to the frustrated user who is just trying to do what ought to be a simple and sensible operation. So it's not really Dell's fault. ... 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 joelja at bogus.com Sun Mar 18 11:28:23 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 18 Mar 2012 09:28:23 -0700 Subject: Shim6, was: Re: filtering /48 is going to be necessary In-Reply-To: References: <8CB8B760-21D4-4E90-9C8B-F8DAD0906083@muada.com> <4F5CF9D5.9050601@bogus.com> <5BEB1E7E-8BF6-4432-9257-9F17B8100E01@muada.com> <4F5D465A.2060301@dougbarton.us> <86k42prh6d.fsf@seastrom.com> Message-ID: <4F660D27.2090003@bogus.com> On 3/12/12 08:56 , Iljitsch van Beijnum wrote: > On 12 Mar 2012, at 16:21 , Leigh Porter wrote: > >>> Grass-roots, bottom-up policy process + Need for multihoming + >>> Got tired of waiting = IPv6 PI > >> A perfect summation. > > Except that it didn't happen in that order. When ARIN approved PI the > shim6 effort was well underway, but it was too early to be able to > know to what degree it would solve the multihoming problem. Earlier, > when multi6 was stuck or later, when shim6, at least as a > specification, but preferably as multiple implementations, could have > been evaluated would both have been reasonable times to decide to go > for PI instead. Recall that from the outset (e.g. long before shim6) some of the very early pi prefixes to be assigned were done to organizations which are not internet service providers in any traditional sense. 2001:490::/32 not an isp... 2001:420::/32 not an isp... having received an assignment under the then existing policy it was not hard for large corporate or academic network operators to describe themselves as LIRs. Morever no-one batted an eye when I deaggregated a /32 into /36s we can hem and haw for a long about the possible prefix count and where one draws the line but it's been a consideration since the begining. If the fundamental distinction for who got a pi prefix and who didn't is scale, well there are a lot of ISPS that are small. That camel had it's nose under the tent from day one. From mnagel at willingminds.com Sun Mar 18 22:01:40 2012 From: mnagel at willingminds.com (Mark D. Nagel) Date: Sun, 18 Mar 2012 20:01:40 -0700 Subject: dell switch config export In-Reply-To: <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> References: <4F638EA4.8060204@mompl.net> <8011350.1021.1331935375313.JavaMail.geo-discussion-forums@ynee13> Message-ID: <9e91466b-68e2-4401-a971-b7f0ff9ef417@email.android.com> Ryan Malayter wrote: >Despite the terrible GUI and passable CLI, we're found the our 6248s to >be >remarkable stable and bug free. Some have been up for more than 3 >years, >and all the things you expect to be problematic on cheap switches >(cross-stack LACP, multicast, MSTP, QoS) work perfectly. I would agree they are passable, but they have broken sFlow support (e.g., not supported on LAGs, though this is documented nowhere, sFlow generates invalid data when it does work, stack management is not even close to appropriate for production environments, almost any change requires a full stack reset, and stack member flash storage failures are way too common). That said, at least they try with sFlow, just wish they would get it working. Mark From jeroen at mompl.net Mon Mar 19 15:16:00 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 19 Mar 2012 13:16:00 -0700 Subject: Regex validation, was Re: Programmers with network engineering skills In-Reply-To: References: Message-ID: <4F679400.8000909@mompl.net> Joel Maslak wrote: > is not. But there is value in not passing utter garbage to another > program (it has a tendency to clog mail queues, if for no other > reason) - just make sure you do it right. I fail to see why you wouldn't be able to throttle any abuse of your webform so it wouldn't clog a mail queue. Besides it's very hard to clog or otherwise overload an MTA, since it's purpose built to handle that kind of thing. I also fail to see why it would be so hard to install an MTA listening on localhost which sole purpose would be to validate email addresses and nothing else. And just dumps any possible outgoing email to /dev/null. If you're afraid of clogging the mail queue then only hand it off to the sending MTA after validation succeeded. But to be honest why would you care? MTAs are purpose made to handle such things. I can't really think of a scenario where validating an email address using a separate service would create such a performance bottleneck. If you have robots flooding your web forms 1000s of times a second (still peanuts for the average MTA) you need to rethink your security and abuse prevention...not your email validation...I would say. :-) People us a separate database instance for database queries, the database server has its own code to validate input. We don't code our own database server as part of the web form handling code. Why not hand of email validation the same way? > Okay, I'll step off the soap box and let the next person holler about > how I was wrong about all this! You're mostly right, but I disagreed about the email validation part. I just don't see a point in re-inventing the wheel when there are perfectly capable free alternatives that can do it for you with no noticeable performance penalty. Greetings, Jeroen -- Earthquake Magnitude: 4.8 Date: Saturday, March 17, 2012 01:49:29 UTC Location: Banda Sea Latitude: -7.0313; Longitude: 123.4175 Depth: 632.60 km From frnkblk at iname.com Tue Mar 20 03:36:54 2012 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 20 Mar 2012 03:36:54 -0500 Subject: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error" Message-ID: <01fb01cd0674$9b010240$d10306c0$@iname.com> Email to Level3's "DL-IPV6-Support at Level3.com" has gone unanswered, so perhaps someone on this list can prompt the right group at Level3 to look at this: nagios:/tmp# wget -6 ipv6.level3.com --2012-03-20 03:35:16-- http://ipv6.level3.com/ Resolving ipv6.level3.com... 2001:1900:2018:3000::105 Connecting to ipv6.level3.com|2001:1900:2018:3000::105|:80... connected. HTTP request sent, awaiting response... 500 Internal Server Error 2012-03-20 03:35:16 ERROR 500: Internal Server Error. nagios:/tmp# It's been an issue since Saturday, 3:09 am Central. Regards, Frank Bulk From tagno25 at gmail.com Tue Mar 20 04:41:01 2012 From: tagno25 at gmail.com (Philip Dorr) Date: Tue, 20 Mar 2012 04:41:01 -0500 Subject: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error" In-Reply-To: <01fb01cd0674$9b010240$d10306c0$@iname.com> References: <01fb01cd0674$9b010240$d10306c0$@iname.com> Message-ID: Chrome, Konqueror, and Firefox load the page fine. But wget and curl gave 500 errors. With telnet I narrowed it down to the "Accept-Language:" having to be two or more characters long. wget -6 ipv6.level3.com --header='Accept-Language: fake' --2012-03-20 04:40:20-- http://ipv6.level3.com/ Resolving ipv6.level3.com... 2001:1900:2018:3000::105 Connecting to ipv6.level3.com|2001:1900:2018:3000::105|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 51504 (50K) [text/html] Saving to: `index.html' 100%[======================================>] 51,504 17.4K/s in 2.9s 2012-03-20 04:40:23 (17.4 KB/s) - `index.html' saved [51504/51504] On Tue, Mar 20, 2012 at 3:36 AM, Frank Bulk wrote: > Email to Level3's "DL-IPV6-Support at Level3.com" has gone unanswered, so > perhaps someone on this list can prompt the right group at Level3 to look at > this: > > nagios:/tmp# wget -6 ipv6.level3.com > --2012-03-20 03:35:16-- ?http://ipv6.level3.com/ > Resolving ipv6.level3.com... 2001:1900:2018:3000::105 > Connecting to ipv6.level3.com|2001:1900:2018:3000::105|:80... connected. > HTTP request sent, awaiting response... 500 Internal Server Error > 2012-03-20 03:35:16 ERROR 500: Internal Server Error. > > nagios:/tmp# > > It's been an issue since Saturday, 3:09 am Central. > > Regards, > > Frank Bulk > > From jrjahangir at gmail.com Tue Mar 20 06:29:18 2012 From: jrjahangir at gmail.com (Md.Jahangir Hossain) Date: Tue, 20 Mar 2012 17:29:18 +0600 Subject: About CISCO ASR 1006 router performance. Message-ID: Dear valued member: Wishes all are fine. i need suggestion from you about CISCO ASR 1006 router performance. i want to buy this router for IP Transit provider where i received all global routes . it would be nice please put your valued suggestion about this issue. Thanks ---------- Jahangir* * From cb.list6 at gmail.com Tue Mar 20 06:51:58 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 20 Mar 2012 04:51:58 -0700 Subject: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error" In-Reply-To: References: <01fb01cd0674$9b010240$d10306c0$@iname.com> Message-ID: Not sure on the usefulness of these threads, but i have been getting testy about lightreading.com not working wget -6 www.lightreading.com --2012-03-20 04:48:25-- http://www.lightreading.com/ Resolving www.lightreading.com (www.lightreading.com)... 2001:470:1f06:1274::2 Connecting to www.lightreading.com (www.lightreading.com)|2001:470:1f06:1274::2|:80... failed: Connection refused. [cbyrne at chair6 ~]$ Perhaps they will write a story about how they tried and failed to deploy IPv6 From frnkblk at iname.com Tue Mar 20 06:53:42 2012 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 20 Mar 2012 06:53:42 -0500 Subject: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error" In-Reply-To: References: <01fb01cd0674$9b010240$d10306c0$@iname.com> Message-ID: <01fd01cd0690$19011110$4b033330$@iname.com> Thanks, this was a case of the CLI tools indicating an error that doesn't exist in the actual GUI. I've never seen this before, but will need to adjust my host checks accordingly. Frank -----Original Message----- From: Philip Dorr [mailto:tagno25 at gmail.com] Sent: Tuesday, March 20, 2012 4:41 AM To: Frank Bulk Cc: nanog at nanog.org Subject: Re: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error" Chrome, Konqueror, and Firefox load the page fine. But wget and curl gave 500 errors. With telnet I narrowed it down to the "Accept-Language:" having to be two or more characters long. wget -6 ipv6.level3.com --header='Accept-Language: fake' --2012-03-20 04:40:20-- http://ipv6.level3.com/ Resolving ipv6.level3.com... 2001:1900:2018:3000::105 Connecting to ipv6.level3.com|2001:1900:2018:3000::105|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 51504 (50K) [text/html] Saving to: `index.html' 100%[======================================>] 51,504 17.4K/s in 2.9s 2012-03-20 04:40:23 (17.4 KB/s) - `index.html' saved [51504/51504] On Tue, Mar 20, 2012 at 3:36 AM, Frank Bulk wrote: > Email to Level3's "DL-IPV6-Support at Level3.com" has gone unanswered, so > perhaps someone on this list can prompt the right group at Level3 to look at > this: > > nagios:/tmp# wget -6 ipv6.level3.com > --2012-03-20 03:35:16-- http://ipv6.level3.com/ > Resolving ipv6.level3.com... 2001:1900:2018:3000::105 > Connecting to ipv6.level3.com|2001:1900:2018:3000::105|:80... connected. > HTTP request sent, awaiting response... 500 Internal Server Error > 2012-03-20 03:35:16 ERROR 500: Internal Server Error. > > nagios:/tmp# > > It's been an issue since Saturday, 3:09 am Central. > > Regards, > > Frank Bulk > > From Vinny_Abello at Dell.com Tue Mar 20 09:40:57 2012 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Tue, 20 Mar 2012 14:40:57 +0000 Subject: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error" In-Reply-To: References: <01fb01cd0674$9b010240$d10306c0$@iname.com> Message-ID: FYI - it's also the main IPv4 site, not just IPv6... although I'm unsure if it's the same issue. I was monitoring availability as a point of reference for my network and started receiving 500 errors recently as well that tripped up the monitoring system, even though the page comes up in any browser I try. GET / HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT) Accept: */* Host: www.level3.com HTTP/1.1 500 Internal Server Error Connection: Keep-Alive Set-Cookie: ISAWPLB{98EBD5B9-3291-4747-849D-EABBFCE6EAA5}={895C6EC5-4BFE-48F4-A0A2-3393F2E8CF2F}; HttpOnly; Path=/ Content-Length: 3026 Date: Tue, 20 Mar 2012 14:33:53 GMT Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/7.5 Cache-Control: private X-AspNet-Version: 2.0.50727 X-Powered-By: ASP.NET This is followed by a typical obfuscated ASP.NET application runtime error. I just chose a different reference point to monitor and didn't really dig into it much more than that... -Vinny -----Original Message----- From: Philip Dorr [mailto:tagno25 at gmail.com] Sent: Tuesday, March 20, 2012 5:41 AM To: Frank Bulk Cc: nanog at nanog.org Subject: Re: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error" Chrome, Konqueror, and Firefox load the page fine. But wget and curl gave 500 errors. With telnet I narrowed it down to the "Accept-Language:" having to be two or more characters long. wget -6 ipv6.level3.com --header='Accept-Language: fake' --2012-03-20 04:40:20-- http://ipv6.level3.com/ Resolving ipv6.level3.com... 2001:1900:2018:3000::105 Connecting to ipv6.level3.com|2001:1900:2018:3000::105|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 51504 (50K) [text/html] Saving to: `index.html' 100%[======================================>] 51,504 17.4K/s in 2.9s 2012-03-20 04:40:23 (17.4 KB/s) - `index.html' saved [51504/51504] On Tue, Mar 20, 2012 at 3:36 AM, Frank Bulk wrote: > Email to Level3's "DL-IPV6-Support at Level3.com" has gone unanswered, so > perhaps someone on this list can prompt the right group at Level3 to look at > this: > > nagios:/tmp# wget -6 ipv6.level3.com > --2012-03-20 03:35:16-- ?http://ipv6.level3.com/ > Resolving ipv6.level3.com... 2001:1900:2018:3000::105 > Connecting to ipv6.level3.com|2001:1900:2018:3000::105|:80... connected. > HTTP request sent, awaiting response... 500 Internal Server Error > 2012-03-20 03:35:16 ERROR 500: Internal Server Error. > > nagios:/tmp# > > It's been an issue since Saturday, 3:09 am Central. > > Regards, > > Frank Bulk > > From jeroen at unfix.org Tue Mar 20 09:54:13 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 20 Mar 2012 15:54:13 +0100 Subject: Monitoring other people's sites (Was: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error") In-Reply-To: References: <01fb01cd0674$9b010240$d10306c0$@iname.com> Message-ID: <4F689A15.8020707@unfix.org> On 2012-03-20 15:40 , Vinny_Abello at Dell.com wrote: > FYI - it's also the main IPv4 site, not just IPv6... although I'm > unsure if it's the same issue. > > I was monitoring availability as a point of reference for my network > and started receiving 500 errors recently as well that tripped up the > monitoring system, even though the page comes up in any browser I > try. > > GET / HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; > Windows NT) For everybody who is "monitoring" other people's websites, please please please, monitor something static like /robots.txt as that can be statically served and is kinda appropriate as it is intended for robots. Oh and of course do set the User-Agent to something logical and to be super nice include a contact address so that people who do check their logs once in a while for fishy things they at least know what is happening there and that it is not a process run afoul or something. Of course, asking before doing tends to be a good idea too. The IPv6 Internet already consists way too much out of monitoring by pulling pages and doing pings... Fortunately that should heavily change in a few months. Greets, Jeroen (who noticed a certain s....h company performing latency checks against one of his sites, which was no problem, but the fact that they where causing almost more hits/traffic/load than normal clients was a bit on the much side, them pulling robots.txt solved their problem to be able to check if their IPv6 worked fine and the load issue on the server side was gone too as nginx happily serves little robots.txt's at great speed from cache ;) And for the few folks putting nagios's on other people's sites, they obviously do not understand that even if the alarm goes off that something is broken that they cannot fix it anyway, thus why bother... From nick at foobar.org Tue Mar 20 10:53:42 2012 From: nick at foobar.org (Nick Hilliard) Date: Tue, 20 Mar 2012 15:53:42 +0000 Subject: Monitoring other people's sites (Was: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error") In-Reply-To: <4F689A15.8020707@unfix.org> References: <01fb01cd0674$9b010240$d10306c0$@iname.com> <4F689A15.8020707@unfix.org> Message-ID: <4F68A806.9020607@foobar.org> On 20/03/2012 14:54, Jeroen Massar wrote: > For everybody who is "monitoring" other people's websites, please please > please, monitor something static like /robots.txt as that can be > statically served and is kinda appropriate as it is intended for robots. Depends on what you are monitoring. If you're looking for layer 4 ipv6 connectivity then robots.txt is fine. If you're trying to determine whether a site is serving active content on ipv6 and not serving http errors, then it's pretty pointless to monitor robots.txt - you need to monitor /. > Oh and of course do set the User-Agent to something logical and to be > super nice include a contact address so that people who do check their > logs once in a while for fishy things they at least know what is > happening there and that it is not a process run afoul or something. Good policy, yes. Some robots do this but others don't. > Of course, asking before doing tends to be a good idea too. Depends on the scale. I'm not going to ask permission to poll someone else's site every 5 minutes, and I would be surprised if they asked me the same. OTOH, if they were polling to the point that it was causing issues, that might be different. > The IPv6 Internet already consists way too much out of monitoring by > pulling pages and doing pings... "way too much" for what? IPv6 is not widely adopted. > Fortunately that should heavily change in a few months. We've been saying this for years. World IPv6 day 2012 will come and go, and things are unlikely to change a whole lot. The only thing that World IPv6 day 2012 will ensure is that people whose ipv6 configuration actively interferes with their daily Internet usage will be self-flagged and their configuration issues can be dealt with. > (who noticed a certain s....h company performing latency checks against > one of his sites, which was no problem, but the fact that they where > causing almost more hits/traffic/load than normal clients was a bit on > the much side If that web page is configured to be as top-heavy as this, then I'd suggest putting a cache in front of it. nginx is good for this sort of thing. Nick From jhellenthal at dataix.net Tue Mar 20 11:29:14 2012 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Tue, 20 Mar 2012 12:29:14 -0400 Subject: Monitoring other people's sites (Was: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error") In-Reply-To: <4F689A15.8020707@unfix.org> References: <01fb01cd0674$9b010240$d10306c0$@iname.com> <4F689A15.8020707@unfix.org> Message-ID: <20120320162914.GB63274@DataIX.net> On Tue, Mar 20, 2012 at 03:54:13PM +0100, Jeroen Massar wrote: > On 2012-03-20 15:40 , Vinny_Abello at Dell.com wrote: > > FYI - it's also the main IPv4 site, not just IPv6... although I'm > > unsure if it's the same issue. > > > > I was monitoring availability as a point of reference for my network > > and started receiving 500 errors recently as well that tripped up the > > monitoring system, even though the page comes up in any browser I > > try. > > > > GET / HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; > > Windows NT) > > For everybody who is "monitoring" other people's websites, please please > please, monitor something static like /robots.txt as that can be > statically served and is kinda appropriate as it is intended for robots. > Oh and of course do set the User-Agent to something logical and to be > super nice include a contact address so that people who do check their > logs once in a while for fishy things they at least know what is > happening there and that it is not a process run afoul or something. > > Of course, asking before doing tends to be a good idea too. > > The IPv6 Internet already consists way too much out of monitoring by > pulling pages and doing pings... > > Fortunately that should heavily change in a few months. > > Greets, > Jeroen > > (who noticed a certain s....h company performing latency checks against > one of his sites, which was no problem, but the fact that they where > causing almost more hits/traffic/load than normal clients was a bit on > the much side, them pulling robots.txt solved their problem to be able > to check if their IPv6 worked fine and the load issue on the server side > was gone too as nginx happily serves little robots.txt's at great speed > from cache ;) > > And for the few folks putting nagios's on other people's sites, they > obviously do not understand that even if the alarm goes off that > something is broken that they cannot fix it anyway, thus why bother... I agree! leave the monitoring for those that are hired to do so. Using someone elses server to verify that your ipv6 connectivity works should just strictly get your traffic dropped or null-routed with an alert sent to your provider. ping6 your provider... wget -6 your provider but beyond that you, most likely cannot fix it... -- ;s =; From felipe at starbyte.net Tue Mar 20 14:51:28 2012 From: felipe at starbyte.net (Felipe Zanchet Grazziotin) Date: Tue, 20 Mar 2012 16:51:28 -0300 Subject: ifHighSpeed for 10 Gb/s port-channels Message-ID: Hello, can anyone confirm why IF-MIB::ifHighSpeed should return 0 for aggregates of 10 Gbit/s ports? My google-foo led me to several topics on "use ifHighSpeed to 10 Gbit/s", but none is clear on 10 Gbit/s aggregated. So far I could only find references pointing to IEEE Std 802.1AX-2008 clause 6.3.1.1.16 (aAggDataRate), mapping to IF-MIB::ifSpeed, which is locked in 4,294,967,295 (Gauge32). In this same standard it is very specific about ifHighSpeed: "Set to zero.". Or, more directly: how can one find current speed of a 10Gb/s+ link aggregate port? Please, answer me off-list and I promise to summarize an answer... :) Thanks in advance. Felipe From charles-lists at knownelement.com Tue Mar 20 15:45:55 2012 From: charles-lists at knownelement.com (Charles N Wyble) Date: Tue, 20 Mar 2012 15:45:55 -0500 Subject: Monitoring other people's sites (Was: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error") In-Reply-To: <4F689A15.8020707@unfix.org> References: <01fb01cd0674$9b010240$d10306c0$@iname.com> <4F689A15.8020707@unfix.org> Message-ID: <4F68EC83.406@knownelement.com> On 03/20/2012 09:54 AM, Jeroen Massar wrote: > On 2012-03-20 15:40 , Vinny_Abello at Dell.com wrote: > > For everybody who is "monitoring" other people's websites, please please > please, monitor something static like /robots.txt as that can be > statically served and is kinda appropriate as it is intended for robots. This could provide a false positive if one is interested in ensuring that the full application stack is working. > Oh and of course do set the User-Agent to something logical and to be > super nice include a contact address so that people who do check their > logs once in a while for fishy things they at least know what is > happening there and that it is not a process run afoul or something. A server side process? Or client side? If the client side monitoring is too aggressive , then your rate limiting firewall rules should kick in and block it. If you don't have a rate limiting firewall on your web server, (on the server itself, not in front of it) then you have bigger problems. > Of course, asking before doing tends to be a good idea too. If you are running a public service, expect it to get monitored/attacked/probed etc. If you don't want traffic from certain sources then block it. > The IPv6 Internet already consists way too much out of monitoring by > pulling pages and doing pings... Who made you the arbiter of acceptable automated traffic levels? > > > (who noticed a certain s....h company performing latency checks against > one of his sites, which was no problem, but the fact that they where > causing almost more hits/traffic/load than normal clients was a bit on > the much side, Again. Use a firewall and limit them if the traffic isn't in line with your site policies. > And for the few folks putting nagios's on other people's sites, they > obviously do not understand that even if the alarm goes off that > something is broken that they cannot fix it anyway, thus why bother... You obviously do not understand why people are implementing these monitors. It's to serve as a canary for v6 connectivity issues. If I was implementing a monitor like this, I'd use the following logic: HTTP 200 returned via v4/v6 == all is well HTTP 200 returned via v4 or v6 , no HTTP code returned via v4 or v6 (ie one path works) == v6/v4 potentially broken. no HTTP code returned via either method == end site problem. nothing we can do. don't alert. Presumably you'd also implement a TCP 80 check as well. From lstewart at superb.net Tue Mar 20 15:53:46 2012 From: lstewart at superb.net (Landon Stewart) Date: Tue, 20 Mar 2012 13:53:46 -0700 Subject: Looking for advice - Auditing zones on a set of name servers Message-ID: Hi Everyone, I'm looking for some advice here. I'm attempting to clean up a set of name servers and have a list of domain names that should not actually be hosted on those name servers. In some cases there are issues where there are actually no NS records in a domain but it should be hosted on those name servers. In some cases the name servers just aren't authoritative and the domain should be removed. The name servers are all djbdns, not that it matters a whole lot. I'm wondering if anyone knows of some tools that I can use other than homegrown ones that are a little more robust in terms of thinking of every little possible issue for or against a domain than I can think of. Of a list of domains that I marked for deletion some of them simply had little problems but should not be deleted (rather just have their NS records fixed). I also don't' want to pound on someone else's recursive name servers or even the root name servers trying to audit ours since that's not very nice. If anything I guess I could spread out the queries if I had the right tools. I wrote a quick script that looks up the NS records for a zone, then the A records for those NS records and checks the resulting IP addresses against a list of IP addresses that are our name servers. It's not quite doing all I need it to do since sometimes we are authoritative but there are no NS records or they are wrong. I'm also not sure beating on google's name servers is a good idea either so you should fill in your OWN recursive name servers instead f 8.8.8.8 and 8.8.4.4. Thanks for reading! :-D #!/usr/bin/perl # No warranty or guarantee of fitness for any purpose or use. Do not use # if you don't know what it does. # use strict; use Net::Nslookup; die ("Usage: $0 \n") if !$ARGV[0]; # Array of the IP addresses of YOUR name servers my @goodns = ( "10.10.0.5", "10.10.1.5", ); open(F,"<$ARGV[0]") or die("Cannot open file: $ARGV[0]\n"); my @zonelist = ; close(F); chomp(@zonelist); ##### # Cycle through each zone to find out if we are authoritative on one of the IPs listed # above in @goodns. ##### foreach my $zone (@zonelist) { # Sub 8.8.8.8 and 8.8.4.4 for your own recursive name server IP addresses to # avoid being rude to google's name servers if you are doing a lot of lookups. # # Find the NS records for the zone my @pns = nslookup(domain => $zone, type => "NS", server => [ '8.8.8.8', '8.8.4.4'] ); # Cycle through each NS record and store an IP address for each my @dns_a_records = (); foreach my $ns (@pns) { my $arr = nslookup(domain => $ns, type => "A", server => [ '8.8.8.8', '8.8.4.4'] ); push(@dns_a_records,$arr); } ##### # If @dns_a_records contains stuff that's also in @goodns then it means # we are probably authoritative in some way. ##### my %goodns=map{$_ =>1} @goodns; my %dns_a_records=map{$_=>1} @dns_a_records; my @isect = grep( $goodns{$_}, @dns_a_records ); if (!@isect) { @dns_a_records[0] = "NONE" if (!@dns_a_records); # We are not authoritative - print the zone and ns record information with a - print "-:$zone: ".join(",", at pns)."\[".join(",", @dns_a_records)."\]\n"; } else { # We are authoritative print it with a + print "+:$zone: ".join(",", at pns)."\[".join(",", @dns_a_records)."\]\n"; } } # END --- Landon Stewart > Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": www.superb.net From nathan at atlasnetworks.us Tue Mar 20 16:23:32 2012 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 20 Mar 2012 21:23:32 +0000 Subject: Clueful Mail Contact at Charter.net Message-ID: <8C26A4FDAE599041A13EB499117D3C287C9D5A73@EX-MB-1.corp.atlasnetworks.us> Would a clueful mail admin at Charter.net please contact me off list? From pfunix at gmail.com Tue Mar 20 17:26:03 2012 From: pfunix at gmail.com (Beavis) Date: Tue, 20 Mar 2012 16:26:03 -0600 Subject: About CISCO ASR 1006 router performance. In-Reply-To: References: Message-ID: suggest go to http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf On Tue, Mar 20, 2012 at 5:29 AM, Md.Jahangir Hossain wrote: > Dear valued member: > > > Wishes all are fine. > > > i need ? suggestion from you about CISCO ASR 1006 router performance. i > want to buy ?this router for IP Transit provider where i received ?all > global routes . > > > it would be nice please put your valued suggestion about this issue. > > > > > > Thanks > ---------- Jahangir* > * -- ()? ascii ribbon campaign - against html e-mail /\? www.asciiribbon.org?? - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From morrowc.lists at gmail.com Tue Mar 20 19:24:29 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 20 Mar 2012 20:24:29 -0400 Subject: Looking for advice - Auditing zones on a set of name servers In-Reply-To: References: Message-ID: On Tue, Mar 20, 2012 at 4:53 PM, Landon Stewart wrote: > I'm looking for some advice here. ?I'm attempting to clean up a set of name > servers and have a list of domain names that should not actually be hosted > on those name servers. ?In some cases there are issues where there are > actually no NS records in a domain but it should be hosted on those name > servers. ?In some cases the name servers just aren't authoritative and the > domain should be removed. ?The name servers are all djbdns, not that it > matters a whole lot. > I wrote a quick script that looks up the NS records for a zone, then the A > records for those NS records and checks the resulting IP addresses against > a list of IP addresses that are our name servers. ?It's not quite doing all > I need it to do since sometimes we are authoritative but there are no NS > records or they are wrong. ?I'm also not sure beating on google's name > servers is a good idea either so you should fill in your OWN recursive name > servers instead f 8.8.8.8 and 8.8.4.4. don't you really want to walk the tree from . down? so dig +trace | machine-ify then make sure that the criteria you care about work out properly? (this avoides people's old/legacy/super-long-ttl causing problems in the shorter term) -chris From sherwin.ang at gmail.com Wed Mar 21 00:10:19 2012 From: sherwin.ang at gmail.com (Sherwin Ang) Date: Wed, 21 Mar 2012 13:10:19 +0800 Subject: About CISCO ASR 1006 router performance. In-Reply-To: References: Message-ID: I am currently running ASR1006 with ESP20 with 12 full routes and routing around 12gig of traffic with no issues. i guess it would depend on the size of traffic that you will be putting in at day 1 and for the next 3-5 years to protect your investment. You can also have the ESP40 if you need more backplane capacity. -Sherwin On Tue, Mar 20, 2012 at 7:29 PM, Md.Jahangir Hossain wrote: > Dear valued member: > > > Wishes all are fine. > > > i need ? suggestion from you about CISCO ASR 1006 router performance. i > want to buy ?this router for IP Transit provider where i received ?all > global routes . > > > it would be nice please put your valued suggestion about this issue. > > > > > > Thanks > ---------- Jahangir* > * From jeroen at unfix.org Wed Mar 21 03:43:03 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 21 Mar 2012 09:43:03 +0100 Subject: Monitoring other people's sites (Was: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error") In-Reply-To: <4F68A806.9020607@foobar.org> References: <01fb01cd0674$9b010240$d10306c0$@iname.com> <4F689A15.8020707@unfix.org> <4F68A806.9020607@foobar.org> Message-ID: <4F699497.1040908@unfix.org> On 2012-03-20 16:53 , Nick Hilliard wrote: > On 20/03/2012 14:54, Jeroen Massar wrote: >> For everybody who is "monitoring" other people's websites, please please >> please, monitor something static like /robots.txt as that can be >> statically served and is kinda appropriate as it is intended for robots. > > Depends on what you are monitoring. If you're looking for layer 4 ipv6 > connectivity then robots.txt is fine. If you're trying to determine > whether a site is serving active content on ipv6 and not serving http > errors, then it's pretty pointless to monitor robots.txt - you need to > monitor /. And as can be seen with the monitoring of ipv6.level3.com it will tell you 'it is broken' but as the person who is monitoring has no relation or contact with them, it only leads to public complaints which do not get resolved.... If the site themselves cannot be arsed to monitor their own, then why would you bother to do so. Indeed, I agree that it can be useful, especially as an access ISP, to monitor popular websites so that you know that you can reach them, but that does not mean you need to pull large amounts of data. (for determining MTU issues yes, but likely you have a full 1500 path anyway thus these should as good as possible not happen anyway) But unless you have a contact at the site it will be tough to resolve the issue anyway. >> Oh and of course do set the User-Agent to something logical and to be >> super nice include a contact address so that people who do check their >> logs once in a while for fishy things they at least know what is >> happening there and that it is not a process run afoul or something. > > Good policy, yes. Some robots do this but others don't. > >> Of course, asking before doing tends to be a good idea too. > > Depends on the scale. I'm not going to ask permission to poll someone > else's site every 5 minutes, and I would be surprised if they asked me the > same. OTOH, if they were polling to the point that it was causing issues, > that might be different. I was not talking about that low rate, not a lot of people will notice that, but the 1000qps from 500 sources was quite noticed and thus at first they got blocked, then we tried to find out who was doing it, and then they repointed to robots.txt, unblocked them and all was fine. >> The IPv6 Internet already consists way too much out of monitoring by >> pulling pages and doing pings... > > "way too much" for what? IPv6 is not widely adopted. In comparison to real traffic. There has been a saying since the 6bone days already that IPv6 is just ICMPv6... >> Fortunately that should heavily change in a few months. > > We've been saying this for years. World IPv6 day 2012 will come and go, > and things are unlikely to change a whole lot. The only thing that World > IPv6 day 2012 will ensure is that people whose ipv6 configuration actively > interferes with their daily Internet usage will be self-flagged and their > configuration issues can be dealt with. Fully agree, but at least at that point nobody will be able to claim that they can't deploy IPv6 on the access side as there is no content ;) >> (who noticed a certain s....h company performing latency checks against >> one of his sites, which was no problem, but the fact that they where >> causing almost more hits/traffic/load than normal clients was a bit on >> the much side > > If that web page is configured to be as top-heavy as this, then I'd suggest > putting a cache in front of it. nginx is good for this sort of thing. nginx does not help if your content is not cacheable by nginx, for instance if you simply show the IP address of the client and if they thus have IPv6 or IPv4. In our case, indeed, everything that is static is served by nginx, which is why hammering on /robots.txt is not an issue at all... On 2012-03-20 21:45 , Charles N Wyble wrote: > On 03/20/2012 09:54 AM, Jeroen Massar wrote: >> On 2012-03-20 15:40 , Vinny_Abello at Dell.com wrote: >> >> For everybody who is "monitoring" other people's websites, please >> please please, monitor something static like /robots.txt as that >> can be statically served and is kinda appropriate as it is intended >> for robots. > > This could provide a false positive if one is interested in ensuring > that the full application stack is working. As stated above and given the example of the original subject of ipv6.level3.com, what exactly are you going to do when it does not? And again, if the owner does not care, why should you? Also, maybe they do a redesign of the site and remove the keywords or other metrics you are looking for. It is not your problem to monitor it for them, unless they hire you to do so of course. >> Oh and of course do set the User-Agent to something logical and to >> be super nice include a contact address so that people who do check >> their logs once in a while for fishy things they at least know what >> is happening there and that it is not a process run afoul or >> something. > > A server side process? Or client side? Take a guess what something that polls a HTTP server is. > If the client side monitoring > is too aggressive , then your rate limiting firewall rules should > kick in and block it. If you don't have a rate limiting firewall on > your web server, (on the server itself, not in front of it) then you > have bigger problems. You indeed will have a lot of problems when you are doing connection tracking on your website, be that on the box itself or in front of it in a separate TCP state engine. >> Of course, asking before doing tends to be a good idea too. > > > If you are running a public service, expect it to get > monitored/attacked/probed etc. If you don't want traffic from > certain sources then block it. That is exactly what happened, but if they would have set a proper user-agent it would not have taken time to figure out why they where doing it. There is a big difference between malicious and good traffic, people tend to want to serve the latter one. >> The IPv6 Internet already consists way too much out of monitoring >> by pulling pages and doing pings... > > Who made you the arbiter of acceptable automated traffic levels? I did! And as you state yourself, if you do not like it, block it, which is what we do. But that was not what this thread was about, if you recall, it started with noting that you might want to ask for permission and that you might want to provide proper contact details in the probing. >> (who noticed a certain s....h company performing latency checks >> against one of his sites, which was no problem, but the fact that >> they where causing almost more hits/traffic/load than normal >> clients was a bit on the much side, > > Again. Use a firewall and limit them if the traffic isn't in line > with your site policies. I can only suggest running a site once with more than a few hits per second that is distributed around the world and with actual users ;) >> And for the few folks putting nagios's on other people's sites, >> they obviously do not understand that even if the alarm goes off >> that something is broken that they cannot fix it anyway, thus why >> bother... > > You obviously do not understand why people are implementing these > monitors. Having written various monitoring systems I know exactly why they are doing it. I also know that they are monitoring the wrong thing. > It's to serve as a canary for v6 connectivity issues. Just polling robots.txt is good enough for that. Asking the site operator if it is good with them is also a good idea. Providing contact details in the User-Agent is also a good idea. > If I > was implementing a monitor like this, I'd use the following logic: > > HTTP 200 returned via v4/v6 == all is well HTTP 200 returned via v4 > or v6 , no HTTP code returned via v4 or v6 (ie one path works) == > v6/v4 potentially broken. no HTTP code returned via either method == > end site problem. nothing we can do. don't alert. And then you get an alert, who are you going to call? > Presumably you'd also implement a TCP 80 check as well. Ehmmm, you do realize that if you are able to get a HTTP response that you have (unless doing HTTPS) actually already contacted port 80 over TCP? :) Greets, Jeroen From michiel at klaver.it Wed Mar 21 03:54:52 2012 From: michiel at klaver.it (Michiel Klaver) Date: Wed, 21 Mar 2012 09:54:52 +0100 Subject: Microsoft/Hotmail forgot to set reverse DNS pointers? Message-ID: <4F69975C.3060001@klaver.it> Today I received some notices about Hotmail users who couldn't send e-mail messages to various receipients due to spamfilters blocking them at the receiving mailservers. Seems like Microsoft/Hotmail staff forgot to set some reverse DNS pointer records: Diagnostic-Code: smtp;450 4.7.1 Client host rejected: cannot find your reverse hostname, [157.55.1.150] (Verified this using various public DNS servers, to exclude potential local issues) Anyone here who has proper contacts to give them the clue-bat? -- Michiel Klaver IT Professional From bilal.souman at hotmail.com Wed Mar 21 04:15:43 2012 From: bilal.souman at hotmail.com (Bilal Souman) Date: Wed, 21 Mar 2012 11:15:43 +0200 Subject: MPLS VRF Monitoring Message-ID: Dear All, is there any open source system you can use to monitor routes and interfaces availability inside multiple MPLS VRFs Thanks From jrjahangir at gmail.com Wed Mar 21 04:28:45 2012 From: jrjahangir at gmail.com (Md.Jahangir Hossain) Date: Wed, 21 Mar 2012 15:28:45 +0600 Subject: About CISCO ASR 1006 router performance. In-Reply-To: References: Message-ID: thanks guys for your valued information . On Wed, Mar 21, 2012 at 11:10 AM, Sherwin Ang wrote: > I am currently running ASR1006 with ESP20 with 12 full routes and > routing around 12gig of traffic with no issues. > > i guess it would depend on the size of traffic that you will be > putting in at day 1 and for the next 3-5 years to protect your > investment. You can also have the ESP40 if you need more backplane > capacity. > > > > > -Sherwin > > On Tue, Mar 20, 2012 at 7:29 PM, Md.Jahangir Hossain > wrote: > > Dear valued member: > > > > > > Wishes all are fine. > > > > > > i need suggestion from you about CISCO ASR 1006 router performance. i > > want to buy this router for IP Transit provider where i received all > > global routes . > > > > > > it would be nice please put your valued suggestion about this issue. > > > > > > > > > > > > Thanks > > ---------- Jahangir* > > * > -- Thanks ---------- Jahangir* * From cra at WPI.EDU Wed Mar 21 08:27:19 2012 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 21 Mar 2012 09:27:19 -0400 Subject: how to report spam to Yahoo! Message-ID: <20120321132719.GT1574@angus.ind.WPI.EDU> Yahoo!'s abuse contact from whois: OrgAbuseEmail: network-abuse at cc.yahoo-inc.com now sends an autoresponse that tells you to go to a web form to report spam: http://help.yahoo.com/l/us/yahoo/mail/yahoomail/spam.html but the link doesn't work--it just redirects to a generic Yahoo! help page at: http://help.yahoo.com/kb/index?page=product&locale=en_US&y=PROD_MAIL_ML So how does a non-Yahoo! account holder report spam originating from Yahoo!'s network? ----- Forwarded message from Yahoo! Network ----- From: Yahoo! Network Date: Wed, 21 Mar 2012 05:59:35 -0700 Reply-To: Yahoo! Network Thank you for your email, but this address is no longer being used for abuse reporting or abuse related questions. To report spam, please use this form: http://help.yahoo.com/l/us/yahoo/mail/yahoomail/spam.html To report other types of abuse or for help with security or abuse related issues, please go to Yahoo! Abuse: http://abuse.yahoo.com For questions about using Yahoo! services, please visit Yahoo Help: http://help.yahoo.com Note: Please do not reply to this email as replies will not be answered. Thank you, - Yahoo! Customer Care Original Message Follows: ------------------------ From jasongurtz at npumail.com Wed Mar 21 09:29:34 2012 From: jasongurtz at npumail.com (Jason Gurtz) Date: Wed, 21 Mar 2012 10:29:34 -0400 Subject: Microsoft/Hotmail forgot to set reverse DNS pointers? In-Reply-To: <4F69975C.3060001@klaver.it> References: <4F69975C.3060001@klaver.it> Message-ID: > Diagnostic-Code: smtp;450 4.7.1 Client host rejected: cannot find your > reverse hostname, [157.55.1.150] > > (Verified this using various public DNS servers, to exclude potential > local > issues) > > Anyone here who has proper contacts to give them the clue-bat? noc at microsoft.com will probably understand or at least point you in the right direction. ~JasonG From michael.holstein at csuohio.edu Wed Mar 21 09:44:09 2012 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 21 Mar 2012 10:44:09 -0400 Subject: spammers trying to "lease" IP space? Message-ID: <4F69E939.8060006@csuohio.edu> I know this tactic isn't exactly new .. just thought I'd pass this along. Text below is exact with exception of our ARIN information and ranges (which any of you could figure out anyway). Cheers, Michael Holstein Cleveland State University --snip-- Description: ABC Widgets *Greetings, NOC or IP Admin at (our ARIN NetName)* ** We would like to Lease or even Purchase some of your IPv4 Ranges like (our/16) ?Why do You want to lease our IPs?? Very Simply: Our Business is the delivery of Opted In Marketing Email. The key to this business is good stewardship of IP assets to ensure deliverability, and even more importantly; *Sustainability. *Many of our IP leases last years due to our investment in our network before we ever even mail. As a result it takes Several months before a subnet is profitable for us after recouping our initial infrastructure expenses. So to Hit and Run simply does not make good business sense, after all maybe if we are good to our word you will offer us additional IPs! ** there are two core requirements in any Major League Mail Campaign ? a. _Having a solid list_ with real recipients and records to prove their Sign up is vital to delivery but also to settling any complaints registered with an ISP. b. _Using Multiple IP addresses_. If having a good list is a good defense then using Multiple Static IP addresses is a proactive measure. ISPs, Backbone Carriers, Software Makers, and more all use (among other means) Algorithms to shape traffic across their networks and to their clients. Using an MTA to spread our traffic across thousands of IP addresses from then thousands of ?C-Blocks? we mitigate the footprint of our traffic originating from any one network range. ?/It should be noted here that this email is a Request for Pricing (RFP) and its recipients have in no way requested it, they have instead been identified through research, and therefore this email should not be thought of as characteristic of our normal mailings./ Precision Management of Texas (USA) offers on-demand solutions for brand marketers and website promotion chiefly through email marketing. Currently PM is seeking to expand its network capability both overseas and here in the US with the addition of several points of presence (PoP) in geographically diverse locations. Precision Management makes no attempt to conceal identity or intentions as a show of good faith on our part that we will be good customers with an eye on building a relationship beyond this installation. It should go without saying that our use of your network will be totally AUP Compliant and any complaints will be handled in 12 hours or less. We only mail to Top Level Domain?s and do no General Internet mailing. Also i want you to be aware that we are an American Company with verifiable references who can attest to how we conduct our email business. Description: C:\Users\BLEAUH~1\AppData\Local\Temp\~ed_sb_i\~files\3.gif Description: Content Image InlinePM seeks to obtain as much diversity in the allocated IP space as possible, however the most important thing is the Subnets need to have no abuse history. We can take the IPs via GRE or BGP or other such tunneling solution to where you have them announced. Alternatively we can advertise them ourselves on our network, saving you the back-haul. As a third solution we can take a server on your network with the following specs One Virtual (or Dedicated) Server ? Dual Cores 1 GB RAM 100 GB HDD? 3 Mbps dedicated - burstable to 100 Term period minimum of 6-12 months I hope you have read this far and will seriously consider this opportunity to generate additional revenue for your company. If this email has found you in error please fwd it to the right person and cc me. Otherwise hit the un-sub at the bottom! Thanks, Edward Wootan Chief Technical Officer Precision Management LLC 3030 LBJ Freeway Dallas, TX 75234 If you are interested in working with a *Legitimate Marketer * please reply to this email or call me Direct at *(704)286-6098* anytime. The information contained within the referenced, linked, or directed email communication is intended to be a confidential communication between the original sender and recipient, and is to be treated as confidential. All works, ideas, or copy within are copyrighted by precision management llc., and are not to be used in any manner other by which they were intended by precision management llc... If you believe you have received this or any other email in error, please contact cto at precision-management.info From raymond at prolocation.net Wed Mar 21 09:51:15 2012 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Wed, 21 Mar 2012 15:51:15 +0100 (CET) Subject: spammers trying to "lease" IP space? In-Reply-To: <4F69E939.8060006@csuohio.edu> References: <4F69E939.8060006@csuohio.edu> Message-ID: Hi! This was mailed to many ISP's the last days. Bye, Raymond. > I know this tactic isn't exactly new .. just thought I'd pass this along. > > Text below is exact with exception of our ARIN information and ranges > (which any of you could figure out anyway). > > Cheers, > > Michael Holstein > Cleveland State University > > --snip-- > > Description: ABC Widgets > > *Greetings, NOC or IP Admin at (our ARIN NetName)* > > ** > > We would like to Lease or even Purchase some of your IPv4 Ranges like > (our/16) > > ?Why do You want to lease our IPs?? > > > > Very Simply: Our Business is the delivery of Opted In Marketing Email. The key > to this business is good stewardship of IP assets to ensure deliverability, and > even more importantly; *Sustainability. *Many of our IP leases last years due to > our investment in our network before we ever even mail. As a result it takes > Several months before a subnet is profitable for us after recouping our initial > infrastructure expenses. So to Hit and Run simply does not make good business > sense, after all maybe if we are good to our word you will offer us additional IPs! > > ** > > there are two core requirements in any Major League Mail Campaign ? > > > > a. _Having a solid list_ with real recipients and records to prove their Sign up > is vital to delivery but also to settling any complaints registered with an ISP. > > b. _Using Multiple IP addresses_. If having a good list is a good defense then > using Multiple Static IP addresses is a proactive measure. ISPs, Backbone > Carriers, Software Makers, and more all use (among other means) Algorithms to > shape traffic across their networks and to their clients. Using an MTA to spread > our traffic across thousands of IP addresses from then thousands of ?C-Blocks? > we mitigate the footprint of our traffic originating from any one network range. > > > > ?/It should be noted here that this email is a Request for Pricing (RFP) and its > recipients have in no way requested it, they have instead been identified > through research, and therefore this email should not be thought of as > characteristic of our normal mailings./ > > > > Precision Management of Texas (USA) offers on-demand solutions for brand > marketers and website promotion chiefly through email marketing. Currently PM is > seeking to expand its network capability both overseas and here in the US with > the addition of several points of presence (PoP) in geographically diverse > locations. Precision Management makes no attempt to conceal identity or > intentions as a show of good faith on our part that we will be good customers > with an eye on building a relationship beyond this installation. It should go > without saying that our use of your network will be totally AUP Compliant and > any complaints will be handled in 12 hours or less. We only mail to Top Level > Domain?s and do no General Internet mailing. Also i want you to be aware that we > are an American Company with verifiable references who can attest to how we > conduct our email business. > > Description: C:\Users\BLEAUH~1\AppData\Local\Temp\~ed_sb_i\~files\3.gif > > Description: Content Image InlinePM seeks to obtain as much diversity in the > allocated IP space as possible, however the most important thing is the Subnets > need to have no abuse history. > > We can take the IPs via GRE or BGP or other such tunneling solution to where you > have them announced. Alternatively we can advertise them ourselves on our > network, saving you the back-haul. As a third solution we can take a server on > your network with the following specs > > > > One Virtual (or Dedicated) Server ? > > > > Dual Cores > > 1 GB RAM > > 100 GB HDD? > > 3 Mbps dedicated - burstable to 100 > > Term period minimum of 6-12 months > > > > I hope you have read this far and will seriously consider this opportunity to > generate additional revenue for your company. > > If this email has found you in error please fwd it to the right person and cc > me. Otherwise hit the un-sub at the bottom! > > > > Thanks, > > > Edward Wootan > Chief Technical Officer > Precision Management LLC > 3030 LBJ Freeway > Dallas, TX 75234 > If you are interested in working with a *Legitimate Marketer * > please reply to this email or call me Direct at *(704)286-6098* anytime. > > The information contained within the referenced, linked, or directed email > communication is intended to be a confidential communication between the > original sender and recipient, and is to be treated as confidential. All works, > ideas, or copy within are copyrighted by precision management llc., and are not > to be used in any manner other by which they were intended by precision > management llc... If you believe you have received this or any other email in > error, please contact cto at precision-management.info > > > > > > > From jcurran at arin.net Wed Mar 21 10:04:35 2012 From: jcurran at arin.net (John Curran) Date: Wed, 21 Mar 2012 15:04:35 +0000 Subject: spammers trying to "lease" IP space? In-Reply-To: <4F69E939.8060006@csuohio.edu> References: <4F69E939.8060006@csuohio.edu> Message-ID: Michael - We're aware of several parties out there soliciting to 'lease' your address space, and it appears that most of them are bulk email operations. Given that the nearly inevitable consequence is that the blocks in question end up on various anti-spam blacklists, I imagine that anyone would have to think very carefully about pursuing that option... If you truly have more address space than you need, you can always return it :-), list it as available on ARIN's specified transfer listing service (note - this may result in potential recipients calling you) or working with a facilitator to make it available. More info on all of these options: https://www.arin.net/resources/transfers/index.html and: https://www.arin.net/resources/transfer_listing/listers.html FYI, /John John Curran President and CEO ARIN On Mar 21, 2012, at 10:44 AM, Michael Holstein wrote: > I know this tactic isn't exactly new .. just thought I'd pass this along. > > Text below is exact with exception of our ARIN information and ranges > (which any of you could figure out anyway). > > Cheers, > > Michael Holstein > Cleveland State University > > --snip-- > > Description: ABC Widgets > > *Greetings, NOC or IP Admin at (our ARIN NetName)* > > ** > > We would like to Lease or even Purchase some of your IPv4 Ranges like > (our/16) > > ?Why do You want to lease our IPs?? > > > > Very Simply: Our Business is the delivery of Opted In Marketing Email. The key > to this business is good stewardship of IP assets to ensure deliverability, and > even more importantly; *Sustainability. *Many of our IP leases last years due to > our investment in our network before we ever even mail. As a result it takes > Several months before a subnet is profitable for us after recouping our initial > infrastructure expenses. So to Hit and Run simply does not make good business > sense, after all maybe if we are good to our word you will offer us additional IPs! > > ** > > there are two core requirements in any Major League Mail Campaign ? > > > > a. _Having a solid list_ with real recipients and records to prove their Sign up > is vital to delivery but also to settling any complaints registered with an ISP. > > b. _Using Multiple IP addresses_. If having a good list is a good defense then > using Multiple Static IP addresses is a proactive measure. ISPs, Backbone > Carriers, Software Makers, and more all use (among other means) Algorithms to > shape traffic across their networks and to their clients. Using an MTA to spread > our traffic across thousands of IP addresses from then thousands of ?C-Blocks? > we mitigate the footprint of our traffic originating from any one network range. > > > > ?/It should be noted here that this email is a Request for Pricing (RFP) and its > recipients have in no way requested it, they have instead been identified > through research, and therefore this email should not be thought of as > characteristic of our normal mailings./ > > > > Precision Management of Texas (USA) offers on-demand solutions for brand > marketers and website promotion chiefly through email marketing. Currently PM is > seeking to expand its network capability both overseas and here in the US with > the addition of several points of presence (PoP) in geographically diverse > locations. Precision Management makes no attempt to conceal identity or > intentions as a show of good faith on our part that we will be good customers > with an eye on building a relationship beyond this installation. It should go > without saying that our use of your network will be totally AUP Compliant and > any complaints will be handled in 12 hours or less. We only mail to Top Level > Domain?s and do no General Internet mailing. Also i want you to be aware that we > are an American Company with verifiable references who can attest to how we > conduct our email business. > > Description: C:\Users\BLEAUH~1\AppData\Local\Temp\~ed_sb_i\~files\3.gif > > Description: Content Image InlinePM seeks to obtain as much diversity in the > allocated IP space as possible, however the most important thing is the Subnets > need to have no abuse history. > > We can take the IPs via GRE or BGP or other such tunneling solution to where you > have them announced. Alternatively we can advertise them ourselves on our > network, saving you the back-haul. As a third solution we can take a server on > your network with the following specs > > > > One Virtual (or Dedicated) Server ? > > > > Dual Cores > > 1 GB RAM > > 100 GB HDD? > > 3 Mbps dedicated - burstable to 100 > > Term period minimum of 6-12 months > > > > I hope you have read this far and will seriously consider this opportunity to > generate additional revenue for your company. > > If this email has found you in error please fwd it to the right person and cc > me. Otherwise hit the un-sub at the bottom! > > > > Thanks, > > > Edward Wootan > Chief Technical Officer > Precision Management LLC > 3030 LBJ Freeway > Dallas, TX 75234 > If you are interested in working with a *Legitimate Marketer * > please reply to this email or call me Direct at *(704)286-6098* anytime. > > The information contained within the referenced, linked, or directed email > communication is intended to be a confidential communication between the > original sender and recipient, and is to be treated as confidential. All works, > ideas, or copy within are copyrighted by precision management llc., and are not > to be used in any manner other by which they were intended by precision > management llc... If you believe you have received this or any other email in > error, please contact cto at precision-management.info > > > > > > From jmaimon at ttec.com Wed Mar 21 10:44:56 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 21 Mar 2012 11:44:56 -0400 Subject: Looking for some diversity in Alabama that does not involve ATT Fiber Message-ID: <4F69F778.4060505@ttec.com> Hey All, I have a site in Alabama that could really use some additional diversity, but apparently ATT fiber is the only game in town. If anybody has any options, such as fixed wireless in the 10-50mbs, please reply to me, off-list. Best, Joe From michiel at klaver.it Wed Mar 21 10:51:30 2012 From: michiel at klaver.it (Michiel Klaver) Date: Wed, 21 Mar 2012 16:51:30 +0100 Subject: Microsoft/Hotmail forgot to set reverse DNS pointers? In-Reply-To: References: <4F69975C.3060001@klaver.it> Message-ID: <4F69F902.3070209@klaver.it> At 21-03-2012 15:29, Jason Gurtz wrote: >> Diagnostic-Code: smtp;450 4.7.1 Client host rejected: cannot find your >> reverse hostname, [157.55.1.150] >> >> (Verified this using various public DNS servers, to exclude potential >> local >> issues) >> >> Anyone here who has proper contacts to give them the clue-bat? > > noc at microsoft.com will probably understand or at least point you in the > right direction. > > ~JasonG > > Yeah, tried that, doesn't work. Same for moc@ and soc@ : host mail.messaging.microsoft.com[216.32.181.178] said: 550 5.4.1 noc at microsoft.com: Recipient address rejected: Access Denied (in reply to RCPT TO command) From EWieling at nyigc.com Wed Mar 21 10:55:41 2012 From: EWieling at nyigc.com (Eric Wieling) Date: Wed, 21 Mar 2012 11:55:41 -0400 Subject: Looking for some diversity in Alabama that does not involve ATT Fiber In-Reply-To: <4F69F778.4060505@ttec.com> References: <4F69F778.4060505@ttec.com> Message-ID: I don't know about AT&T, but Verizon physically removes the copper connections when they install fiber into a building. Oddly, this is legal. Verizon is required to open up their copper to CLECs, but not fiber. The only option at that point is cable or wireless. -----Original Message----- From: Joe Maimon [mailto:jmaimon at ttec.com] Sent: Wednesday, March 21, 2012 11:45 AM To: North American Networking and Offtopic Gripes List Subject: Looking for some diversity in Alabama that does not involve ATT Fiber Hey All, I have a site in Alabama that could really use some additional diversity, but apparently ATT fiber is the only game in town. If anybody has any options, such as fixed wireless in the 10-50mbs, please reply to me, off-list. Best, Joe From jared at puck.nether.net Wed Mar 21 10:59:38 2012 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 21 Mar 2012 11:59:38 -0400 Subject: Looking for some diversity in Alabama that does not involve ATT Fiber In-Reply-To: <4F69F778.4060505@ttec.com> References: <4F69F778.4060505@ttec.com> Message-ID: <929032A8-29F9-45E6-BB6E-3EDBAF8C274E@puck.nether.net> How far? There are a lot of fixed wireless solutions in that space. Also building your own fiber an option? That distance comes into play as well... Jared Mauch On Mar 21, 2012, at 11:44 AM, Joe Maimon wrote: > Hey All, > > I have a site in Alabama that could really use some additional diversity, but apparently ATT fiber is the only game in town. > > If anybody has any options, such as fixed wireless in the 10-50mbs, please reply to me, off-list. > > Best, > > Joe From jasongurtz at npumail.com Wed Mar 21 11:06:34 2012 From: jasongurtz at npumail.com (Jason Gurtz) Date: Wed, 21 Mar 2012 12:06:34 -0400 Subject: Microsoft/Hotmail forgot to set reverse DNS pointers? Message-ID: > > noc at microsoft.com will probably understand or at least point you in the > > right direction. > > Yeah, tried that, doesn't work. Same for moc@ and soc@ *sigh* quite the frustrating company... looking in my archives I see also domains at microsoft.com which I conversed with late may last year. I will reach out to a contact and see if they can dig up anything more authoritative. ~JasonG From lesmith at ecsis.net Wed Mar 21 11:08:10 2012 From: lesmith at ecsis.net (Larry Smith) Date: Wed, 21 Mar 2012 10:08:10 -0600 Subject: Looking for some diversity in Alabama that does not involve ATT Fiber In-Reply-To: <4F69F778.4060505@ttec.com> References: <4F69F778.4060505@ttec.com> Message-ID: <201203211108.11511.lesmith@ecsis.net> On Wed March 21 2012 10:44, Joe Maimon wrote: > Hey All, > > I have a site in Alabama that could really use some additional > diversity, but apparently ATT fiber is the only game in town. > > If anybody has any options, such as fixed wireless in the 10-50mbs, > please reply to me, off-list. > Any realistic answers are probably going to require an address or physical location to be able to quote services. Know there are several Fixed wireless providers in AL, you might look at www.wispa.org as I believe they have some information as to which wisps service which areas. -- Larry Smith lesmith at ecsis.net From jra at baylink.com Wed Mar 21 11:22:01 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 21 Mar 2012 12:22:01 -0400 (EDT) Subject: Looking for some diversity in Alabama that does not involve ATT Fiber In-Reply-To: Message-ID: <32953382.7315.1332346921729.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Eric Wieling" > I don't know about AT&T, but Verizon physically removes the copper > connections when they install fiber into a building. Oddly, this is > legal. Verizon is required to open up their copper to CLECs, but not > fiber. The Verizon *regulated ILEC operating company* is required to provide equal access. FiOS comes from an unregulated subsidiary. Whether there might be some illegal collusion in the unreg subsid generating a pull order for a copper service from the regulated LEC is one thing... but why would it otherwise be illegal for the LEC to pull the copper? It *is* their copper... That's an interesting perception, and I'm curious where you came by it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From keegan.holley at sungard.com Wed Mar 21 11:25:38 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 21 Mar 2012 12:25:38 -0400 Subject: Looking for some diversity in Alabama that does not involve ATT Fiber In-Reply-To: <32953382.7315.1332346921729.JavaMail.root@benjamin.baylink.com> References: <32953382.7315.1332346921729.JavaMail.root@benjamin.baylink.com> Message-ID: I feel a topic shift coming... 2012/3/21 Jay Ashworth > ----- Original Message ----- > > From: "Eric Wieling" > > > I don't know about AT&T, but Verizon physically removes the copper > > connections when they install fiber into a building. Oddly, this is > > legal. Verizon is required to open up their copper to CLECs, but not > > fiber. > > The Verizon *regulated ILEC operating company* is required to provide equal > access. FiOS comes from an unregulated subsidiary. > > Whether there might be some illegal collusion in the unreg subsid > generating > a pull order for a copper service from the regulated LEC is one thing... > > but why would it otherwise be illegal for the LEC to pull the copper? > > It *is* their copper... > > That's an interesting perception, and I'm curious where you came by it. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 > 1274 > > > From eyeronic.design at gmail.com Wed Mar 21 11:26:38 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Wed, 21 Mar 2012 09:26:38 -0700 Subject: Looking for some diversity in Alabama that does not involve ATT Fiber In-Reply-To: <4F69F778.4060505@ttec.com> References: <4F69F778.4060505@ttec.com> Message-ID: You can get Satellite service as well. It's really expensive, for the bandwidth, but worth a look if you don't have any other options. On Wed, Mar 21, 2012 at 8:44 AM, Joe Maimon wrote: > Hey All, > > I have a site in Alabama that could really use some additional diversity, > but apparently ATT fiber is the only game in town. > > If anybody has any options, such as fixed wireless in the 10-50mbs, please > reply to me, off-list. > > Best, > > Joe > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From rspott at irongoat.net Wed Mar 21 11:38:52 2012 From: rspott at irongoat.net (D. Ryan Spott) Date: Wed, 21 Mar 2012 09:38:52 -0700 Subject: Microsoft/Hotmail forgot to set reverse DNS pointers? In-Reply-To: <4F69975C.3060001@klaver.it> References: <4F69975C.3060001@klaver.it> Message-ID: <051E28AB-287D-48A0-8E09-62CE063F79A5@irongoat.net> Mocalert at Microsoft.com Mention Sev1 in your email. ryan On Mar 21, 2012, at 1:54 AM, Michiel Klaver wrote: > Today I received some notices about Hotmail users who couldn't send e-mail > messages to various receipients due to spamfilters blocking them at the > receiving mailservers. Seems like Microsoft/Hotmail staff forgot to set some > reverse DNS pointer records: > > Diagnostic-Code: smtp;450 4.7.1 Client host rejected: cannot find your > reverse hostname, [157.55.1.150] > > (Verified this using various public DNS servers, to exclude potential local > issues) > > Anyone here who has proper contacts to give them the clue-bat? > > > -- > Michiel Klaver > IT Professional > From EWieling at nyigc.com Wed Mar 21 12:09:09 2012 From: EWieling at nyigc.com (Eric Wieling) Date: Wed, 21 Mar 2012 13:09:09 -0400 Subject: Looking for some diversity in Alabama that does not involve ATT Fiber In-Reply-To: <32953382.7315.1332346921729.JavaMail.root@benjamin.baylink.com> References: <32953382.7315.1332346921729.JavaMail.root@benjamin.baylink.com> Message-ID: Verizon, the copper wireline company, is removing service from locations EVERY TIME VZ fiber is installed in a building. This prevents other companies from providing service by leasing Verizon's copper infrastructure. If there was copper at a location then VZ would be required to resell it and nobody would be locked out. We often get customers in buildings lit by Verizon fiber service who want to change carriers. Too bad they can't anymore. Technically they can switch providers. Verizon will remove the fiber, re-install copper, and have the customer down for a week or so. If Verizon was not a wireline monopoly I might not have such an issue with this practice. Full Disclosure: I work for a CLEC. -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Wednesday, March 21, 2012 12:22 PM To: NANOG Subject: Re: Looking for some diversity in Alabama that does not involve ATT Fiber ----- Original Message ----- > From: "Eric Wieling" > I don't know about AT&T, but Verizon physically removes the copper > connections when they install fiber into a building. Oddly, this is > legal. Verizon is required to open up their copper to CLECs, but not > fiber. The Verizon *regulated ILEC operating company* is required to provide equal access. FiOS comes from an unregulated subsidiary. Whether there might be some illegal collusion in the unreg subsid generating a pull order for a copper service from the regulated LEC is one thing... but why would it otherwise be illegal for the LEC to pull the copper? It *is* their copper... That's an interesting perception, and I'm curious where you came by it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From john.yocum at fluidhosting.com Wed Mar 21 12:13:56 2012 From: john.yocum at fluidhosting.com (John T. Yocum) Date: Wed, 21 Mar 2012 10:13:56 -0700 Subject: Looking for some diversity in Alabama that does not involve ATT Fiber In-Reply-To: <4F69F778.4060505@ttec.com> References: <4F69F778.4060505@ttec.com> Message-ID: <4F6A0C54.2060207@fluidhosting.com> On 3/21/2012 8:44 AM, Joe Maimon wrote: > Hey All, > > I have a site in Alabama that could really use some additional > diversity, but apparently ATT fiber is the only game in town. > > If anybody has any options, such as fixed wireless in the 10-50mbs, > please reply to me, off-list. > > Best, > > Joe > Depending on location, perhaps Charter. They do offer transport service in some areas they service. --John From tknchris at gmail.com Wed Mar 21 12:25:41 2012 From: tknchris at gmail.com (chris) Date: Wed, 21 Mar 2012 13:25:41 -0400 Subject: Hands with Cisco Clue in/near Fort Lauderdale? Message-ID: Hello, I have a small project where I could use someone onsite who has general working cisco knowledge to help transition a site to new isp and make basic changes in a cisco router. Of course this was dropped in my lap with short notice so clients wants it done "asap" which in reality is something I'd like to get done this week. Please contact me offlist if you think this is within your realm and you are available. Thanks, chris From dgolding at ragingwire.com Wed Mar 21 12:29:17 2012 From: dgolding at ragingwire.com (Dan Golding) Date: Wed, 21 Mar 2012 10:29:17 -0700 Subject: spammers trying to "lease" IP space? In-Reply-To: References: <4F69E939.8060006@csuohio.edu> Message-ID: <1C7B96053DD7814496A0D1E71661B683029C2A9B@SMF-ENTXM-001.sac.ragingwire.net> I think this highlights a very important aspect of the paid IP address transfer process - whomever is buying had better perform some due diligence on the block. These sorts of rent-a-block-for-SPAM activities are extremely common. Most of the time, they aren't quite this blatant. - Dan > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Wednesday, March 21, 2012 11:05 AM > To: Michael Holstein > Cc: NANOG list > Subject: Re: spammers trying to "lease" IP space? > > Michael - > > We're aware of several parties out there soliciting to 'lease' > your address space, and it appears that most of them are bulk > email operations. Given that the nearly inevitable consequence > is that the blocks in question end up on various anti-spam > blacklists, I imagine that anyone would have to think very > carefully about pursuing that option... > > If you truly have more address space than you need, you can always > return it :-), list it as available on ARIN's specified transfer > listing > service (note - this may result in potential recipients calling you) > or > working with a facilitator to make it available. More info on all of > these options: https://www.arin.net/resources/transfers/index.html > and: https://www.arin.net/resources/transfer_listing/listers.html > > FYI, > /John > > John Curran > President and CEO > ARIN > > On Mar 21, 2012, at 10:44 AM, Michael Holstein wrote: > > > I know this tactic isn't exactly new .. just thought I'd pass this > along. > > > > Text below is exact with exception of our ARIN information and ranges > > (which any of you could figure out anyway). > > > > Cheers, > > > > Michael Holstein > > Cleveland State University > > > > --snip-- > > > > Description: ABC Widgets > > > > *Greetings, NOC or IP Admin at (our ARIN NetName)* > > > > ** > > > > We would like to Lease or even Purchase some of your IPv4 Ranges like > > (our/16) > > > > "Why do You want to lease our IPs?" > > > > > > > > Very Simply: Our Business is the delivery of Opted In Marketing > Email. The key > > to this business is good stewardship of IP assets to ensure > deliverability, and > > even more importantly; *Sustainability. *Many of our IP leases last > years due to > > our investment in our network before we ever even mail. As a result > it takes > > Several months before a subnet is profitable for us after recouping > our initial > > infrastructure expenses. So to Hit and Run simply does not make good > business > > sense, after all maybe if we are good to our word you will offer us > additional IPs! > > > > ** > > > > there are two core requirements in any Major League Mail Campaign ? > > > > > > > > a. _Having a solid list_ with real recipients and records to prove > their Sign up > > is vital to delivery but also to settling any complaints registered > with an ISP. > > > > b. _Using Multiple IP addresses_. If having a good list is a good > defense then > > using Multiple Static IP addresses is a proactive measure. ISPs, > Backbone > > Carriers, Software Makers, and more all use (among other means) > Algorithms to > > shape traffic across their networks and to their clients. Using an > MTA to spread > > our traffic across thousands of IP addresses from then thousands of > 'C-Blocks' > > we mitigate the footprint of our traffic originating from any one > network range. > > > > > > > > ?/It should be noted here that this email is a Request for Pricing > (RFP) and its > > recipients have in no way requested it, they have instead been > identified > > through research, and therefore this email should not be thought of > as > > characteristic of our normal mailings./ > > > > > > > > Precision Management of Texas (USA) offers on-demand solutions for > brand > > marketers and website promotion chiefly through email marketing. > Currently PM is > > seeking to expand its network capability both overseas and here in > the US with > > the addition of several points of presence (PoP) in geographically > diverse > > locations. Precision Management makes no attempt to conceal identity > or > > intentions as a show of good faith on our part that we will be good > customers > > with an eye on building a relationship beyond this installation. It > should go > > without saying that our use of your network will be totally AUP > Compliant and > > any complaints will be handled in 12 hours or less. We only mail to > Top Level > > Domain's and do no General Internet mailing. Also i want you to be > aware that we > > are an American Company with verifiable references who can attest to > how we > > conduct our email business. > > > > Description: > C:\Users\BLEAUH~1\AppData\Local\Temp\~ed_sb_i\~files\3.gif > > > > Description: Content Image InlinePM seeks to obtain as much diversity > in the > > allocated IP space as possible, however the most important thing is > the Subnets > > need to have no abuse history. > > > > We can take the IPs via GRE or BGP or other such tunneling solution > to where you > > have them announced. Alternatively we can advertise them ourselves on > our > > network, saving you the back-haul. As a third solution we can take a > server on > > your network with the following specs > > > > > > > > One Virtual (or Dedicated) Server - > > > > > > > > Dual Cores > > > > 1 GB RAM > > > > 100 GB HDD? > > > > 3 Mbps dedicated - burstable to 100 > > > > Term period minimum of 6-12 months > > > > > > > > I hope you have read this far and will seriously consider this > opportunity to > > generate additional revenue for your company. > > > > If this email has found you in error please fwd it to the right > person and cc > > me. Otherwise hit the un-sub at the bottom! > > > > > > > > Thanks, > > > > > > Edward Wootan > > Chief Technical Officer > > Precision Management LLC > > 3030 LBJ Freeway > > Dallas, TX 75234 > > If you are interested in working with a *Legitimate Marketer * > > please reply to this email or call me Direct at *(704)286-6098* > anytime. > > > > The information contained within the referenced, linked, or directed > email > > communication is intended to be a confidential communication between > the > > original sender and recipient, and is to be treated as confidential. > All works, > > ideas, or copy within are copyrighted by precision management llc., > and are not > > to be used in any manner other by which they were intended by > precision > > management llc... If you believe you have received this or any other > email in > > error, please contact cto at precision-management.info > > > > > > > > > > > > > From lyle at lcrcomputer.net Wed Mar 21 13:43:46 2012 From: lyle at lcrcomputer.net (Lyle Giese) Date: Wed, 21 Mar 2012 13:43:46 -0500 Subject: Comcast help in N Illinois Message-ID: <4F6A2162.90908@lcrcomputer.net> Have a customer that is having problems webbrowsing and need some offline assistance from someone at Comcast. First glance, it looks like a proxy/web accelerator problem at Comcast. Thanks, Lyle Giese LCR Computer Services, Inc. From jra at baylink.com Wed Mar 21 13:58:52 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 21 Mar 2012 14:58:52 -0400 (EDT) Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: Message-ID: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Eric Wieling" > Verizon, the copper wireline company, is removing service from > locations EVERY TIME VZ fiber is installed in a building. This > prevents other companies from providing service by leasing Verizon's > copper infrastructure. If there was copper at a location then VZ would > be required to resell it and nobody would be locked out. TTBOMK, whether Verizon has copper to a building has *no bearing at all* on whether a CLEC can place an order for wholesale service to that location; VZN is *required* to provide that wholesale service, at the regulated NRC and MRC rates, whether they currently happen to have the physical facilities in place or not -- are you alleging either that I've misunderstood that, or that VZN is refusing such orders *simply* because they've removed facilities to an address where FiOS has done an install? Cause either of those ought to violate the rules. > We often get customers in buildings lit by Verizon fiber service who > want to change carriers. Too bad they can't anymore. Technically they > can switch providers. Verizon will remove the fiber, re-install > copper, and have the customer down for a week or so. See above. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From mike at mtcc.com Wed Mar 21 14:16:06 2012 From: mike at mtcc.com (Michael Thomas) Date: Wed, 21 Mar 2012 12:16:06 -0700 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> Message-ID: <4F6A28F6.1030705@mtcc.com> On 03/21/2012 11:58 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Eric Wieling" >> Verizon, the copper wireline company, is removing service from >> locations EVERY TIME VZ fiber is installed in a building. This >> prevents other companies from providing service by leasing Verizon's >> copper infrastructure. If there was copper at a location then VZ would >> be required to resell it and nobody would be locked out. > TTBOMK, whether Verizon has copper to a building has *no bearing at all* > on whether a CLEC can place an order for wholesale service to that location; > VZN is *required* to provide that wholesale service, at the regulated NRC > and MRC rates, whether they currently happen to have the physical facilities > in place or not -- are you alleging either that I've misunderstood that, > or that VZN is refusing such orders *simply* because they've removed > facilities to an address where FiOS has done an install? > > Cause either of those ought to violate the rules. > So if Verizon is on the hook to support the CLEC's, why are they pulling the local loop? I'm sure it isn't free to pull it and certainly not to reinstall it, so what might be their motivation? Mike From john.yocum at fluidhosting.com Wed Mar 21 14:28:43 2012 From: john.yocum at fluidhosting.com (John T. Yocum) Date: Wed, 21 Mar 2012 12:28:43 -0700 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <4F6A28F6.1030705@mtcc.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> Message-ID: <4F6A2BEB.1000809@fluidhosting.com> On 3/21/2012 12:16 PM, Michael Thomas wrote: > On 03/21/2012 11:58 AM, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Eric Wieling" >>> Verizon, the copper wireline company, is removing service from >>> locations EVERY TIME VZ fiber is installed in a building. This >>> prevents other companies from providing service by leasing Verizon's >>> copper infrastructure. If there was copper at a location then VZ would >>> be required to resell it and nobody would be locked out. >> TTBOMK, whether Verizon has copper to a building has *no bearing at all* >> on whether a CLEC can place an order for wholesale service to that >> location; >> VZN is *required* to provide that wholesale service, at the regulated NRC >> and MRC rates, whether they currently happen to have the physical >> facilities >> in place or not -- are you alleging either that I've misunderstood that, >> or that VZN is refusing such orders *simply* because they've removed >> facilities to an address where FiOS has done an install? >> >> Cause either of those ought to violate the rules. >> > > So if Verizon is on the hook to support the CLEC's, why are they > pulling the local loop? I'm sure it isn't free to pull it and certainly > not to reinstall it, so what might be their motivation? > > Mike > VZ wants to get rid of their copper plant. It's expensive to maintain, and it requires that they sell service to competitors. Once they've disconnected their customers from it, they can just eliminate the copper plant. POTS service which ILECs provide, is basically copper service. So once the copper is gone, they are no longer in the heavily regulated POTS business. The result being, they can do whatever they want. --John From mike at mtcc.com Wed Mar 21 14:34:42 2012 From: mike at mtcc.com (Michael Thomas) Date: Wed, 21 Mar 2012 12:34:42 -0700 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <4F6A2BEB.1000809@fluidhosting.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> Message-ID: <4F6A2D52.5020903@mtcc.com> On 03/21/2012 12:28 PM, John T. Yocum wrote: > > > On 3/21/2012 12:16 PM, Michael Thomas wrote: >> On 03/21/2012 11:58 AM, Jay Ashworth wrote: >>> ----- Original Message ----- >>>> From: "Eric Wieling" >>>> Verizon, the copper wireline company, is removing service from >>>> locations EVERY TIME VZ fiber is installed in a building. This >>>> prevents other companies from providing service by leasing Verizon's >>>> copper infrastructure. If there was copper at a location then VZ would >>>> be required to resell it and nobody would be locked out. >>> TTBOMK, whether Verizon has copper to a building has *no bearing at all* >>> on whether a CLEC can place an order for wholesale service to that >>> location; >>> VZN is *required* to provide that wholesale service, at the regulated NRC >>> and MRC rates, whether they currently happen to have the physical >>> facilities >>> in place or not -- are you alleging either that I've misunderstood that, >>> or that VZN is refusing such orders *simply* because they've removed >>> facilities to an address where FiOS has done an install? >>> >>> Cause either of those ought to violate the rules. >>> >> >> So if Verizon is on the hook to support the CLEC's, why are they >> pulling the local loop? I'm sure it isn't free to pull it and certainly >> not to reinstall it, so what might be their motivation? >> >> Mike >> > > VZ wants to get rid of their copper plant. It's expensive to maintain, and it requires that they sell service to competitors. Once they've disconnected their customers from it, they can just eliminate the copper plant. POTS service which ILECs provide, is basically copper service. So once the copper is gone, they are no longer in the heavily regulated POTS business. The result being, they can do whatever they want. I can understand their motivation if what Jay writes is incorrect. My guess is that Jay may be correct technically, but VZ does it anyway because they figure they can get away with it. Mike From EWieling at nyigc.com Wed Mar 21 14:46:18 2012 From: EWieling at nyigc.com (Eric Wieling) Date: Wed, 21 Mar 2012 15:46:18 -0400 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <4F6A28F6.1030705@mtcc.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> Message-ID: -----Original Message----- From: Michael Thomas [mailto:mike at mtcc.com] Sent: Wednesday, March 21, 2012 3:16 PM To: Jay Ashworth Cc: NANOG Subject: Re: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) On 03/21/2012 11:58 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Eric Wieling" Verizon, the copper wireline >> company, is removing service from locations EVERY TIME VZ fiber is >> installed in a building. This prevents other companies from providing >> service by leasing Verizon's copper infrastructure. If there was >> copper at a location then VZ would be required to resell it and >> nobody would be locked out. > TTBOMK, whether Verizon has copper to a building has *no bearing at > all* on whether a CLEC can place an order for wholesale service to > that location; VZN is *required* to provide that wholesale service, at > the regulated NRC and MRC rates, whether they currently happen to have > the physical facilities in place or not -- are you alleging either > that I've misunderstood that, or that VZN is refusing such orders > *simply* because they've removed facilities to an address where FiOS has done an install? > > Cause either of those ought to violate the rules. > So if Verizon is on the hook to support the CLEC's, why are they pulling the local loop? I'm sure it isn't free to pull it and certainly not to reinstall it, so what might be their motivation? Mike ========================================== They are required to reinstall copper in many cases. The problem is that the FIOS is removed before the copper is reinstalled (as far as I can tell this is Policy), leading to several days, often a week or more, of downtime for the customer. They count on the fact no customer in their right mind would consider a week of downtime acceptable. From jra at baylink.com Wed Mar 21 15:00:32 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 21 Mar 2012 16:00:32 -0400 (EDT) Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <4F6A2D52.5020903@mtcc.com> Message-ID: <13694695.7491.1332360032081.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael Thomas" > > VZ wants to get rid of their copper plant. It's expensive to > > maintain, and it requires that they sell service to competitors. > > Once they've disconnected their customers from it, they can just > > eliminate the copper plant. POTS service which ILECs provide, is > > basically copper service. So once the copper is gone, they are no > > longer in the heavily regulated POTS business. The result being, > > they can do whatever they want. > > I can understand their motivation if what Jay writes is incorrect. My > guess is that Jay may be correct technically, but VZ does it anyway > because they figure they can get away with it. Someone tells me off list that indeed, if the plant isn't *there*, VZN isn't required to build it. Now, if that's the case, then they can't adminstratively block *someone else* from building it, either... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From mjwise at kapu.net Wed Mar 21 15:02:17 2012 From: mjwise at kapu.net (Michael J Wise) Date: Wed, 21 Mar 2012 13:02:17 -0700 Subject: Microsoft/Hotmail forgot to set reverse DNS pointers? In-Reply-To: <4F69975C.3060001@klaver.it> References: <4F69975C.3060001@klaver.it> Message-ID: <123E1016-7A19-4117-9570-2780BDECFC0F@kapu.net> On Mar 21, 2012, at 1:54 AM, Michiel Klaver wrote: > Diagnostic-Code: smtp;450 4.7.1 Client host rejected: cannot find your > reverse hostname, [157.55.1.150] > Anyone here who has proper contacts to give them the clue-bat? I gather the correct eyes are on the problem and it should be resolved soonest. Thanks for the heads-up. Aloha, Michael. -- "Please have your Internet License and Usenet Registration handy..." From Valdis.Kletnieks at vt.edu Wed Mar 21 15:12:24 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 21 Mar 2012 16:12:24 -0400 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: Your message of "Wed, 21 Mar 2012 16:00:32 -0400." <13694695.7491.1332360032081.JavaMail.root@benjamin.baylink.com> References: <13694695.7491.1332360032081.JavaMail.root@benjamin.baylink.com> Message-ID: <80333.1332360744@turing-police.cc.vt.edu> On Wed, 21 Mar 2012 16:00:32 -0400, Jay Ashworth said: > Someone tells me off list that indeed, if the plant isn't *there*, VZN > isn't required to build it. > > Now, if that's the case, then they can't adminstratively block *someone > else* from building it, either... Yes, but it's assymetric. VZN isn't required to build the 150 foot of copper plant from building to pole, and they can't stop a competitor from building 12,000 foot of copper plant from PoP to building. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bill at herrin.us Wed Mar 21 15:48:39 2012 From: bill at herrin.us (William Herrin) Date: Wed, 21 Mar 2012 16:48:39 -0400 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Mar 21, 2012 at 2:58 PM, Jay Ashworth wrote: >> Verizon, the copper wireline company, is removing service from >> locations EVERY TIME VZ fiber is installed in a building. This >> prevents other companies from providing service by leasing Verizon's >> copper infrastructure. If there was copper at a location then VZ would >> be required to resell it and nobody would be locked out. > > TTBOMK, whether Verizon has copper to a building has *no bearing at all* > on whether a CLEC can place an order for wholesale service to that location; > VZN is *required* to provide that wholesale service, at the regulated NRC > and MRC rates, whether they currently happen to have the physical facilities > in place or not -- are you alleging either that I've misunderstood that, > or that VZN is refusing such orders *simply* because they've removed > facilities to an address where FiOS has done an install? Hi Jay, They way I heard it, ILECs like Verizon are required to provide unbundled elements of the tariffed services anywhere they accept new orders for service which consumes those unbundled elements. They are not required to deploy new infrastructure solely to satisfy an order for an unbundled element but they may not deliver new element-consuming services without also satisfying the orders for unbundled elements. So, if they build new POTS ports at the CO, they're required to also fill the orders for unbundled POTS ports. And if they lay new copper to connect those ports to customer homes they're required to also fill the orders for unbundled pairs along the same path. Separately, an ILEC like Verizon has a universal service obligation to deliver a POTS line anywhere you order one. Without exception. The hinky part is that the FCC decided that copper pairs are an unbundled element but PONS wavelengths and Coaxial cable frequency channels are not. So, Verizon doesn't have to share access to FIOS and Comcast doesn't have to share access to the coax. As long as they deliver phone service without consuming copper pairs, universal service doesn't compel them to build any copper plant to satisfy your unbundled element order. I pine for the return of structural separation. If the cable plant provider was required to be a separate company from the services provider, we wouldn't have these shenanigans. Different shenanigans but not these. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Wed Mar 21 15:56:11 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 21 Mar 2012 16:56:11 -0400 (EDT) Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: Message-ID: <25334430.7501.1332363370994.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" The hinky part is that the FCC decided that copper pairs are an > unbundled element but PONS wavelengths and Coaxial cable frequency > channels are not. So, Verizon doesn't have to share access to FIOS and > Comcast doesn't have to share access to the coax. So why is it, then, that Vision Cable-Bright House-Advance/Newhouse Cable Partnership (which is what the payroll checks have said since about 1979) *is* required to provide competitive cablemodem access on their HFC plant? (I can get RoadRunner, their own brand, or Earthlink, or the local provider Internet Junction...) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From john.yocum at fluidhosting.com Wed Mar 21 16:00:20 2012 From: john.yocum at fluidhosting.com (John T. Yocum) Date: Wed, 21 Mar 2012 14:00:20 -0700 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <25334430.7501.1332363370994.JavaMail.root@benjamin.baylink.com> References: <25334430.7501.1332363370994.JavaMail.root@benjamin.baylink.com> Message-ID: <4F6A4164.6070706@fluidhosting.com> On 3/21/2012 1:56 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "William Herrin" >> The hinky part is that the FCC decided that copper pairs are an >> unbundled element but PONS wavelengths and Coaxial cable frequency >> channels are not. So, Verizon doesn't have to share access to FIOS and >> Comcast doesn't have to share access to the coax. > > So why is it, then, that Vision Cable-Bright House-Advance/Newhouse Cable > Partnership (which is what the payroll checks have said since about 1979) > *is* required to provide competitive cablemodem access on their HFC plant? > > (I can get RoadRunner, their own brand, or Earthlink, or the local provider > Internet Junction...) > > Cheers, > -- jra That's probably a local requirement. It's not a Federal requirement. Though, some cable companies do provide wholesale services even when not required. Look at ATT and others trying to get state-wide franchise agreements. They are trying to avoid having smaller areas tell them what to do, if they want to serve an area. --John From bill at herrin.us Wed Mar 21 16:22:47 2012 From: bill at herrin.us (William Herrin) Date: Wed, 21 Mar 2012 17:22:47 -0400 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <4F6A4164.6070706@fluidhosting.com> References: <25334430.7501.1332363370994.JavaMail.root@benjamin.baylink.com> <4F6A4164.6070706@fluidhosting.com> Message-ID: On Wed, Mar 21, 2012 at 5:00 PM, John T. Yocum wrote: > That's probably a local requirement. It's not a Federal requirement. Though, > some cable companies do provide wholesale services even when not required. Bingo. On the flip side of the equation, if you want to be an overbuilder (a third communications infrastructure provider beyond the phone and cable companies) the owner of the telephone poles is usually required by the state to sell you an "attachment." An attachment is a connection to a pole at a specific height, reserved for connecting your cables. The power company is usually the owner, so they don't get too bent out of shape about the fact that you're competing with the ILEC. The last I checked, this ran about $5/year per pole. See http://transition.fcc.gov/eb/mdrd/PoleAtt.html There are similar rules for underground conduit on public right-of-ways but I don't know what they are. On private land, underground conduit becomes a fixture of the property. So even though Verizon installed the conduit for their own cable, you as the property owner have a right to use it as you see fit. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mailinglists at expresswebsystems.com Wed Mar 21 20:23:44 2012 From: mailinglists at expresswebsystems.com (Tom Walsh - EWS) Date: Wed, 21 Mar 2012 20:23:44 -0500 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: References: <25334430.7501.1332363370994.JavaMail.root@benjamin.baylink.com> <4F6A4164.6070706@fluidhosting.com> Message-ID: <021c01cd07ca$6d399190$47acb4b0$@com> > Bingo. > > On the flip side of the equation, if you want to be an overbuilder (a > third communications infrastructure provider beyond the phone and cable > companies) the owner of the telephone poles is usually required by the > state to sell you an "attachment." An attachment is a connection to a > pole at a specific height, reserved for connecting your cables. The > power company is usually the owner, so they don't get too bent out of > shape about the fact that you're competing with the ILEC. The last I > checked, this ran about $5/year per pole. > > See http://transition.fcc.gov/eb/mdrd/PoleAtt.html When I worked for a CLEC the way that power pole attachments went, they would sell you the bottom most attachment point on the pole and you were required to move the other attachements further up the pole to make room for your attachment point (at your own expense). In our town the ILEC (GTE which morphed into Verizon) sold the power poles to the local municipality. So if you wanted attachment rights you had to negotiate with the local city manager. So be sure to check with them as well. My personal favorite was driving down the road one day watching them literally snip our fiber off the pole with a pair of cutters (it was a dark overlay we weren't using at the time, thankfully). Apparently the new city manager deemed that our agreement for power pole attachment didn't apply to him since it was negotiated under the previous city manager. He instructed the line workers to cut it down. Lawyers were involved shortly thereafter and the company went insolvent. Good times. From mysidia at gmail.com Wed Mar 21 20:47:17 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 21 Mar 2012 20:47:17 -0500 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <4F6A2BEB.1000809@fluidhosting.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> Message-ID: On Wed, Mar 21, 2012 at 2:28 PM, John T. Yocum wrote: > VZ wants to get rid of their copper plant. It's expensive to maintain, and As opposed to fiber plant which is indestructible and cheap to maintain? Well, if VZ owns the copper, if it's not being used to provide a service, and the price of copper keeps going up, it's only a matter of time before VZ should want to take their bits of unused cable back. How useful is leaving a dormant loop in place just because someone might theoretically want it someday? Seems like a waste for VZ not to reclaim it so it can be recycled/put to good use. > it requires that they sell service to competitors. Once they've disconnected > their customers from it, they can just eliminate the copper plant. POTS You sure the regulations won't eventually be updated to apply some rules to whatever POTS is being replaced with? Possibly years before they could finish eliminating their copper plant, which doesn't likely happen until the pricing allows POTS customers to get FiOS delivery installed for free as a cheaper alternative to POTS delivery. -- -JH From joe at via.net Wed Mar 21 23:23:18 2012 From: joe at via.net (joe mcguckin) Date: Wed, 21 Mar 2012 21:23:18 -0700 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> Message-ID: <745BA359-96B0-4B11-B967-D1752CB8B6B5@via.net> My understanding was that fiber loops were originally included in UNE products available to clecs but several years ago the FCC modified the regulations to remove them. So, if a service can be provisioned over a copper loop, a clec can offer it, but the ilec doesn't have to share fiber loops or services provisioned over fiber loops. I guess that explains the frenzy of fiber-to-the-curb buildout we saw with Pac Bell in the early 2000's. I don't think ATT/PacBell has been ripping out copper, but much of it in the SF Bay area is a rotting mess and ATT hasn't been spending much money to maintain it. Now that the DSL clecs are all but extinct, the pace of fiber buildout to the end-user has slowed down considerably. Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax On Mar 21, 2012, at 11:58 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Eric Wieling" > >> Verizon, the copper wireline company, is removing service from >> locations EVERY TIME VZ fiber is installed in a building. This >> prevents other companies from providing service by leasing Verizon's >> copper infrastructure. If there was copper at a location then VZ would >> be required to resell it and nobody would be locked out. > > TTBOMK, whether Verizon has copper to a building has *no bearing at all* > on whether a CLEC can place an order for wholesale service to that location; > VZN is *required* to provide that wholesale service, at the regulated NRC > and MRC rates, whether they currently happen to have the physical facilities > in place or not -- are you alleging either that I've misunderstood that, > or that VZN is refusing such orders *simply* because they've removed > facilities to an address where FiOS has done an install? > > Cause either of those ought to violate the rules. > >> We often get customers in buildings lit by Verizon fiber service who >> want to change carriers. Too bad they can't anymore. Technically they >> can switch providers. Verizon will remove the fiber, re-install >> copper, and have the customer down for a week or so. > > See above. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From ops.lists at gmail.com Wed Mar 21 23:41:12 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 22 Mar 2012 10:11:12 +0530 Subject: Microsoft/Hotmail forgot to set reverse DNS pointers? In-Reply-To: <123E1016-7A19-4117-9570-2780BDECFC0F@kapu.net> References: <4F69975C.3060001@klaver.it> <123E1016-7A19-4117-9570-2780BDECFC0F@kapu.net> Message-ID: On Thu, Mar 22, 2012 at 1:32 AM, Michael J Wise wrote: > > I gather the correct eyes are on the problem and it should be resolved > soonest. > Thanks for the heads-up. Seems fixed ;; ANSWER SECTION: 150.1.55.157.in-addr.arpa. 3600 IN PTR dub0-omc2-s11.dub0.hotmail.com. forgetting to set the rDNS was a dub*mis*step I guess .. -- Suresh Ramasubramanian (ops.lists at gmail.com) From scubacuda at gmail.com Thu Mar 22 03:01:38 2012 From: scubacuda at gmail.com (Rogelio) Date: Thu, 22 Mar 2012 15:01:38 +0700 Subject: Huawei WiFi = Ruckus OEM? Message-ID: Is it just me? Or do these Huawei wireless APs look like Ruckus APs? http://enterprise.huawei.com/ilink/enenterprise/support/documents/base-network/wirleless-area/index.htm Looks specifically at the A603DE and WA653DE. Even the GUIs look very similar. -- Also on LinkedIn? Feel free to connect if you too are an open networker: scubacuda at gmail.com From rs at seastrom.com Thu Mar 22 09:18:55 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 22 Mar 2012 10:18:55 -0400 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: (Jimmy Hess's message of "Wed, 21 Mar 2012 20:47:17 -0500") References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> Message-ID: <86haxgu3ao.fsf@seastrom.com> Jimmy Hess writes: > Seems like a waste for VZ not to reclaim it so it can be > recycled/put to good use. To put some numbers with this statement (which I agree with btw): OSP cable is commonly available composed of 19 AWG, 22 AWG, 24 AWG, and 26 AWG pairs. 19 and 26 are outliers; 19 is for low pair count cables going extra long distances and 26 is only good for quite short distances (CO/SLC to customer) but Superior Essex makes a 3000 pair cable in #26 (22 and 24 max out at 900 and 1800 pair, at least on the spec sheet I have handy). Most of the cable out there is 22 or 24. Solid #22 and #24 (uninsulated) copper wire weighs 1.95 and 1.23 pounds per 1000 feet respectively. That's without the insulation, and only one wire, not a pair. I found scrap pricing for "telco" (obviously the contaminant ratios out there are different for different types of copper) at $1.20/pound, which may or may not be current, but if you figure a single pair of #24 is probably around 4 pounds per 1000 feet scrap weight... if an average loop is, say, 5000 feet, you can see where there is substantial incentive to recycle all the 600 pair that you have lying around. -r From bill at herrin.us Thu Mar 22 09:53:10 2012 From: bill at herrin.us (William Herrin) Date: Thu, 22 Mar 2012 10:53:10 -0400 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <86haxgu3ao.fsf@seastrom.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <86haxgu3ao.fsf@seastrom.com> Message-ID: On Thu, Mar 22, 2012 at 10:18 AM, Robert E. Seastrom wrote: > Jimmy Hess writes: > >> Seems like a waste for VZ not to reclaim it so it can be >> recycled/put to good use. > > To put some numbers with this statement (which I agree with btw): > > OSP cable is commonly available composed of 19 AWG, 22 AWG, 24 AWG, > and 26 AWG pairs. ?19 and 26 are outliers; 19 is for low pair count > cables going extra long distances and 26 is only good for quite short > distances (CO/SLC to customer) but Superior Essex makes a 3000 pair > cable in #26 (22 and 24 max out at 900 and 1800 pair, at least on the > spec sheet I have handy). > > Most of the cable out there is 22 or 24. ?Solid #22 and #24 > (uninsulated) copper wire weighs 1.95 and 1.23 pounds per 1000 feet > respectively. ?That's without the insulation, and only one wire, not a > pair. > > I found scrap pricing for "telco" (obviously the contaminant ratios > out there are different for different types of copper) at $1.20/pound, > which may or may not be current, but if you figure a single pair of > #24 is probably around 4 pounds per 1000 feet scrap weight... ?if an > average loop is, say, 5000 feet, you can see where there is > substantial incentive to recycle all the 600 pair that you have lying > around. Hi Robert, That depends on the cost of recovering it. We're not talking about salvage operators pulling cable, we're talking about highly trained [sic] Verizon installers. The last 4 pairs in use on that 3000 count cable will tend to linger a long, long time before you can go remove it. Mostly you'll recover short runs of low-count cable like the fifty-foot two and six pair cables from the street to the house: maybe $3 in scrap. How many dollars worth of time will the installer bill Verizon for recovering it? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Thu Mar 22 09:53:52 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 22 Mar 2012 10:53:52 -0400 (EDT) Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <86haxgu3ao.fsf@seastrom.com> Message-ID: <30922754.7661.1332428032331.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert E. Seastrom" > I found scrap pricing for "telco" (obviously the contaminant ratios > out there are different for different types of copper) at $1.20/pound, > which may or may not be current, but if you figure a single pair of > #24 is probably around 4 pounds per 1000 feet scrap weight... if an > average loop is, say, 5000 feet, you can see where there is > substantial incentive to recycle all the 600 pair that you have lying > around. That's relatively current. I recycled about 105 ft of 25pr I pulled out on a cabling job 3 or 4 months ago, and I think I got $130 for it. But remember: much to most telco trunk cable is icky-pic, and direct-burial; both of those change the effectiveness equation *markedly*. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From tknchris at gmail.com Thu Mar 22 10:05:02 2012 From: tknchris at gmail.com (chris) Date: Thu, 22 Mar 2012 11:05:02 -0400 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> Message-ID: I'm all for VZ being able to reclaim it as long as they open their fiber which I don't see happening unless its by force via government. At the end of the day there needs to be the ability to allow competitors in so of course they shouldnt be allowed to rip out the regulated part and replace it with a unregulated one. Also, I think Z doesnt see any problem at the moment because they probably make more money with the closed fiber network than they ever would shutting down/recycling copper On Wed, Mar 21, 2012 at 9:47 PM, Jimmy Hess wrote: > On Wed, Mar 21, 2012 at 2:28 PM, John T. Yocum > wrote: > > VZ wants to get rid of their copper plant. It's expensive to maintain, > and > > As opposed to fiber plant which is indestructible and cheap to maintain? > > > Well, if VZ owns the copper, if it's not being used to provide a > service, and the price of > copper keeps going up, it's only a matter of time before VZ should > want to take their bits of unused cable back. How useful is leaving > a dormant loop in place just because someone might theoretically want > it someday? > > Seems like a waste for VZ not to reclaim it so it can be recycled/put > to good use. > > > it requires that they sell service to competitors. Once they've > disconnected > > their customers from it, they can just eliminate the copper plant. POTS > > You sure the regulations won't eventually be updated to apply some > rules to whatever POTS is being replaced with? Possibly years > before they could finish eliminating their copper plant, which > doesn't > likely happen until the pricing allows POTS customers to get FiOS > delivery installed for free as a > cheaper alternative to POTS delivery. > > > -- > -JH > > From jamie at photon.com Thu Mar 22 11:18:59 2012 From: jamie at photon.com (Jamie Bowden) Date: Thu, 22 Mar 2012 16:18:59 +0000 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <86haxgu3ao.fsf@seastrom.com> Message-ID: <465966A5F5B867419F604CD3E604C1E5A40348@PRA-ESS-MAIL.ess.us.ray.com> > From: William Herrin [mailto:bill at herrin.us] > On Thu, Mar 22, 2012 at 10:18 AM, Robert E. Seastrom > wrote: > > Jimmy Hess writes: > > > >> Seems like a waste for VZ not to reclaim it so it can be > >> recycled/put to good use. > > > > To put some numbers with this statement (which I agree with btw): > > > > OSP cable is commonly available composed of 19 AWG, 22 AWG, 24 AWG, > > and 26 AWG pairs. ?19 and 26 are outliers; 19 is for low pair count > > cables going extra long distances and 26 is only good for quite short > > distances (CO/SLC to customer) but Superior Essex makes a 3000 pair > > cable in #26 (22 and 24 max out at 900 and 1800 pair, at least on the > > spec sheet I have handy). > > > > Most of the cable out there is 22 or 24. ?Solid #22 and #24 > > (uninsulated) copper wire weighs 1.95 and 1.23 pounds per 1000 feet > > respectively. ?That's without the insulation, and only one wire, not > a > > pair. > > > > I found scrap pricing for "telco" (obviously the contaminant ratios > > out there are different for different types of copper) at > $1.20/pound, > > which may or may not be current, but if you figure a single pair of > > #24 is probably around 4 pounds per 1000 feet scrap weight... ?if an > > average loop is, say, 5000 feet, you can see where there is > > substantial incentive to recycle all the 600 pair that you have lying > > around. > > Hi Robert, > > That depends on the cost of recovering it. We're not talking about > salvage operators pulling cable, we're talking about highly trained > [sic] Verizon installers. > > The last 4 pairs in use on that 3000 count cable will tend to linger a > long, long time before you can go remove it. Mostly you'll recover > short runs of low-count cable like the fifty-foot two and six pair > cables from the street to the house: maybe $3 in scrap. How many > dollars worth of time will the installer bill Verizon for recovering > it? If it means they're shutting down the CLECs in the process? I suspect it's worth quite a bit of installer billable time... Jamie From jared at puck.nether.net Thu Mar 22 11:26:50 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 22 Mar 2012 12:26:50 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> Message-ID: <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> On Mar 22, 2012, at 11:05 AM, chris wrote: > I'm all for VZ being able to reclaim it as long as they open their fiber > which I don't see happening unless its by force via government. At the end > of the day there needs to be the ability to allow competitors in so of > course they shouldnt be allowed to rip out the regulated part and replace > it with a unregulated one. I think this partly captures the incentive case here, but there is also a larger one at play. Over the years the copper infrastructure was installed and extended through various incentive programs. You can see the modern-day reflection of that in the RUS (used to manage rural electrification act, part of USDA) and NTIA (Department of Commerce). The barriers to entry are significant for a new player in the marketplace. The cost is putting the cabling in the ground vs the cost of the cable itself. One can easily pick up hardware for $250 to light a single strand of 9/125 SM fiber @ 10km for a 1Gb/s ethernet link. That's low enough you could likely get a consumer to buy the hardware. The real cost is the installation per strand foot/mile. In the past this has been subsidized for copper plant. There is no reason in my mind that the fiber plant should be treated differently from this standpoint. I can find fiber optic cabling for $0.25/ft. The problem here is a multi-dimensional one that I've seen play out in a few markets: Verizon selling assets to Fairpoint (NH, ME, VT). These are high cost areas due to low-density population. For the sale to go through, Fairpoint had to agree to build into these higher cost areas. The result was bankruptcy for Fairpoint. Verizon sold assets in Michigan (and other states) to Frontier. I've not tracked this one as closely, but I suspect the economics of this are fairly complex. I've also spoken to some small ISPs and their general cost of building fiber to the home tends to be $2500/subscriber in upfront capital. This covers just the installation cost. Due to years of subsidy and regulation, people are unwilling to pay this amount to install a telecommunications service whereas a new home requiring a connection to the water, sewers, natural gas or electric grid may pay $10k or more to connect. Many people wouldn't think of buying a home without electric service, but without modern telecommunication service? I've seen this play out after the fact with friends asking how to get service. Satellite, Fixed wireless or just cellular data quickly become their fallbacks. The demand is there, the challenge becomes recovering the build cost. It is my firm belief that without a regulatory regime it will not be feasible to connect many communities robustly to modern communications infrastructure. This could clearly change if the carriers involved see fit to replace this infrastructure, but with their current debt loads, I think it will be challenging to say the least. Taking a look at Verizon - Their most recent quarterly balance sheet shows: http://finance.yahoo.com/q/bs?s=VZ Assets: 230.461 Billion USD Liabilities: 194.491 Billion USD. This is not a lot of money, considering they have growing liabilities on a quarterly basis as part of their debt load (Long-term debt of $50 Billion). A large fiber build would easily cost a few billion dollars and have lots of regulatory barriers. In my county it costs $200 to go over or under any public road (just for the permit). This starts to add up quickly. I do think we need a new last-mile regime in many areas, be it more "fair" access similar to pole attach fees or the removal of local barriers to build this infrastructure. Some school and other governments here in Michigan would love to sell/lease their excess fiber capacity to the private sector, but are worried about turning a profit when it was built with taxpayer funds and problems associated with that. I'd like to see these barriers removed. If it's there, lets make it of value. If the school system turns a profit on their enterprise, that's fine, it can lower the tax burden elsewhere. Me? I'd be willing to pay $2500 to have Fiber built to my home. I might even pay more. At this point, my research continues on building the fiber and arranging my own easements for where to place it. I suspect you just need a few geeks that are willing to part with some extra $ for fiber bragging rights and one can build it. - Jared From xiangy08 at csnet1.cs.tsinghua.edu.cn Thu Mar 22 11:45:47 2012 From: xiangy08 at csnet1.cs.tsinghua.edu.cn (Yang Xiang) Date: Fri, 23 Mar 2012 00:45:47 +0800 Subject: FYI: [Argus] 12.231.155/24 is 'hijacked' by anomalous origin 'AS13490' Message-ID: Hi, Just now we found a hijacking, as shown below. Is it a real prefix hijacking, or a false alarm made by us? Hope someone in this list, maybe the admin of those ASes listed below, can give me a reply :-) The feedback can help us improve Argus and provide more valuable information. BRs. ---------- Forwarded message ---------- From: argus-alarm Date: 2012/3/23 Subject: [Argus] 12.231.155/24 is 'hijacked' by anomalous origin 'AS13490' To: argus Prefix hijacking alarm: Start Time(UTC): Mar-22-2012 16:29:07 IP Prefix: 12.231.155/24 Origin AS change: AS7018 -> AS13490 Details: http://argus.csnet1.cs.tsinghua.edu.cn/fingerprints/207340/ _______________________________________________ Argus mailing list Argus at csnet1.cs.tsinghua.edu.cn http://csnet1.cs.tsinghua.edu.cn/mailman/listinfo/argus -- _________________________________________ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn From andrea at ripe.net Thu Mar 22 11:48:31 2012 From: andrea at ripe.net (Andrea Cima) Date: Thu, 22 Mar 2012 17:48:31 +0100 Subject: New AS Number Blocks allocated to the RIPE NCC Message-ID: <4F6B57DF.9020600@ripe.net> Dear Colleagues, The RIPE NCC has received the following AS Number Blocks from the IANA in March 2012. 59392-60415 60416-61439 198656-199679 You may want to update your records accordingly. Best regards, Andrea Cima Registration Services Manager RIPE NCC From tknchris at gmail.com Thu Mar 22 12:12:58 2012 From: tknchris at gmail.com (chris) Date: Thu, 22 Mar 2012 13:12:58 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: On Thu, Mar 22, 2012 at 12:26 PM, Jared Mauch wrote: > > On Mar 22, 2012, at 11:05 AM, chris wrote: > > > I'm all for VZ being able to reclaim it as long as they open their fiber > > which I don't see happening unless its by force via government. At the > end > > of the day there needs to be the ability to allow competitors in so of > > course they shouldnt be allowed to rip out the regulated part and replace > > it with a unregulated one. > > I think this partly captures the incentive case here, but there is also a > larger one at play. Over the years the copper infrastructure was installed > and extended through various incentive programs. You can see the > modern-day reflection of that in the RUS (used to manage rural > electrification act, part of USDA) and NTIA (Department of Commerce). > > The barriers to entry are significant for a new player in the marketplace. > The cost is putting the cabling in the ground vs the cost of the cable > itself. One can easily pick up hardware for $250 to light a single strand > of 9/125 SM fiber @ 10km for a 1Gb/s ethernet link. That's low enough you > could likely get a consumer to buy the hardware. The real cost is the > installation per strand foot/mile. > > In the past this has been subsidized for copper plant. There is no reason > in my mind that the fiber plant should be treated differently from this > standpoint. I can find fiber optic cabling for $0.25/ft. The problem here > is a multi-dimensional one that I've seen play out in a few markets: > > Verizon selling assets to Fairpoint (NH, ME, VT). These are high cost > areas due to low-density population. For the sale to go through, Fairpoint > had to agree to build into these higher cost areas. The result was > bankruptcy for Fairpoint. > > Verizon sold assets in Michigan (and other states) to Frontier. I've not > tracked this one as closely, but I suspect the economics of this are fairly > complex. > > I've also spoken to some small ISPs and their general cost of building > fiber to the home tends to be $2500/subscriber in upfront capital. This > covers just the installation cost. Due to years of subsidy and regulation, > people are unwilling to pay this amount to install a telecommunications > service whereas a new home requiring a connection to the water, sewers, > natural gas or electric grid may pay $10k or more to connect. Many people > wouldn't think of buying a home without electric service, but without > modern telecommunication service? I've seen this play out after the fact > with friends asking how to get service. Satellite, Fixed wireless or just > cellular data quickly become their fallbacks. The demand is there, the > challenge becomes recovering the build cost. > > It is my firm belief that without a regulatory regime it will not be > feasible to connect many communities robustly to modern communications > infrastructure. This could clearly change if the carriers involved see fit > to replace this infrastructure, but with their current debt loads, I think > it will be challenging to say the least. > > Taking a look at Verizon - Their most recent quarterly balance sheet shows: > > http://finance.yahoo.com/q/bs?s=VZ > > Assets: 230.461 Billion USD > Liabilities: 194.491 Billion USD. > > This is not a lot of money, considering they have growing liabilities on a > quarterly basis as part of their debt load (Long-term debt of $50 Billion). > > A large fiber build would easily cost a few billion dollars and have lots > of regulatory barriers. In my county it costs $200 to go over or under any > public road (just for the permit). This starts to add up quickly. > > I do think we need a new last-mile regime in many areas, be it more "fair" > access similar to pole attach fees or the removal of local barriers to > build this infrastructure. > > Some school and other governments here in Michigan would love to > sell/lease their excess fiber capacity to the private sector, but are > worried about turning a profit when it was built with taxpayer funds and > problems associated with that. I'd like to see these barriers removed. If > it's there, lets make it of value. If the school system turns a profit on > their enterprise, that's fine, it can lower the tax burden elsewhere. > > Me? I'd be willing to pay $2500 to have Fiber built to my home. I might > even pay more. At this point, my research continues on building the fiber > and arranging my own easements for where to place it. I suspect you just > need a few geeks that are willing to part with some extra $ for fiber > bragging rights and one can build it. > > - Jared I agree that barrier of entry is what is stifling competition. Hardware, cabling, even software is relatively inexpensive. Opening things up to competition is what drives innovation in the field. I think a good example of this is in the datacenter space. You usually have the same group of suspects who provide internet access for the home/business delivering service there at a fraction of what their retail price is. I know some people will say its a different scenario and less complexity, but the competition helps significantly. Do you think Verizon can sell ATM circuits with ridiculously long contracts like they're used to? Hell no. If I call up the carriers who service my local datacenter and they know they have competitors who can deliver the same service they will price accordingly. There's a unique sequence of events in each market but its all similar, and all in all Verizon isnt the only one at fault. We need new regulation that puts things back into perspective. Why is it that the big companies are controlling what happens? From jared at puck.nether.net Thu Mar 22 12:17:33 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 22 Mar 2012 13:17:33 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: <69ECC0E5-29E9-431E-8AD3-9798B3EF0750@puck.nether.net> On Mar 22, 2012, at 1:12 PM, chris wrote: > Why is it that the big companies are controlling what happens? They have used the past decades or century to establish these assets. - Jared From keegan.holley at sungard.com Thu Mar 22 12:22:58 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 22 Mar 2012 13:22:58 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: 2012/3/22 Jared Mauch > > On Mar 22, 2012, at 11:05 AM, chris wrote: > > > I'm all for VZ being able to reclaim it as long as they open their fiber > > which I don't see happening unless its by force via government. At the > end > > of the day there needs to be the ability to allow competitors in so of > > course they shouldnt be allowed to rip out the regulated part and replace > > it with a unregulated one. > Maybe I'm missing something, but how exactly does one share fiber? Isn't it usually a closed loop between DWDM or Sonet nodes? It doesn't seem fair to force the incumbents to start handing out lambdas and timeslots to their competitors on the business side. I guess passive optical can be shared depending on the details of the network, but that would still be much different than sharing copper pairs. From keegan.holley at sungard.com Thu Mar 22 12:24:11 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 22 Mar 2012 13:24:11 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <69ECC0E5-29E9-431E-8AD3-9798B3EF0750@puck.nether.net> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <69ECC0E5-29E9-431E-8AD3-9798B3EF0750@puck.nether.net> Message-ID: 2012/3/22 Jared Mauch > > On Mar 22, 2012, at 1:12 PM, chris wrote: > > > Why is it that the big companies are controlling what happens? > > They have used the past decades or century to establish these assets. > > What is there that's worth having that isn't controlled by a big company of some sort? From jared at puck.nether.net Thu Mar 22 12:31:47 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 22 Mar 2012 13:31:47 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: On Mar 22, 2012, at 1:22 PM, Keegan Holley wrote: > > 2012/3/22 Jared Mauch > > On Mar 22, 2012, at 11:05 AM, chris wrote: > > > I'm all for VZ being able to reclaim it as long as they open their fiber > > which I don't see happening unless its by force via government. At the end > > of the day there needs to be the ability to allow competitors in so of > > course they shouldnt be allowed to rip out the regulated part and replace > > it with a unregulated one. > > > Maybe I'm missing something, but how exactly does one share fiber? Isn't it usually a closed loop between DWDM or Sonet nodes? It doesn't seem fair to force the incumbents to start handing out lambdas and timeslots to their competitors on the business side. I guess passive optical can be shared depending on the details of the network, but that would still be much different than sharing copper pairs. You agree on a price per distance (e.g.: mile/foot/whatnot). Lets say the cable costs $25k to install for the distance of 5000 feet. That cable has 144 strands. You need access to one strand. If you install it yourself, it will cost you $25k. If you share the pro-rata cost, it comes out around $174 for that strand. Lets say they mark it up 10x (profit, unused strands), would you pay $1740 for access? What does emergency restoration cost? WDM/DWDM add cost to that strand, but also increase the capacity based on what your overall lit capacity may be on a route. There are various cwdm/dwdm systems that range the usual 10/20/40/80/100km ranges. You obviously need to do the math yourselves on this. You may find the ROI is better than you think... - Jared From john.kreno at gmail.com Thu Mar 22 12:31:06 2012 From: john.kreno at gmail.com (John Kreno) Date: Thu, 22 Mar 2012 10:31:06 -0700 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) Message-ID: This sharing can be done at a layer-3 or as you say at the time slot level or lambda level. It's no different than what is happening with the copper already. It's not like they have to give it away for free. They just have to offer it to other carriers at cost. This will hopefully provide more of a competitive market. But I don't see Verizon giving into it, nor Comcast or any other provider that has fiber. Verizon campaigned hard to have fiber removed from the equal access legalize so like most of these other large companies, they don't want to share their new toy with the other children. -John Keegan Holley wrote: >2012/3/22 Jared Mauch > >> >> On Mar 22, 2012, at 11:05 AM, chris wrote: >> >> > I'm all for VZ being able to reclaim it as long as they open their fiber >> > which I don't see happening unless its by force via government. At the >> end >> > of the day there needs to be the ability to allow competitors in so of >> > course they shouldnt be allowed to rip out the regulated part and replace >> > it with a unregulated one. >> > > >Maybe I'm missing something, but how exactly does one share fiber? Isn't >it usually a closed loop between DWDM or Sonet nodes? It doesn't seem fair >to force the incumbents to start handing out lambdas and timeslots to their >competitors on the business side. I guess passive optical can be shared >depending on the details of the network, but that would still be much >different than sharing copper pairs. From jared at puck.nether.net Thu Mar 22 12:36:27 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 22 Mar 2012 13:36:27 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <69ECC0E5-29E9-431E-8AD3-9798B3EF0750@puck.nether.net> Message-ID: <3D415E37-3AA3-4DD5-86F7-BC157AB2D087@puck.nether.net> On Mar 22, 2012, at 1:24 PM, Keegan Holley wrote: > What is there that's worth having that isn't controlled by a big company of some sort? This is done in some places. eg: http://www.allband.org/ Some states place barriers to establishing a cooperative. Call your state PUC, there are good people there who will tell you about the unserved areas of the state. Your universal service fund tax has not made PSTN available to 100% of the US. The Allband service area just got the telephony services the rest of the country has enjoyed for decades. There are also many independent phone companies nationwide. Some are comfortable in their areas, others are pushing to expand. - Jared From keegan.holley at sungard.com Thu Mar 22 12:40:40 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 22 Mar 2012 13:40:40 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: 2012/3/22 Jared Mauch > > On Mar 22, 2012, at 1:22 PM, Keegan Holley wrote: > > > > > 2012/3/22 Jared Mauch > > > > On Mar 22, 2012, at 11:05 AM, chris wrote: > > > > > I'm all for VZ being able to reclaim it as long as they open their > fiber > > > which I don't see happening unless its by force via government. At the > end > > > of the day there needs to be the ability to allow competitors in so of > > > course they shouldnt be allowed to rip out the regulated part and > replace > > > it with a unregulated one. > > > > > > Maybe I'm missing something, but how exactly does one share fiber? > Isn't it usually a closed loop between DWDM or Sonet nodes? It doesn't > seem fair to force the incumbents to start handing out lambdas and > timeslots to their competitors on the business side. I guess passive > optical can be shared depending on the details of the network, but that > would still be much different than sharing copper pairs. > > You agree on a price per distance (e.g.: mile/foot/whatnot). > > Lets say the cable costs $25k to install for the distance of 5000 feet. > > That cable has 144 strands. > > You need access to one strand. If you install it yourself, it will cost > you $25k. If you share the pro-rata cost, it comes out around $174 for > that strand. Lets say they mark it up 10x (profit, unused strands), would > you pay $1740 for access? What does emergency restoration cost? > I agree, but what if it's not as simple as a bunch of strands in a conduit. What if the plant is part of some sort of multiplexed network or GPON solution. That's alot harder to share with another carrier . But yes if it's simple stands of glass not plugged into anything in particular it can be shared just like copper. Alot of the fiber plant out there isn't used this way though. > > WDM/DWDM add cost to that strand, but also increase the capacity based on > what your overall lit capacity may be on a route. There are various > cwdm/dwdm systems that range the usual 10/20/40/80/100km ranges. You > obviously need to do the math yourselves on this. You may find the ROI is > better than you think... > This is different than sharing cables. Any long distance carrier is still free to purchase service from any LEC. The term "sharing fiber" seemed to imply that it's freely transferable from one company to the next. It largely isn't though, which is why I think the FCC hasn't touched it yet. From keegan.holley at sungard.com Thu Mar 22 12:44:19 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 22 Mar 2012 13:44:19 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: Message-ID: If it's done on a box owned by the incumbent then sharing has evolved into giving away free service to competitors. It's different when copper pairs into a house could be latched onto anyone's switch. Once you start requiring a carrier to give away capacity in it's network that's different. Also, diversity/redundancy becomes dodgy at this point. Not that the billions of dollars they are making didn't come into the discussion, but it seems like its more complicated to share fiber access than it was to share copper pairs. 2012/3/22 John Kreno > This sharing can be done at a layer-3 or as you say at the time slot level > or lambda level. It's no different than what is happening with the copper > already. It's not like they have to give it away for free. They just have > to offer it to other carriers at cost. This will hopefully provide more of > a competitive market. But I don't see Verizon giving into it, nor Comcast > or any other provider that has fiber. Verizon campaigned hard to have fiber > removed from the equal access legalize so like most of these other large > companies, they don't want to share their new toy with the other children. > > -John > > > Keegan Holley wrote: > > >2012/3/22 Jared Mauch > > > >> > >> On Mar 22, 2012, at 11:05 AM, chris wrote: > >> > >> > I'm all for VZ being able to reclaim it as long as they open their > fiber > >> > which I don't see happening unless its by force via government. At the > >> end > >> > of the day there needs to be the ability to allow competitors in so of > >> > course they shouldnt be allowed to rip out the regulated part and > replace > >> > it with a unregulated one. > >> > > > > > >Maybe I'm missing something, but how exactly does one share fiber? Isn't > >it usually a closed loop between DWDM or Sonet nodes? It doesn't seem > fair > >to force the incumbents to start handing out lambdas and timeslots to > their > >competitors on the business side. I guess passive optical can be shared > >depending on the details of the network, but that would still be much > >different than sharing copper pairs. > From EWieling at nyigc.com Thu Mar 22 12:46:53 2012 From: EWieling at nyigc.com (Eric Wieling) Date: Thu, 22 Mar 2012 13:46:53 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: -----Original Message----- From: Keegan Holley [mailto:keegan.holley at sungard.com] Sent: Thursday, March 22, 2012 1:41 PM To: Jared Mauch Cc: nanog at nanog.org Subject: Re: last mile, regulatory incentives, etc (was: att fiber, et al) 2012/3/22 Jared Mauch > > On Mar 22, 2012, at 1:22 PM, Keegan Holley wrote: > > > > > 2012/3/22 Jared Mauch > > > > On Mar 22, 2012, at 11:05 AM, chris wrote: > > > > > I'm all for VZ being able to reclaim it as long as they open their > fiber > > > which I don't see happening unless its by force via government. At > > > the > end > > > of the day there needs to be the ability to allow competitors in > > > so of course they shouldnt be allowed to rip out the regulated > > > part and > replace > > > it with a unregulated one. > > > > > > Maybe I'm missing something, but how exactly does one share fiber? > Isn't it usually a closed loop between DWDM or Sonet nodes? It > doesn't seem fair to force the incumbents to start handing out lambdas > and timeslots to their competitors on the business side. I guess > passive optical can be shared depending on the details of the network, > but that would still be much different than sharing copper pairs. > > You agree on a price per distance (e.g.: mile/foot/whatnot). > > Lets say the cable costs $25k to install for the distance of 5000 feet. > > That cable has 144 strands. > > You need access to one strand. If you install it yourself, it will > cost you $25k. If you share the pro-rata cost, it comes out around > $174 for that strand. Lets say they mark it up 10x (profit, unused > strands), would you pay $1740 for access? What does emergency restoration cost? > I agree, but what if it's not as simple as a bunch of strands in a conduit. What if the plant is part of some sort of multiplexed network or GPON solution. That's alot harder to share with another carrier . But yes if it's simple stands of glass not plugged into anything in particular it can be shared just like copper. Alot of the fiber plant out there isn't used this way though. > > WDM/DWDM add cost to that strand, but also increase the capacity based > on what your overall lit capacity may be on a route. There are > various cwdm/dwdm systems that range the usual 10/20/40/80/100km > ranges. You obviously need to do the math yourselves on this. You > may find the ROI is better than you think... > This is different than sharing cables. Any long distance carrier is still free to purchase service from any LEC. The term "sharing fiber" seemed to imply that it's freely transferable from one company to the next. It largely isn't though, which is why I think the FCC hasn't touched it yet. ---------------------------------------------------------------------- Verizon has no problem delivering service via fiber with a DSX-1 or Ethernet handoff. We simply want that service backhauled to us just like all our customers with service over copper with DSX-1 or Ethernet handoff. From jra at baylink.com Thu Mar 22 12:51:32 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 22 Mar 2012 13:51:32 -0400 (EDT) Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: Message-ID: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Kreno" > This sharing can be done at a layer-3 or as you say at the time slot > level or lambda level. It's no different than what is happening with > the copper already. It's not like they have to give it away for free. > They just have to offer it to other carriers at cost. This will > hopefully provide more of a competitive market. But I don't see > Verizon giving into it, nor Comcast or any other provider that has > fiber. Verizon campaigned hard to have fiber removed from the equal > access legalize so like most of these other large companies, they > don't want to share their new toy with the other children. Oh, it's *much* worse than that, John. The *right*, long term solution to all of these problems is for municipalities to do the fiber build, properly engineered, and even subbed out to a contractor to build and possibly operate... offering *only* layer 1 service at wholesale. Any comer can light up each city's pop, and offer retail service over the FTTH fiber to that customer at whatever rate they like, and the city itself doesn't offer layer 2 or 3 service at all. High-speed optical data *is* the next natural monopoly, after power and water/sewer delivery, and it's time to just get over it and do it right. As you might imagine, this environment -- one where the LEC doesn't own the physical plant -- scares the ever-lovin' daylights out of Verizon (among others), so much so that they *have gotten it made illegal* in several states, and they're lobbying to expand that footprint. See, among other sites: http://www.muninetworks.org/ As you might imagine, I am a fairly strong proponent of muni layer 1 -- or even layer 2, where the municipality supplies (matching) ONTs, and services have to fit over GigE -- fiber delivery of high-speed data service. I believe Google agrees with me. :-) Cheers, -- jra Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From morrowc.lists at gmail.com Thu Mar 22 13:07:34 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 22 Mar 2012 14:07:34 -0400 Subject: FYI: [Argus] 12.231.155/24 is 'hijacked' by anomalous origin 'AS13490' In-Reply-To: References: Message-ID: On Thu, Mar 22, 2012 at 12:45 PM, Yang Xiang wrote: > Hi, > > Just now we found a hijacking, as shown below. > Is it a real prefix hijacking, or a false alarm made by us? > > Hope someone in this list, maybe the admin of those ASes listed below, can > give me a reply :-) > The feedback can help us improve Argus and provide more valuable > information. FIRST SOLAR LLC FIRST-SO23-155 (NET-12-231-155-0-1) 12.231.155.0 - 12.231.155.255 ASNumber: 13490 ASName: BUCKEYECABLEVISION ASHandle: AS13490 OrgName: Buckeye Cablevision, Inc. OrgId: BUCKEY-4 Address: 5566 Southwyck Blvd. City: Toledo StateProv: OH OrgTechHandle: RLK3-ARIN OrgTechName: Karpinski, Rebecca Lynn OrgTechPhone: +1-419-724-3818 OrgTechEmail: rkarpinski at bex.net OrgTechRef: http://whois.arin.net/rest/poc/RLK3-ARIN NetBlock data: OrgName: FIRST SOLAR LLC OrgId: FIRST-283 Address: 1391 GENEVA DR City: SUNYVL StateProv: CA PostalCode: 94089 Call Rebecca and ask? It seems unlikely though to be proper... of course, maybe the block was re-allocated by ATT and whois just hasn't caught up? -chris (note that it doesn't SEEM that BEX is actually announcing that block currently? nor are there other att prefixes in their announcements) > BRs. > > ---------- Forwarded message ---------- > From: argus-alarm > Date: 2012/3/23 > Subject: [Argus] 12.231.155/24 is 'hijacked' by anomalous origin 'AS13490' > To: argus > > > Prefix hijacking alarm: > ?Start Time(UTC): Mar-22-2012 16:29:07 > ?IP Prefix: 12.231.155/24 > ?Origin AS change: AS7018 -> AS13490 > ?Details: http://argus.csnet1.cs.tsinghua.edu.cn/fingerprints/207340/ > _______________________________________________ > Argus mailing list > Argus at csnet1.cs.tsinghua.edu.cn > http://csnet1.cs.tsinghua.edu.cn/mailman/listinfo/argus > > > > -- > _________________________________________ > Yang Xiang. Ph.D candidate. Tsinghua University > Argus: argus.csnet1.cs.tsinghua.edu.cn From bill at herrin.us Thu Mar 22 13:08:52 2012 From: bill at herrin.us (William Herrin) Date: Thu, 22 Mar 2012 14:08:52 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: On Thu, Mar 22, 2012 at 1:22 PM, Keegan Holley wrote: > 2012/3/22 Jared Mauch >> On Mar 22, 2012, at 11:05 AM, chris wrote: >> > I'm all for VZ being able to reclaim it as long as they open their fiber >> > which I don't see happening unless its by force via government. At the >> end >> > of the day there needs to be the ability to allow competitors in so of >> > course they shouldnt be allowed to rip out the regulated part and replace >> > it with a unregulated one. > > Maybe I'm missing something, but how exactly does one share fiber? ?Isn't > it usually a closed loop between DWDM or Sonet nodes? ?It doesn't seem fair > to force the incumbents to start handing out lambdas and timeslots to their > competitors on the business side. ?I guess passive optical can be shared > depending on the details of the network, but that would still be much > different than sharing copper pairs. PON (e.g. FIOS) is similar to CWDM. The PO in PON is Passive Optical. As in a glass prism-like device with no electronics. You remember prisms from high school physics, right? Beam of white light into a glass triangle and it splits off into a rainbow of colors. Well, with CWDM the different color sources all being joined by the prism into a beam of "white" light. And then split back out at the other end. So, you share fiber by having one guy control one wavelength (color, e.g. red) and another guy control another wavelength (e.g. blue). And when you install it to a home or business, the "prism" sits up on the phone pole and just splits out the one wavelength that is intended for that location. You can't even stray out of your color: if you do, the prism will bend the light in a way that misses the target beam. Key is: it's just a piece of glass. A very finely machined piece of glass to be sure, but no electronics. Or, you could share at a different level: ethernet packets. Unbundle the local ethernet service from the Internet service. $X for the local ethernet service to the local concentration point at whatever capacity, $Y for the Internet/tv/phone services connected at the concentration point. Or buy some other service from another vendor at the concentration point. But you don't get to double-dip the billing: $X includes the cost to take the packets off at the concentration point; the service vendor doesn't pay again. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rs at seastrom.com Thu Mar 22 13:21:47 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 22 Mar 2012 14:21:47 -0400 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: (William Herrin's message of "Thu, 22 Mar 2012 10:53:10 -0400") References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <86haxgu3ao.fsf@seastrom.com> Message-ID: <86vclwv6mc.fsf@seastrom.com> William Herrin writes: > That depends on the cost of recovering it. We're not talking about > salvage operators pulling cable, we're talking about highly trained > [sic] Verizon installers. > > The last 4 pairs in use on that 3000 count cable will tend to linger a > long, long time before you can go remove it. Mostly you'll recover > short runs of low-count cable like the fifty-foot two and six pair > cables from the street to the house: maybe $3 in scrap. How many > dollars worth of time will the installer bill Verizon for recovering > it? I bet there is some kind of creative accounting that they can use that makes this totally worthwhile window dressing on their 10-Qs. -r From lsc at prgmr.com Thu Mar 22 13:59:16 2012 From: lsc at prgmr.com (Luke S. Crawford) Date: Thu, 22 Mar 2012 14:59:16 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: <20120322185915.GA25250@luke.xen.prgmr.com> On Thu, Mar 22, 2012 at 01:31:47PM -0400, Jared Mauch wrote: > You agree on a price per distance (e.g.: mile/foot/whatnot). > > Lets say the cable costs $25k to install for the distance of 5000 feet. > > That cable has 144 strands. > > You need access to one strand. If you install it yourself, it will cost you $25k. If you share the pro-rata cost, it comes out around $174 for that strand. Lets say they mark it up 10x (profit, unused strands), would you pay $1740 for access? What does emergency restoration cost? > > WDM/DWDM add cost to that strand, but also increase the capacity based on what your overall lit capacity may be on a route. There are various cwdm/dwdm systems that range the usual 10/20/40/80/100km ranges. You obviously need to do the math yourselves on this. You may find the ROI is better than you think... I'm trying to do just that right now, actually. 55 s. market to 250 Stockton in San Jose. I dono if it's five thousand feet, but it's not twice that. The cheapest fiber pair I can rent from someone else I've found is $5K/month; the cheapest build-out I've found is $150K, so even if I'm only using one pair in that, if I can get money at anything like a reasonable interest rate, if I plan on sticking around more than 5 years it makes sense to lay new fiber. Which is weird, as this is probably one of the densest masses of existing fiber in the world, going from a 'center of the universe' data center to a minor data center. Even the $5K/month rate isn't bad. If they asked for a third of that, I'd bite even though I don't need that much capacity quite yet. The big problem here, I think, is that it's quite difficult to figure out who has what fiber where, and even once you know who owns it, to find out who to talk to at a company that might know what 'dark fiber' is, much less know how much they might rent it to you for. I spent several hours last month on the phone with XO and I kept getting redirected to someone trying to sell me a T1. I've got other projects right now, but once I'm done with that, I'm going to be spending a bunch of time pestering the PUC and other people that might know who owns fiber between here and there. As for equipment cost, in my corner of the world, I can get used cisco 15540 systems for what I consider to be not very much money, and 32 10G waves is plenty for what I'm doing. I mean, they eat way more power than is required, and 10G/wave is not great these days, but if I could sell a reasonable number of waves, even at a whole order of magnitude below market, I'd be in good shape. The whole project seems dramatically cheaper than lit services. At quoted prices, 10G waves over the same distance cost about 1/2 what a full pair of dark fiber costs. Now, the big problem with the build out? as far as I can tell, I've gotta be a carrier to actually own fiber in the ground. From what I understand, that's not out of the question for me, but it's definitely a lot of work and red tape. There are, however, companies that will do a build out for you (of course, charging you for it up front) then they will lease you the fiber at a very low yearly rate - right now, that looks like the second-best option, where the best option is hunting down the owners of all the dead bundles of fiber going into the meetme room. (250 Stockton is ex-enron, it's got bundles coming in from MFN, quest, global crossing, MCI, "enron broadband" xo and others. I'd bet money that if I had the kind of access to the meetme at 55 s. Market that I have at 250 Stockton I could start shining light down empty strands and I'd see some of it come out the other side.) But from the amount of time it takes to just find someone at those companies that even knows what dark fiber is? I think I might be better off putting in the effort to do whatever regulatory red tape is required to own fiber in the ground. So yeah; really? in my corner of the world, the problem is the same problem you see everywhere else in this industry. Any useful information is guarded jealously. In this case, where does the fiber run? I mean, I have pretty good maps of the Santa Clara municipal fiber network; but the private networks are impossible. From paul.w.bennett at gmail.com Thu Mar 22 14:31:50 2012 From: paul.w.bennett at gmail.com (Paul Bennett) Date: Thu, 22 Mar 2012 15:31:50 -0400 Subject: how to report spam to Yahoo! In-Reply-To: <20120321132719.GT1574@angus.ind.WPI.EDU> References: <20120321132719.GT1574@angus.ind.WPI.EDU> Message-ID: On Wed, Mar 21, 2012 at 9:27 AM, Chuck Anderson wrote: > Yahoo!'s abuse contact from whois: > > OrgAbuseEmail: ?network-abuse at cc.yahoo-inc.com Have you tried abuse at att.net ? They accept ARF and X-ARF reports, or anything with the complete message headers (or logs) in it will work in a pinch. Plain-text, no attachments, etc. Don't expect anything more than an autoreply, but all complaints do get processed. -- Paul From paul at paulgraydon.co.uk Thu Mar 22 14:41:05 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 22 Mar 2012 09:41:05 -1000 Subject: how to report spam to Yahoo! In-Reply-To: <20120321132719.GT1574@angus.ind.WPI.EDU> References: <20120321132719.GT1574@angus.ind.WPI.EDU> Message-ID: <4F6B8051.7030704@paulgraydon.co.uk> The Yahoo form hasn't worked for a while. When you do get to somewhere for reporting spam, a few hours or days later you'll get a response telling you to submit a report on the exact same form you used. If you do you end up with the same response. Repeat ad infinitum. Same goes for their grey-listing/rate limiting report message. I've given up trying to report anything e-mail related to Yahoo, mostly just apologise to end users and suggest they use another e-mail provider. Paul On 03/21/2012 03:27 AM, Chuck Anderson wrote: > Yahoo!'s abuse contact from whois: > > OrgAbuseEmail: network-abuse at cc.yahoo-inc.com > > now sends an autoresponse that tells you to go to a web form to report > spam: > > http://help.yahoo.com/l/us/yahoo/mail/yahoomail/spam.html > > but the link doesn't work--it just redirects to a generic Yahoo! help > page at: > > http://help.yahoo.com/kb/index?page=product&locale=en_US&y=PROD_MAIL_ML > > So how does a non-Yahoo! account holder report spam originating from > Yahoo!'s network? > > ----- Forwarded message from Yahoo! Network ----- > > From: Yahoo! Network > Date: Wed, 21 Mar 2012 05:59:35 -0700 > Reply-To: Yahoo! Network > > Thank you for your email, but this address is no longer being used for > abuse reporting or abuse related questions. > > To report spam, please use this form: > http://help.yahoo.com/l/us/yahoo/mail/yahoomail/spam.html > > To report other types of abuse or for help with security or abuse > related issues, please go to Yahoo! Abuse: > http://abuse.yahoo.com > > For questions about using Yahoo! services, please visit Yahoo Help: > http://help.yahoo.com > > Note: Please do not reply to this email as replies will not be answered. > > Thank you, > - Yahoo! Customer Care > > > > > Original Message Follows: > ------------------------ > From jason at thebaughers.com Thu Mar 22 15:03:25 2012 From: jason at thebaughers.com (Jason Baugher) Date: Thu, 22 Mar 2012 15:03:25 -0500 Subject: Looking for direct # for AT&T translations Message-ID: <4F6B858D.8030109@thebaughers.com> Our Central Office has been going around in circles trying to open a trouble with AT&T regarding the inability to make outbound 800 number calls. Anyone have a good number we can use? Thanks From jason at thebaughers.com Thu Mar 22 15:37:18 2012 From: jason at thebaughers.com (Jason Baugher) Date: Thu, 22 Mar 2012 15:37:18 -0500 Subject: Fwd: Looking for direct # for AT&T translations In-Reply-To: <4F6B858D.8030109@thebaughers.com> References: <4F6B858D.8030109@thebaughers.com> Message-ID: <4F6B8D7E.20604@thebaughers.com> I probably should have been more clear. We're an ILEC in West-Central Illinois having trouble originating 800-number calls to CIC 288 (AT&T). Jason -------- Original Message -------- Subject: Looking for direct # for AT&T translations Date: Thu, 22 Mar 2012 15:03:25 -0500 From: Jason Baugher To: nanog Our Central Office has been going around in circles trying to open a trouble with AT&T regarding the inability to make outbound 800 number calls. Anyone have a good number we can use? Thanks From owen at delong.com Thu Mar 22 15:40:27 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Mar 2012 13:40:27 -0700 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> On Mar 22, 2012, at 10:12 AM, chris wrote: > On Thu, Mar 22, 2012 at 12:26 PM, Jared Mauch wrote: > >> >> On Mar 22, 2012, at 11:05 AM, chris wrote: >> >>> I'm all for VZ being able to reclaim it as long as they open their fiber >>> which I don't see happening unless its by force via government. At the >> end >>> of the day there needs to be the ability to allow competitors in so of >>> course they shouldnt be allowed to rip out the regulated part and replace >>> it with a unregulated one. >> >> I think this partly captures the incentive case here, but there is also a >> larger one at play. Over the years the copper infrastructure was installed >> and extended through various incentive programs. You can see the >> modern-day reflection of that in the RUS (used to manage rural >> electrification act, part of USDA) and NTIA (Department of Commerce). >> Yes, I find it quite "amusing" that I am paying additional fees on all of my telecommunications services to subsidize high speed PON networks in rural bumf*ck while I can't get anything like it in San Jose, California. >> The barriers to entry are significant for a new player in the marketplace. >> The cost is putting the cabling in the ground vs the cost of the cable >> itself. One can easily pick up hardware for $250 to light a single strand >> of 9/125 SM fiber @ 10km for a 1Gb/s ethernet link. That's low enough you >> could likely get a consumer to buy the hardware. The real cost is the >> installation per strand foot/mile. >> Yes, at some point, we need to recognize that LMI (Last Mile Infrastructure) is and likely always will be a natural monopoly in all but the most densely populated areas (and actually even in many of those). THe market simply won't support the costs of deploying duplicate infrastructure installed by multiple providers. Given this fact, the only way to ensure competition in the services arena is to divorce the infrastructure from the services and require an independent operator of the infrastructure to make it available on an equal basis to all service providers. >> In the past this has been subsidized for copper plant. There is no reason >> in my mind that the fiber plant should be treated differently from this >> standpoint. I can find fiber optic cabling for $0.25/ft. The problem here >> is a multi-dimensional one that I've seen play out in a few markets: >> One reason the fiber plant should be treated differently is that we should learn from the mistakes we made with copper and we shouldn't continue to subsidize corporations to build out infrastructure that extends their ability to block competitors and should, instead insist that subsidized infrastructure is deployed in such a manner as to benefit all and support healthy competition for the services market. >> It is my firm belief that without a regulatory regime it will not be >> feasible to connect many communities robustly to modern communications >> infrastructure. This could clearly change if the carriers involved see fit >> to replace this infrastructure, but with their current debt loads, I think >> it will be challenging to say the least. >> WHile I agree with you, the situation is already somewhat inverted in the US in that the existing USF subsidies have now made it more cost effective to build advanced networks into rural low-density subscriber bases than into moderately populated areas. >> I do think we need a new last-mile regime in many areas, be it more "fair" >> access similar to pole attach fees or the removal of local barriers to >> build this infrastructure. >> The mechanism I have described above has been deployed in Sweden for some time now and is working out quite well from what I hear. It's also being tried in Australia now, much to the consternation of Telstra, but, it seems to be going well for the residents and businesses. >> Some school and other governments here in Michigan would love to >> sell/lease their excess fiber capacity to the private sector, but are >> worried about turning a profit when it was built with taxpayer funds and >> problems associated with that. I'd like to see these barriers removed. If >> it's there, lets make it of value. If the school system turns a profit on >> their enterprise, that's fine, it can lower the tax burden elsewhere. +1 I do not understand this aversion to government having other sources of revenue besides direct taxation. If government can earn money from infrastructure it built with taxpayer money by leasing it to corporations or others, so long as it doesn't interfere with the original purpose for which the taxpayers funded its construction, I think this should absolutely be allowed and even encouraged. >> Me? I'd be willing to pay $2500 to have Fiber built to my home. I might >> even pay more. At this point, my research continues on building the fiber >> and arranging my own easements for where to place it. I suspect you just >> need a few geeks that are willing to part with some extra $ for fiber >> bragging rights and one can build it. There was a project in New Zealand that started out not too far off from what you are describing above and resulted in a fiber run that now stretches from one end to the other of one of their islands IIRC. It was presented at PacNOG in American Samoa a couple of years back. Owen From owen at delong.com Thu Mar 22 15:48:14 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Mar 2012 13:48:14 -0700 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <69ECC0E5-29E9-431E-8AD3-9798B3EF0750@puck.nether.net> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <69ECC0E5-29E9-431E-8AD3-9798B3EF0750@puck.nether.net> Message-ID: On Mar 22, 2012, at 10:17 AM, Jared Mauch wrote: > > On Mar 22, 2012, at 1:12 PM, chris wrote: > >> Why is it that the big companies are controlling what happens? > > They have used the past decades or century to establish these assets. > > - Jared 1. Do not mistake a large telco for a communications company or an entity that considers itself in the communications business. They are not and do not. They are very large law firms and lobbying organizations that happen to have significant telecommunications infrastructure. One of the key differentiators of the internet is that it is not dominated as a battleground for lawyers and diplomats, but, rather is worked out between cooperating and competing entities as a (relatively) unregulated business transaction. 2. Because companies are allowed to own infrastructure and sell services over that infrastructure and in many cases without being required to make that (subsidized) infrastructure available to other services providers. 3. Because it is very expensive to build out the infrastructure to a given area and the maximum revenue potential from it is limited to a value unlikely to support 2x or more the infrastructure build-out cost, thus resulting in a sort of natural monopoly because it is cost effective to build out if you have a reasonable chance of capturing ~100% of the revenue, but, much less so if you are faced with the possibility of capturing 50% or less of the revenue.[1] Owen [1] Comparing across topologies is not as valid as the carriers would like you to believe. While the end services being offered share significant similarities in a converged digital world, they still retain unique properties that make certain things more optimal for different purposes. Consider the number of places in the US that have more than one cable provider or more than one DSL provider or more than one PON provider. These are few and far between and usually only reflect the very densest population centers. From Jonathon.Exley at kordia.co.nz Thu Mar 22 15:57:43 2012 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Thu, 22 Mar 2012 20:57:43 +0000 Subject: Looking for advice - Auditing zones on a set of name servers In-Reply-To: References: Message-ID: You could try ValiDNS (http://www.validns.net) which I am told does this sort of thing. Jonathon > -----Original Message----- > From: Landon Stewart [mailto:lstewart at superb.net] > Sent: Wednesday, 21 March 2012 9:54 a.m. > To: NANOG list > Subject: Looking for advice - Auditing zones on a set of name servers > > Hi Everyone, > > I'm looking for some advice here. I'm attempting to clean up a set of name > servers and have a list of domain names that should not actually be hosted > on those name servers. In some cases there are issues where there are > actually no NS records in a domain but it should be hosted on those name > servers. In some cases the name servers just aren't authoritative and the > domain should be removed. The name servers are all djbdns, not that it > matters a whole lot. > > I'm wondering if anyone knows of some tools that I can use other than > homegrown ones that are a little more robust in terms of thinking of every > little possible issue for or against a domain than I can think of. Of a list of > domains that I marked for deletion some of them simply had little problems > but should not be deleted (rather just have their NS records fixed). I also > don't' want to pound on someone else's recursive name servers or even the > root name servers trying to audit ours since that's not very nice. If anything I > guess I could spread out the queries if I had the right tools. > > I wrote a quick script that looks up the NS records for a zone, then the A > records for those NS records and checks the resulting IP addresses against a > list of IP addresses that are our name servers. It's not quite doing all I need it > to do since sometimes we are authoritative but there are no NS records or > they are wrong. I'm also not sure beating on google's name servers is a good > idea either so you should fill in your OWN recursive name servers instead f > 8.8.8.8 and 8.8.4.4. > > Thanks for reading! :-D This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From young at jsyoung.net Thu Mar 22 16:12:43 2012 From: young at jsyoung.net (Jeff Young) Date: Fri, 23 Mar 2012 08:12:43 +1100 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> Message-ID: On 23/03/2012, at 4:51 AM, Jay Ashworth wrote: > As you might imagine, I am a fairly strong proponent of muni layer 1 -- > or even layer 2, where the municipality supplies (matching) ONTs, and > services have to fit over GigE -- fiber delivery of high-speed data > service. > > I believe Google agrees with me. :-) And the country of Australia agrees with you (at least more than half of it). The current nature of FTTH makes it hard to do a layer 1-only service and the NBN has opted to provide layer 2 hand-off at POI's (points of interconnect) around Australia. jy From james.braunegg at micron21.com Thu Mar 22 16:49:08 2012 From: james.braunegg at micron21.com (James Braunegg) Date: Thu, 22 Mar 2012 21:49:08 +0000 Subject: http://www.moduletek.com/ SFP's anyone using them Message-ID: Dear Nanog Just wondering if anyone has used moduletek 10gbit SFP's+ and what has your experience been like ? their product spec sheets are almost identical to Finisar http://www.moduletek.com/ Kindest Regards James Braunegg W:? 1300 769 972? |? M:? 0488 997 207 |? D:? (03) 9751 7616 E:?? james.braunegg at micron21.com? |? ABN:? 12 109 977 666?? This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. From lstewart at superb.net Thu Mar 22 17:05:27 2012 From: lstewart at superb.net (Landon Stewart) Date: Thu, 22 Mar 2012 15:05:27 -0700 Subject: Looking for advice - Auditing zones on a set of name servers In-Reply-To: References: Message-ID: ..snip.. > > I need it to do since sometimes we are authoritative but there are no NS > > records or they are wrong. I'm also not sure beating on google's name > > servers is a good idea either so you should fill in your OWN recursive > name > > servers instead f 8.8.8.8 and 8.8.4.4. > > don't you really want to walk the tree from . down? so dig +trace | > machine-ify > then make sure that the criteria you care about work out properly? > (this avoides people's old/legacy/super-long-ttl causing problems in > the shorter term) > I've done it this way. Another person wrote me off list and said the same thing so I've modified things to do it this way and it looks good. Thanks for your reply! From jharper at well.com Thu Mar 22 17:07:02 2012 From: jharper at well.com (Jeff Harper) Date: Thu, 22 Mar 2012 15:07:02 -0700 (PDT) Subject: Routing issues? In-Reply-To: Message-ID: <1475206893.4379.1332454022509.JavaMail.root@zimbra.well.com> Anyone else noticing some routing abnormalities today? http://www.internettrafficreport.com/details.htm Jeff Harper | www.well.com ip access-list extended jeff permit ip any any eq intelligence log deny ip any any eq stupid-people From Valdis.Kletnieks at vt.edu Thu Mar 22 17:11:33 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 22 Mar 2012 18:11:33 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: Your message of "Thu, 22 Mar 2012 13:40:27 -0700." <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> Message-ID: <48045.1332454293@turing-police.cc.vt.edu> On Thu, 22 Mar 2012 13:40:27 -0700, Owen DeLong said: > Yes, I find it quite "amusing" that I am paying additional fees on all > of my telecommunications services to subsidize high speed PON networks > in rural bumf*ck while I can't get anything like it in San Jose, California. That's OK, you're all in the same boat - the subsidized users can't get it either. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Thu Mar 22 17:15:56 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 23 Mar 2012 07:15:56 +0900 Subject: last mile, regulatory incentives, etc In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: <4F6BA49C.7040004@necom830.hpcl.titech.ac.jp> William Herrin wrote: > PON (e.g. FIOS) is similar to CWDM. If you are not talking about WDM PON, no, not at all. > The PO in PON is Passive Optical. > As in a glass prism-like device with no electronics. The passive optical device of usual PON is not a prism but a splitter. The entire optics is shared by all the subscribers sharing a fiber. Thus, the problem is collision avoidance of simultaneous transmission, which makes PON time shared with L2 protocols. > So, you share fiber by having one guy control one wavelength (color, > e.g. red) and another guy control another wavelength (e.g. blue). That's not a usual PON but WDN PON. > Or, you could share at a different level: ethernet packets. That's where usual PON can be shared. But, it costs a lot, as much as sharing at L3. Masataka Ohta From gjshep at gmail.com Thu Mar 22 17:49:19 2012 From: gjshep at gmail.com (Greg Shepherd) Date: Thu, 22 Mar 2012 15:49:19 -0700 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <48045.1332454293@turing-police.cc.vt.edu> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> Message-ID: On Thu, Mar 22, 2012 at 3:11 PM, wrote: > On Thu, 22 Mar 2012 13:40:27 -0700, Owen DeLong said: >> Yes, I find it quite "amusing" that I am paying additional fees on all >> of my telecommunications services to subsidize high speed PON networks >> in rural bumf*ck while I can't get anything like it in San Jose, California. > > That's OK, you're all in the same boat - the subsidized users can't get it either. :) So where are these "subsidies" going? I live in rural BFE where most of my neighbors are still dialing in, and the local providers have no $$ incentive to build out here. Greg From john.yocum at fluidhosting.com Thu Mar 22 17:57:12 2012 From: john.yocum at fluidhosting.com (John T. Yocum) Date: Thu, 22 Mar 2012 15:57:12 -0700 Subject: last mile, regulatory incentives, etc In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> Message-ID: <4F6BAE48.3060700@fluidhosting.com> On 3/22/2012 3:49 PM, Greg Shepherd wrote: > On Thu, Mar 22, 2012 at 3:11 PM, wrote: >> On Thu, 22 Mar 2012 13:40:27 -0700, Owen DeLong said: >>> Yes, I find it quite "amusing" that I am paying additional fees on all >>> of my telecommunications services to subsidize high speed PON networks >>> in rural bumf*ck while I can't get anything like it in San Jose, California. >> >> That's OK, you're all in the same boat - the subsidized users can't get it either. :) > > So where are these "subsidies" going? I live in rural BFE where most > of my neighbors are still dialing in, and the local providers have no > $$ incentive to build out here. > > Greg > I imagine a lot goes into the general maintenance of rural systems. I recall 12 - 15 years ago, on the local news when it was announced a small town got its first phone line. Cost to GTE at the time was said to be 40K to do it, as the town was 20+ miles from the nearest anything. I've lived in an area where Verizon had to maintain 10 miles of overhead just for 1 SLC that serves 20 homes. Not that the service was any good but, I'm sure the cost was far higher than what the customers were paying. --John From drew.linsalata at gmail.com Thu Mar 22 17:58:32 2012 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Thu, 22 Mar 2012 18:58:32 -0400 Subject: Planet-Lab.org traffic Message-ID: At about 17:40 EDT today we started seeing traffic from planet-lab.orgnodes at 25+ US universities all directed at one of our hosting boxes. Its all ICMP and high port UDP stuff. Nothing terrible from what we can tell, but its triggering a constant stream of IDS alerts and auto-blocks. Not easy to configure for since the traffic originates from subnets all over the place, and the list of originating nodes is growing every few minutes. Its horribly annoying, and trying to determine the source using the tools provided on the planet-lab.org site is pretty much impossible as the search tool returns nothing at all times. Yes, we've opened a ticket with support at planet-lab.org already. Has anyone else had to deal with this, or is anyone connected to that particular project listening? Im all for academic projects, but the approach here is rubbing me the wrong way. From keegan.holley at sungard.com Thu Mar 22 18:16:37 2012 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 22 Mar 2012 19:16:37 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: 2012/3/22 William Herrin > On Thu, Mar 22, 2012 at 1:22 PM, Keegan Holley > wrote: > > 2012/3/22 Jared Mauch > >> On Mar 22, 2012, at 11:05 AM, chris wrote: > >> > I'm all for VZ being able to reclaim it as long as they open their > fiber > >> > which I don't see happening unless its by force via government. At the > >> end > >> > of the day there needs to be the ability to allow competitors in so of > >> > course they shouldnt be allowed to rip out the regulated part and > replace > >> > it with a unregulated one. > > > > Maybe I'm missing something, but how exactly does one share fiber? Isn't > > it usually a closed loop between DWDM or Sonet nodes? It doesn't seem > fair > > to force the incumbents to start handing out lambdas and timeslots to > their > > competitors on the business side. I guess passive optical can be shared > > depending on the details of the network, but that would still be much > > different than sharing copper pairs. > > > So, you share fiber by having one guy control one wavelength (color, > e.g. red) and another guy control another wavelength (e.g. blue). And > when you install it to a home or business, the "prism" sits up on the > phone pole and just splits out the one wavelength that is intended for > that location. You can't even stray out of your color: if you do, the > prism will bend the light in a way that misses the target beam. > > So who get's the keys the the cabinet it resides in? The LEC? All of the CLECs? The FCC? Who's responsible for maintaining the box given it's now shared. Who takes legal responsibility for outages caused by things done to this magical prism you speak of? In the LD to LEC carrier model you can use whatever you want, but this is different from what the FCC intended when they forced the incumbents to share copper plant. Also PON and WDM are very different actually, but that's beside the point. Once the incumbent has to permit access to their nodes the CLECs become customers. Copper pairs followed a different model because they could be used by anyone at the whim of hte customer. Not all fiber based networks are implemented that way. From bill at herrin.us Thu Mar 22 18:41:14 2012 From: bill at herrin.us (William Herrin) Date: Thu, 22 Mar 2012 19:41:14 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: On Thu, Mar 22, 2012 at 7:16 PM, Keegan Holley wrote: > 2012/3/22 William Herrin >> On Thu, Mar 22, 2012 at 1:22 PM, Keegan Holley >> wrote: >> > Maybe I'm missing something, but how exactly does one share fiber? >> > ?Isn't >> > it usually a closed loop between DWDM or Sonet nodes? ?It doesn't seem >> > fair >> > to force the incumbents to start handing out lambdas and timeslots to >> > their >> > competitors on the business side. ?I guess passive optical can be shared >> > depending on the details of the network, but that would still be much >> > different than sharing copper pairs. >> >> >> So, you share fiber by having one guy control one wavelength (color, >> e.g. red) and another guy control another wavelength (e.g. blue). And >> when you install it to a home or business, the "prism" sits up on the >> phone pole and just splits out the one wavelength that is intended for >> that location. You can't even stray out of your color: if you do, the >> prism will bend the light in a way that misses the target beam. >> > So who get's the keys the the cabinet it resides in?? The LEC?? All of the > CLECs?? The FCC?? Who's responsible for maintaining the box given it's now > shared.? Who takes legal responsibility for outages caused by things done to > this magical prism you speak of? A fiber wavelength in the described PON scenario is operationally identical to a dedicated fiber strand or a dedicated copper pair with respect to management and connection. There's a physical "wire" coming out at each end which is connected to equipment with "lights" it. The problem is reduced to the already solved one of how to "share" copper pairs in a single cable. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Thu Mar 22 20:07:02 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 22 Mar 2012 21:07:02 -0400 Subject: Planet-Lab.org traffic In-Reply-To: References: Message-ID: On Thu, Mar 22, 2012 at 6:58 PM, Drew Linsalata wrote: > Has anyone else had to deal with this, or is anyone connected to that people get dos'd (or think they do, not you in this case) regularly. > particular project listening? ?Im all for academic projects, but the > approach here is rubbing me the wrong way. normally their support arm had been helpful... in the past at least I'd gotten responses :( From kyle.creyts at gmail.com Thu Mar 22 20:12:39 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Thu, 22 Mar 2012 21:12:39 -0400 Subject: Routing issues? In-Reply-To: <1475206893.4379.1332454022509.JavaMail.root@zimbra.well.com> References: <1475206893.4379.1332454022509.JavaMail.root@zimbra.well.com> Message-ID: Kinda looks like a problem with their monitor. On Mar 22, 2012 6:07 PM, "Jeff Harper" wrote: > Anyone else noticing some routing abnormalities today? > > http://www.internettrafficreport.com/details.htm > > Jeff Harper | www.well.com > ip access-list extended jeff > permit ip any any eq intelligence log > deny ip any any eq stupid-people > > > From blakjak at blakjak.net Thu Mar 22 21:21:28 2012 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 23 Mar 2012 15:21:28 +1300 Subject: how to report spam to Yahoo! In-Reply-To: <4F6B8051.7030704@paulgraydon.co.uk> References: <20120321132719.GT1574@angus.ind.WPI.EDU> <4F6B8051.7030704@paulgraydon.co.uk> Message-ID: <4F6BDE28.8090508@blakjak.net> I used to use this form semi regularly. It's behavior has changed in the last couple of months, after i'd finally gotten over the whole 'why can't I just forward them the email' thing and gotten used to copying and pasting the header and the body (seperately) into different fields on their webform. I'm disgusted that Yahoo (a regular source of spam) no longer readily offer the means to report the abusers (or abused accounts) in their midst. This while they apply some of the most over-the-top and disproportionate justifications to categorise inbound mail as spam (to their customers detriment, and also their correspondents, who have no idea why they're being categorised that way). If anyone knows what Yahoo's intentions are in this space, i'd love to hear about it. Mark. On 23/03/12 08:41, Paul Graydon wrote: > The Yahoo form hasn't worked for a while. When you do get to > somewhere for reporting spam, a few hours or days later you'll get a > response telling you to submit a report on the exact same form you > used. If you do you end up with the same response. Repeat ad > infinitum. Same goes for their grey-listing/rate limiting report > message. I've given up trying to report anything e-mail related to > Yahoo, mostly just apologise to end users and suggest they use another > e-mail provider. > > Paul > > On 03/21/2012 03:27 AM, Chuck Anderson wrote: >> Yahoo!'s abuse contact from whois: >> >> OrgAbuseEmail: network-abuse at cc.yahoo-inc.com >> >> now sends an autoresponse that tells you to go to a web form to report >> spam: >> >> http://help.yahoo.com/l/us/yahoo/mail/yahoomail/spam.html >> >> but the link doesn't work--it just redirects to a generic Yahoo! help >> page at: >> >> http://help.yahoo.com/kb/index?page=product&locale=en_US&y=PROD_MAIL_ML >> >> So how does a non-Yahoo! account holder report spam originating from >> Yahoo!'s network? >> >> ----- Forwarded message from Yahoo! >> Network ----- >> >> From: Yahoo! Network >> Date: Wed, 21 Mar 2012 05:59:35 -0700 >> Reply-To: Yahoo! Network >> >> Thank you for your email, but this address is no longer being used for >> abuse reporting or abuse related questions. >> >> To report spam, please use this form: >> http://help.yahoo.com/l/us/yahoo/mail/yahoomail/spam.html >> >> To report other types of abuse or for help with security or abuse >> related issues, please go to Yahoo! Abuse: >> http://abuse.yahoo.com >> >> For questions about using Yahoo! services, please visit Yahoo Help: >> http://help.yahoo.com >> >> Note: Please do not reply to this email as replies will not be answered. >> >> Thank you, >> - Yahoo! Customer Care >> >> >> >> >> Original Message Follows: >> ------------------------ >> > > From drew.linsalata at gmail.com Thu Mar 22 21:29:04 2012 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Thu, 22 Mar 2012 22:29:04 -0400 Subject: Planet-Lab.org traffic In-Reply-To: References: Message-ID: In fairness to the PlanetLab folks, I did get a response to my original ticket and someone from NANOG also contacted me after my post. I do appreciate that. I will repeat that the traffic is not malicious, but it might be a more friendly policy to allow network operators to automatically opt-out of that environment if desired. Since we have some semblance of clue it was obvious within 30 seconds that this was an academic research network at play, and only took another 15 seconds to figure out that it was PlanetLab, so just let me add my subnets to a database which then prevents the "uber cluster" from including those subnets when generating experimental traffic. Another option might be to clearly state which prefixes the traffic may originate from so operators can filter accordingly. The cluster is pretty widespread so I realize that might not be very practical. Simply assuming that we won't mind having PlanetLab researchers using our assets as a lab isn't terribly cool. On Thu, Mar 22, 2012 at 9:07 PM, Christopher Morrow wrote: > On Thu, Mar 22, 2012 at 6:58 PM, Drew Linsalata > wrote: > > Has anyone else had to deal with this, or is anyone connected to that > > people get dos'd (or think they do, not you in this case) regularly. > > > particular project listening? Im all for academic projects, but the > > approach here is rubbing me the wrong way. > > normally their support arm had been helpful... in the past at least > I'd gotten responses :( > From dwcarder at wisc.edu Thu Mar 22 22:57:03 2012 From: dwcarder at wisc.edu (Dale W. Carder) Date: Thu, 22 Mar 2012 22:57:03 -0500 Subject: http://www.moduletek.com/ SFP's anyone using them In-Reply-To: References: Message-ID: <814C4C92-8773-48D3-810D-15601BFD1A24@wisc.edu> Hey James, On Mar 22, 2012, at 4:49 PM, James Braunegg wrote: > http://www.moduletek.com/ > Just wondering if anyone has used moduletek 10gbit SFP's+ and what has your experience been like ? We've used a variety of what they have for 4-5 years now in in lots of flavors of sfp, sfp+, x2, xfp, xenpak, lr & cwdm, etc, in vendors C, J, and what is now D gear. Cost effective and reliable. Lead times depend on stock / fab / shipping / customs. I have heard they might do paypal now in addition to wire xfer. Dale as59 / as2381 From frnkblk at iname.com Thu Mar 22 23:27:09 2012 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 22 Mar 2012 23:27:09 -0500 Subject: Monitoring other people's sites (Was: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error") In-Reply-To: <4F689A15.8020707@unfix.org> References: <01fb01cd0674$9b010240$d10306c0$@iname.com> <4F689A15.8020707@unfix.org> Message-ID: <029501cd08ad$3659ed80$a30dc880$@iname.com> I and my customers users IPv6-enabled sites. If it doesn't work (a hopefully their web browser uses HE) I want to know, and know when it happens. Yes, many sites aren't monitoring their own IPv6-connected content, but I've had reasonably good success privately letting them know when it's down. And communicating to them when it's down lets them know that people care and want to access their IPv6-enabled content. Last, monitoring IPv6 access to many different sites brings our own connectivity issues to the surface as they arise -- we had one inside Level3's network last week Friday and it was resolved about 18 hours later. If we had not monitored it's possible it would be much longer before it was discovered and troubleshot through the regular sequence of events. Frank -----Original Message----- From: Jeroen Massar [mailto:jeroen at unfix.org] Sent: Tuesday, March 20, 2012 9:54 AM To: Vinny_Abello at Dell.com Cc: nanog at nanog.org Subject: Monitoring other people's sites (Was: Website for ipv6.level3.com returns "HTTP/1.1 500 Internal Server Error") And for the few folks putting nagios's on other people's sites, they obviously do not understand that even if the alarm goes off that something is broken that they cannot fix it anyway, thus why bother... From nanog at punk.co.nz Thu Mar 22 23:45:27 2012 From: nanog at punk.co.nz (Kris Price) Date: Thu, 22 Mar 2012 21:45:27 -0700 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> Message-ID: <4F6BFFE7.3090201@punk.co.nz> > I believe Google agrees with me. :-) Are they? Last I saw they were building out a layer 3 network -- no wholesale access -- did this change? It sorta fit with their goals in that it meant they could build a faster/simpler network for less money and make a big/bold 1 Gbps to every home (not really true) statement, but it doesn't end up serving a very practical model for most of the world who believe the separation needs to happen at layer 2. Layer 3 is interesting, but is everyone happy with saying goodbye to the ISP entirely and accepting regional monopolies on that space? From randy at psg.com Fri Mar 23 00:37:37 2012 From: randy at psg.com (Randy Bush) Date: Fri, 23 Mar 2012 06:37:37 +0100 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> Message-ID: >>> Yes, I find it quite "amusing" that I am paying additional fees on >>> all of my telecommunications services to subsidize high speed PON >>> networks in rural bumf*ck while I can't get anything like it in San >>> Jose, California. >> That's OK, you're all in the same boat - the subsidized users can't >> get it either. :) > So where are these "subsidies" going? what a silly question. lining the telcos' pockets. american so called 'broadband' is a joke and a scam. randy From faisal at snappydsl.net Fri Mar 23 00:53:49 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Fri, 23 Mar 2012 01:53:49 -0400 Subject: last mile, regulatory incentives, etc In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> Message-ID: <4F6C0FED.4070100@snappydsl.net> So do a quick research on USF and see who gets paid from it... Please don't read this if you have just eaten.. you might puke .. http://connectedplanetonline.com/commentary/real-story-usf-data-071510/ http://republicans.energycommerce.house.gov/Media/file/PDFs/2011usf/ResponsetoQuestion1.pdf If you have more time.. read these for your enjoyment.. http://energycommerce.house.gov/news/PRArticle.aspx?NewsID=8737 Then one can understand how come folks like Century Tel can gobble up Qwest, Savvis, Sprint, and a few others rather quickly !!! I believe the current USF contribution is about 19% !!! Faisal Imtiaz Snappy Internet& Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 3/23/2012 1:37 AM, Randy Bush wrote: >>>> Yes, I find it quite "amusing" that I am paying additional fees on >>>> all of my telecommunications services to subsidize high speed PON >>>> networks in rural bumf*ck while I can't get anything like it in San >>>> Jose, California. >>> That's OK, you're all in the same boat - the subsidized users can't >>> get it either. :) >> So where are these "subsidies" going? > what a silly question. lining the telcos' pockets. american so called > 'broadband' is a joke and a scam. > > randy > > From Valdis.Kletnieks at vt.edu Fri Mar 23 02:01:38 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Mar 2012 03:01:38 -0400 Subject: how to report spam to Yahoo! In-Reply-To: Your message of "Fri, 23 Mar 2012 15:21:28 +1300." <4F6BDE28.8090508@blakjak.net> References: <20120321132719.GT1574@angus.ind.WPI.EDU> <4F6B8051.7030704@paulgraydon.co.uk> <4F6BDE28.8090508@blakjak.net> Message-ID: <16118.1332486098@turing-police.cc.vt.edu> On Fri, 23 Mar 2012 15:21:28 +1300, Mark Foster said: > If anyone knows what Yahoo's intentions are in this space, i'd love to > hear about it. There's good reason to think that even Yahoo doesn't know what its intentions are. http://pandodaily.com/2012/03/16/yahoo-decides-to-fire-its-brightest-tech-minds-facebook-will-gladly-take-them/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jared at puck.nether.net Fri Mar 23 05:49:57 2012 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 23 Mar 2012 06:49:57 -0400 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <4F6BFFE7.3090201@punk.co.nz> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <4F6BFFE7.3090201@punk.co.nz> Message-ID: <0B60F7E3-1075-4A26-8BD7-742C63420D22@puck.nether.net> It is already a monopoly. Most places are served by one of the utilities: power, telephony or cable. He that controls the outside plant controls your fate. Jared Mauch On Mar 23, 2012, at 12:45 AM, Kris Price wrote: > Layer 3 is interesting, but is everyone happy with saying goodbye to the ISP entirely and accepting regional monopolies on that space? From eugen at leitl.org Fri Mar 23 06:53:45 2012 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 23 Mar 2012 12:53:45 +0100 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms Message-ID: <20120323115345.GF9891@leitl.org> http://www.extremetech.com/extreme/122989-1-5-billion-the-cost-of-cutting-london-toyko-latency-by-60ms $1.5 billion: The cost of cutting London-Tokyo latency by 60ms By Sebastian Anthony on March 20, 2012 at 1:04 pm Arctic Link submarine cable Starting this summer, a convoy of ice breakers and specially-adapted polar ice-rated cable laying ships will begin to lay the first ever trans-Arctic Ocean submarine fiber optic cables. Two of these cables, called Artic Fibre and Arctic Link, will cross the Northwest Passage which runs through the Canadian Arctic Archipelago. A third cable, the Russian Optical Trans-Arctic Submarine Cable System (ROTACS), will skirt the north coast of Scandinavia and Russia. All three cables will connect the United Kingdom to Japan, with a smattering of branches that will provide high-speed internet access to a handful of Arctic Circle communities. The completed cables are estimated to cost between $600 million and $1.5 billion each. All three cables are being laid for the same reasons: Redundancy and speed. As it stands, it takes roughly 230 milliseconds for a packet to go from London to Tokyo; the new cables will reduce this by 30% to 170ms. This speed-up will be gained by virtue of a much shorter run: Currently, packets from the UK to Japan either have to traverse Europe, the Middle East, and the Indian Ocean, or the Atlantic, US, and Pacific, both routes racking up around 15,000 miles in the process. It?s only 10,000 miles (16,000km) across the Arctic Ocean, and you don?t have to mess around with any land crossings, either. Russian Optical Trans-Arctic Submarine Cable System (ROTACS) between UK and JapanThe massive drop in latency is expected to supercharge algorithmic stock market trading, where a difference of a few milliseconds can gain (or lose) millions of dollars. It is for this reason that a new cable is currently being laid between the UK and US ? it will cost $300 million and shave ?just? six milliseconds off the fastest link currently available. The lower latency will also be a boon to other technologies that hinge heavily on the internet, such as telemedicine (and teleconferencing) and education. Telephone calls and live news coverage would also enjoy the significantly lower latency. Each of the fiber optic cables will have a capacity in the terabits-per-second range, which will probably come in handy too. Beyond the stock markets, though, the main advantage of the three new cables is added redundancy. Currently, almost every cable that lands in Asia goes through a choke point in the Middle East or the Luzon Strait between the Philippine and South China seas. If a ship were to drag an anchor across the wrong patch of seabed, billions of people could wake up to find themselves either completely disconnected from the internet or surfing with dial-up-like speeds. The three new cables will all come down from the north of Japan, through the relatively-empty Bering Sea ? and the Arctic Ocean, where each of the cables will run for more than 5,000 miles, is one of the least-trafficked parts of the world. That said, the cables will still have to be laid hundreds of meters below the surface to avoid the tails of roving icebergs. The ROTACS cable path Each cable will be laid by a pair of ships: an ice breaker that leads the way, and a cable ship. Until now it has been impossible to lay cables in the Arctic Ocean, but the retreat of the Arctic sea ice means that the Northwest Passage is now generally ice-free from August to October; a big enough window that cable can be laid fairly safely. Existing cable ships (and there aren?t many of them) are all outfitted for balmier climes, so all three cables will require the use of a polar ice-rated ship that has been retrofitted to carry cable-laying gear. Read more about the secret world of submarine cables. For more information on the Russian Optical Trans-Arctic Submarine Cable System (ROTACS), check out the Polarnet Project (machine translated). The Arctic Fibre and Arctic Link websites have information on the North American cables. [Image credit: New Scientist] From me at anuragbhatia.com Fri Mar 23 06:58:58 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 23 Mar 2012 17:28:58 +0530 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <20120323115345.GF9891@leitl.org> References: <20120323115345.GF9891@leitl.org> Message-ID: Yeah this is super cool! I hope ISPs will peer well once cable is ready! (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Mar 23, 2012 5:24 PM, "Eugen Leitl" wrote: > > > http://www.extremetech.com/extreme/122989-1-5-billion-the-cost-of-cutting-london-toyko-latency-by-60ms > > $1.5 billion: The cost of cutting London-Tokyo latency by 60ms > > By Sebastian Anthony on March 20, 2012 at 1:04 pm > > Arctic Link submarine cable > > Starting this summer, a convoy of ice breakers and specially-adapted polar > ice-rated cable laying ships will begin to lay the first ever trans-Arctic > Ocean submarine fiber optic cables. Two of these cables, called Artic Fibre > and Arctic Link, will cross the Northwest Passage which runs through the > Canadian Arctic Archipelago. A third cable, the Russian Optical > Trans-Arctic > Submarine Cable System (ROTACS), will skirt the north coast of Scandinavia > and Russia. All three cables will connect the United Kingdom to Japan, > with a > smattering of branches that will provide high-speed internet access to a > handful of Arctic Circle communities. The completed cables are estimated to > cost between $600 million and $1.5 billion each. > > All three cables are being laid for the same reasons: Redundancy and speed. > As it stands, it takes roughly 230 milliseconds for a packet to go from > London to Tokyo; the new cables will reduce this by 30% to 170ms. This > speed-up will be gained by virtue of a much shorter run: Currently, packets > from the UK to Japan either have to traverse Europe, the Middle East, and > the > Indian Ocean, or the Atlantic, US, and Pacific, both routes racking up > around > 15,000 miles in the process. It?s only 10,000 miles (16,000km) across the > Arctic Ocean, and you don?t have to mess around with any land crossings, > either. > > Russian Optical Trans-Arctic Submarine Cable System (ROTACS) between UK and > JapanThe massive drop in latency is expected to supercharge algorithmic > stock > market trading, where a difference of a few milliseconds can gain (or lose) > millions of dollars. It is for this reason that a new cable is currently > being laid between the UK and US ? it will cost $300 million and shave > ?just? > six milliseconds off the fastest link currently available. The lower > latency > will also be a boon to other technologies that hinge heavily on the > internet, > such as telemedicine (and teleconferencing) and education. Telephone calls > and live news coverage would also enjoy the significantly lower latency. > Each > of the fiber optic cables will have a capacity in the terabits-per-second > range, which will probably come in handy too. > > Beyond the stock markets, though, the main advantage of the three new > cables > is added redundancy. Currently, almost every cable that lands in Asia goes > through a choke point in the Middle East or the Luzon Strait between the > Philippine and South China seas. If a ship were to drag an anchor across > the > wrong patch of seabed, billions of people could wake up to find themselves > either completely disconnected from the internet or surfing with > dial-up-like > speeds. The three new cables will all come down from the north of Japan, > through the relatively-empty Bering Sea ? and the Arctic Ocean, where each > of > the cables will run for more than 5,000 miles, is one of the > least-trafficked > parts of the world. That said, the cables will still have to be laid > hundreds > of meters below the surface to avoid the tails of roving icebergs. > > The ROTACS cable path > > Each cable will be laid by a pair of ships: an ice breaker that leads the > way, and a cable ship. Until now it has been impossible to lay cables in > the > Arctic Ocean, but the retreat of the Arctic sea ice means that the > Northwest > Passage is now generally ice-free from August to October; a big enough > window > that cable can be laid fairly safely. Existing cable ships (and there > aren?t > many of them) are all outfitted for balmier climes, so all three cables > will > require the use of a polar ice-rated ship that has been retrofitted to > carry > cable-laying gear. > > Read more about the secret world of submarine cables. > > For more information on the Russian Optical Trans-Arctic Submarine Cable > System (ROTACS), check out the Polarnet Project (machine translated). > > The Arctic Fibre and Arctic Link websites have information on the North > American cables. > > [Image credit: New Scientist] > > From jgreco at ns.sol.net Fri Mar 23 07:12:02 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 23 Mar 2012 07:12:02 -0500 (CDT) Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: Message-ID: <201203231212.q2NCC35m073646@aurora.sol.net> > >>> Yes, I find it quite "amusing" that I am paying additional fees on > >>> all of my telecommunications services to subsidize high speed PON > >>> networks in rural bumf*ck while I can't get anything like it in San > >>> Jose, California. > >> That's OK, you're all in the same boat - the subsidized users can't > >> get it either. :) > > So where are these "subsidies" going? > > what a silly question. lining the telcos' pockets. american so called > 'broadband' is a joke and a scam. Yup. I'm always shocked by how naive people are; the telcos did a fantastic job on this front. So few people realize what's actually happened. http://www.newnetworks.com/broadbandscandals.htm This is one of the clearest summaries of how we've been taken for hundreds of billions of dollars by telecom companies that promised to provide the "Information Superhighway"; while it has some clear bias, it is probably the best summarization of how this all went down, and who, why, and how. ... 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 aledm at qix.co.uk Fri Mar 23 07:31:13 2012 From: aledm at qix.co.uk (Aled Morris) Date: Fri, 23 Mar 2012 12:31:13 +0000 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <20120323115345.GF9891@leitl.org> References: <20120323115345.GF9891@leitl.org> Message-ID: On 23 March 2012 11:53, Eugen Leitl wrote: > All three cables are being laid for the same reasons: Redundancy and speed. > As it stands, it takes roughly 230 milliseconds for a packet to go from > London to Tokyo; the new cables will reduce this by 30% to 170ms. This > speed-up will be gained by virtue of a much shorter run: If they could armor the cable sufficiently perhaps they could drill the straigh line path through the Earth's crust (mantle and outer core) and do London-Tokyo in less than 10,000km. Aled From avitkovsky at emea.att.com Fri Mar 23 07:53:02 2012 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Fri, 23 Mar 2012 13:53:02 +0100 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> Message-ID: That is why there's this neutrinos project It's not faster than the speed of light though it can shoot through the Earth and no cables cost involved So far the speed is 0.1 bit per sec Can't wait for the neutrino SFPs :) adam -----Original Message----- From: Aled Morris [mailto:aledm at qix.co.uk] Sent: Friday, March 23, 2012 1:31 PM To: Eugen Leitl Cc: NANOG list Subject: Re: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms On 23 March 2012 11:53, Eugen Leitl wrote: > All three cables are being laid for the same reasons: Redundancy and speed. > As it stands, it takes roughly 230 milliseconds for a packet to go from > London to Tokyo; the new cables will reduce this by 30% to 170ms. This > speed-up will be gained by virtue of a much shorter run: If they could armor the cable sufficiently perhaps they could drill the straigh line path through the Earth's crust (mantle and outer core) and do London-Tokyo in less than 10,000km. Aled From regnauld at nsrc.org Fri Mar 23 08:14:58 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Fri, 23 Mar 2012 13:14:58 +0000 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> Message-ID: <20120323131458.GN6834@macbook.bluepipe.net> Vitkovsky, Adam (avitkovsky) writes: > > Can't wait for the neutrino SFPs :) You know the shipping cost on a 2 light year thick lead SFP ? From leigh.porter at ukbroadband.com Fri Mar 23 08:20:05 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Fri, 23 Mar 2012 13:20:05 +0000 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> Message-ID: > -----Original Message----- > From: Vitkovsky, Adam [mailto:avitkovsky at emea.att.com] > Sent: 23 March 2012 12:57 > To: Aled Morris; Eugen Leitl > Cc: NANOG list > Subject: RE: $1.5 billion: The cost of cutting London-Tokyo latency by > 60ms > > That is why there's this neutrinos project It's not faster than the > speed of light though it can shoot through the Earth and no cables cost > involved > > So far the speed is 0.1 bit per sec > > Can't wait for the neutrino SFPs :) > > adam > Nooo, we just need Interocitors! http://en.wikipedia.org/wiki/Interocitor --- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From mohta at necom830.hpcl.titech.ac.jp Fri Mar 23 08:21:30 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 23 Mar 2012 22:21:30 +0900 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <0B60F7E3-1075-4A26-8BD7-742C63420D22@puck.nether.net> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <4F6BFFE7.3090201@punk.co.nz> <0B60F7E3-1075-4A26-8BD7-742C63420D22@puck.nether.net> Message-ID: <4F6C78DA.2060607@necom830.hpcl.titech.ac.jp> Jared Mauch wrote: > It is already a monopoly. Most places are served by one of > the utilities: power, telephony or cable. He that controls > the outside plant controls your fate. The difference is in how the services can be unbundled. Power is additive (if in phase) that network topology is irrelevant. For telephony, unbundling for DSL at L1 is just fine. So is optical fiber if single star topology is used. WDM PON can still be unbundled at L1. However, with time slotted PON, unbundling must be at L2, which is as expensive as L3, which means there effectively is no unbundling. Or, CLEC may rent a raw fiber at L1 and operate its own PON. However, as CLEC has less customer density to share the fiber than ILEC, CLEC's fiber cost per customer is higher than that of ILEC, which is why PON promotes local monopoly. Masataka Ohta From Valdis.Kletnieks at vt.edu Fri Mar 23 08:47:44 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Mar 2012 09:47:44 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: Your message of "Fri, 23 Mar 2012 12:53:45 +0100." <20120323115345.GF9891@leitl.org> References: <20120323115345.GF9891@leitl.org> Message-ID: <30864.1332510464@turing-police.cc.vt.edu> On Fri, 23 Mar 2012 12:53:45 +0100, Eugen Leitl said: > http://www.extremetech.com/extreme/122989-1-5-billion-the-cost-of-cutting-london-toyko-latency-by-60ms Lower latency is good... > The massive drop in latency is expected to supercharge algorithmic stock > market trading, where a difference of a few milliseconds can gain (or lose) > millions of dollars. But it should be illegal to run a stock market that volatile. This can't end well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From avitkovsky at emea.att.com Fri Mar 23 08:51:13 2012 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Fri, 23 Mar 2012 14:51:13 +0100 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> Message-ID: Or http://en.wikipedia.org/wiki/Ansible That's what came to my mind when I first heard about quantum entanglement just to learn that there's really small chance we could ever use it for communication adam -----Original Message----- From: Leigh Porter [mailto:leigh.porter at ukbroadband.com] Sent: Friday, March 23, 2012 2:20 PM To: Vitkovsky, Adam; Aled Morris; Eugen Leitl Cc: NANOG list Subject: RE: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms > -----Original Message----- > From: Vitkovsky, Adam [mailto:avitkovsky at emea.att.com] > Sent: 23 March 2012 12:57 > To: Aled Morris; Eugen Leitl > Cc: NANOG list > Subject: RE: $1.5 billion: The cost of cutting London-Tokyo latency by > 60ms > > That is why there's this neutrinos project It's not faster than the > speed of light though it can shoot through the Earth and no cables cost > involved > > So far the speed is 0.1 bit per sec > > Can't wait for the neutrino SFPs :) > > adam > Nooo, we just need Interocitors! http://en.wikipedia.org/wiki/Interocitor --- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From bill at herrin.us Fri Mar 23 09:20:48 2012 From: bill at herrin.us (William Herrin) Date: Fri, 23 Mar 2012 10:20:48 -0400 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <4F6C78DA.2060607@necom830.hpcl.titech.ac.jp> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <4F6BFFE7.3090201@punk.co.nz> <0B60F7E3-1075-4A26-8BD7-742C63420D22@puck.nether.net> <4F6C78DA.2060607@necom830.hpcl.titech.ac.jp> Message-ID: 2012/3/23 Masataka Ohta : > Jared Mauch wrote: > >> It is already a monopoly. Most places are served by one of >> the utilities: power, telephony or cable. He that controls >> the outside plant controls your fate. > > The difference is in how the services can be unbundled. > > Power is additive (if in phase) that network topology is > irrelevant. > > For telephony, unbundling for DSL at L1 is just fine. > > So is optical fiber if single star topology is used. > > WDM PON can still be unbundled at L1. > > However, with time slotted PON, unbundling must be > at L2, which is as expensive as L3, which means > there effectively is no unbundling. I strongly disagree. If this were true, there would be no market for MPLS service: folks would simply buy Internet service and run VPNs. If you take my packets off at the first hop and deliver them to a 3rd party provider, I can buy service from that 3rd party with as many IP addresses as I want, I can buy service with BGP routing, I can buy non-Internet services and I can buy bandwidth-hungry services that aren't cost effective when they take a trip through the Internet backbone. Even if the cost for the unbundled L2 circuit was *identical* to the cost of the bundled Internet circuit it would enable a huge range of niche products that aren't practical now. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Fri Mar 23 09:27:57 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Mar 2012 07:27:57 -0700 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <4F6C78DA.2060607@necom830.hpcl.titech.ac.jp> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <4F6BFFE7.3090201@punk.co.nz> <0B60F7E3-1075-4A26-8BD7-742C63420D22@puck.nether.net> <4F6C78DA.2060607@necom830.hpcl.titech.ac.jp> Message-ID: On Mar 23, 2012, at 6:21 AM, Masataka Ohta wrote: > Jared Mauch wrote: > >> It is already a monopoly. Most places are served by one of >> the utilities: power, telephony or cable. He that controls >> the outside plant controls your fate. > > The difference is in how the services can be unbundled. > > Power is additive (if in phase) that network topology is > irrelevant. > > For telephony, unbundling for DSL at L1 is just fine. > > So is optical fiber if single star topology is used. > > WDM PON can still be unbundled at L1. > > However, with time slotted PON, unbundling must be > at L2, which is as expensive as L3, which means > there effectively is no unbundling. > > Or, CLEC may rent a raw fiber at L1 and operate its > own PON. However, as CLEC has less customer density > to share the fiber than ILEC, CLEC's fiber cost per > customer is higher than that of ILEC, which is why > PON promotes local monopoly. It doesn't promote local monopoly if you don't allow the L1 company to provide L2+ services. If the L1 company is required to be independent of and treat all L2+ services companies equally, then, the ILEC, CLEC, et. all have the same cost per customer. Owen From joelja at bogus.com Fri Mar 23 10:16:26 2012 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 23 Mar 2012 16:16:26 +0100 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <30864.1332510464@turing-police.cc.vt.edu> References: <20120323115345.GF9891@leitl.org> <30864.1332510464@turing-police.cc.vt.edu> Message-ID: <4F6C93CA.1070704@bogus.com> On 3/23/12 14:47 , Valdis.Kletnieks at vt.edu wrote: > On Fri, 23 Mar 2012 12:53:45 +0100, Eugen Leitl said: >> http://www.extremetech.com/extreme/122989-1-5-billion-the-cost-of-cutting-london-toyko-latency-by-60ms > > Lower latency is good... > >> The massive drop in latency is expected to supercharge algorithmic stock >> market trading, where a difference of a few milliseconds can gain (or lose) >> millions of dollars. > > But it should be illegal to run a stock market that volatile. This can't end well. Notwithstanding how bad an idea high speed trading from the vantage point of those who don't participate in it, 60ms would place you at a competitive disadvantage to traders that are collocated at or near the exchange, such that if you're engaged in an arbitrage activity between two markets someone can frontrun your front-running. From nick at foobar.org Fri Mar 23 10:52:21 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 23 Mar 2012 15:52:21 +0000 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <4F6C93CA.1070704@bogus.com> References: <20120323115345.GF9891@leitl.org> <30864.1332510464@turing-police.cc.vt.edu> <4F6C93CA.1070704@bogus.com> Message-ID: <4F6C9C35.8080603@foobar.org> On 23/03/2012 15:16, Joel jaeggli wrote: > Notwithstanding how bad an idea high speed trading from the vantage > point of those who don't participate in it, 60ms would place you at a > competitive disadvantage to traders that are collocated at or near the > exchange, such that if you're engaged in an arbitrage activity between > two markets someone can frontrun your front-running. I'd be quite interested in seeing the MTTR for a sub-ice cable break which happened in late october. Nick From brandon at rd.bbc.co.uk Fri Mar 23 10:56:46 2012 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 23 Mar 2012 15:56:46 GMT Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms Message-ID: <201203231556.PAA20909@sunf10.rd.bbc.co.uk> > I'd be quite interested in seeing the MTTR for a sub-ice cable break which > happened in late october. More fun too when we get global warming under control and there's no longer any way to reach it brandon From bzs at world.std.com Fri Mar 23 11:00:59 2012 From: bzs at world.std.com (Barry Shein) Date: Fri, 23 Mar 2012 12:00:59 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> Message-ID: <20332.40507.727674.586329@world.std.com> What about those -- I assume successful -- experiments to fire neutrinos straight through the earth as a communications medium? Not sure what the bandwidth of a neutrino stream is. On March 23, 2012 at 12:31 aledm at qix.co.uk (Aled Morris) wrote: > On 23 March 2012 11:53, Eugen Leitl wrote: > > > All three cables are being laid for the same reasons: Redundancy and speed. > > As it stands, it takes roughly 230 milliseconds for a packet to go from > > London to Tokyo; the new cables will reduce this by 30% to 170ms. This > > speed-up will be gained by virtue of a much shorter run: > > > > > If they could armor the cable sufficiently perhaps they could drill the > straigh line path through the Earth's crust (mantle and outer core) and do > London-Tokyo in less than 10,000km. > > Aled -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From rol at witbe.net Fri Mar 23 11:06:06 2012 From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)) Date: Fri, 23 Mar 2012 17:06:06 +0100 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <4F6C9C35.8080603@foobar.org> References: <20120323115345.GF9891@leitl.org> <30864.1332510464@turing-police.cc.vt.edu> <4F6C93CA.1070704@bogus.com> <4F6C9C35.8080603@foobar.org> Message-ID: <20120323170606.42f6c795@tux.DEF.witbe.net> Hello, On Fri, 23 Mar 2012 15:52:21 +0000 Nick Hilliard wrote: > I'd be quite interested in seeing the MTTR for a sub-ice cable break which > happened in late october. Maybe that's the reason they want to build three with different paths ;) Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jcdill.lists at gmail.com Fri Mar 23 11:57:58 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 23 Mar 2012 09:57:58 -0700 Subject: how to report spam to Yahoo! In-Reply-To: <16118.1332486098@turing-police.cc.vt.edu> References: <20120321132719.GT1574@angus.ind.WPI.EDU> <4F6B8051.7030704@paulgraydon.co.uk> <4F6BDE28.8090508@blakjak.net> <16118.1332486098@turing-police.cc.vt.edu> Message-ID: <4F6CAB96.3050903@gmail.com> On 23/03/12 12:01 AM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 23 Mar 2012 15:21:28 +1300, Mark Foster said: > >> If anyone knows what Yahoo's intentions are in this space, i'd love to >> hear about it. > There's good reason to think that even Yahoo doesn't know what its intentions are. > > http://pandodaily.com/2012/03/16/yahoo-decides-to-fire-its-brightest-tech-minds-facebook-will-gladly-take-them/ Yahoo has long been using Ling Chion themselves, a death by 1000 cuts. (Condolences to all my .net friends who still get paychecks from Yahoo.) jc From bill at herrin.us Fri Mar 23 12:12:08 2012 From: bill at herrin.us (William Herrin) Date: Fri, 23 Mar 2012 13:12:08 -0400 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <4F6BFFE7.3090201@punk.co.nz> <0B60F7E3-1075-4A26-8BD7-742C63420D22@puck.nether.net> <4F6C78DA.2060607@necom830.hpcl.titech.ac.jp> Message-ID: On Fri, Mar 23, 2012 at 10:27 AM, Owen DeLong wrote: > On Mar 23, 2012, at 6:21 AM, Masataka Ohta wrote: >> Jared Mauch wrote: >> >>> It is already a monopoly. Most places are served by one of >>> the utilities: power, telephony or cable. He that controls >>> the outside plant controls your fate. >> >> The difference is in how the services can be unbundled. >> >> Power is additive (if in phase) that network topology is >> irrelevant. >> >> For telephony, unbundling for DSL at L1 is just fine. >> >> So is optical fiber if single star topology is used. >> >> WDM PON can still be unbundled at L1. >> >> However, with time slotted PON, unbundling must be >> at L2, which is as expensive as L3, which means >> there effectively is no unbundling. >> >> Or, CLEC may rent a raw fiber at L1 and operate its >> own PON. However, as CLEC has less customer density >> to share the fiber than ILEC, CLEC's fiber cost per >> customer is higher than that of ILEC, which is why >> PON promotes local monopoly. > > It doesn't promote local monopoly if you don't allow the L1 company to provide L2+ services. > > If the L1 company is required to be independent of and treat > all L2+ services companies equally, then, the ILEC, CLEC, > et. all have the same cost per customer. Hi Owen, Just for grins, I wonder: what is the minimal set of _structural_ requirements that could end the kind of abuses we see from the ILECs without relying on good behavior? The problem with regulatory compulsion is that it restrains the march of technological progress too. Minimum is good. Here's what I'm thinking: 1. Any company which provides more than "5%" of the OSI Layer 1 services in a given locality is prohibited from providing any Layer 7 services except those strictly incidental to the operation of the L1 service (e.g. billing or customer service web sites, internal corporate network). 2. Such a communications infrastructure company may vend L1-L6 services only in units suitable for connecting single customers. For example, they're not allowed to lease "a multi-customer coaxial cable in the King street neighborhood." The service unit is "a dedicated coaxial cable from 44 King street to the head end" or "A dedicated cable channel from 44 King Street to the head end" or "25mbps/25mbps from 44 King strreet to the head end" or "25 mbps / 25 mbps from 44 King Street to 888 King Street". 3. Such a communications infrastructure company is compelled to provide reasonable and non-discriminatory access too all who would interconnect. Charge whatever you want but no quantity or special discounts and if you bill any service provider at the head end of the connection then you bill them all the same. No settlement free peering for this guy while that guy pays. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Fri Mar 23 12:21:10 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Mar 2012 13:21:10 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: Your message of "Fri, 23 Mar 2012 15:56:46 -0000." <201203231556.PAA20909@sunf10.rd.bbc.co.uk> References: <201203231556.PAA20909@sunf10.rd.bbc.co.uk> Message-ID: <3339.1332523270@turing-police.cc.vt.edu> On Fri, 23 Mar 2012 15:56:46 -0000, Brandon Butterworth said: > > I'd be quite interested in seeing the MTTR for a sub-ice cable break which > > happened in late october. > > More fun too when we get global warming under control and there's no > longer any way to reach it Submarines. It's allegedly been done before, and will probably be done again. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From george.herbert at gmail.com Fri Mar 23 12:33:34 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 23 Mar 2012 10:33:34 -0700 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <3339.1332523270@turing-police.cc.vt.edu> References: <201203231556.PAA20909@sunf10.rd.bbc.co.uk> <3339.1332523270@turing-police.cc.vt.edu> Message-ID: On Fri, Mar 23, 2012 at 10:21 AM, wrote: > On Fri, 23 Mar 2012 15:56:46 -0000, Brandon Butterworth said: >> > I'd be quite interested in seeing the MTTR for a sub-ice cable break which >> > happened in late october. >> >> More fun too when we get global warming under control and there's no >> longer any way to reach it > > Submarines. ?It's allegedly been done before, and will probably be done again. No allegedly about it, though it's not officially acknowledged. See Sontag's "Blind Man's Bluff". However, that was in shallow water, where the sub could rest on the seabottom next to the cable and divers could exit and work on the cable outside the sub to tap it. The subs involved can't dive to the depths that the cables in question will be mostly laid at, and those exceed reasonable diver operations depths as well. One could fix this situation, but it would probably have to be a (low end) nuclear power plant and a very custom deep submergence hull, and probably on the order of as expensive as the combined cables cost to lay. Probably easier to run redundant cables and fix it come the next spring... -- -george william herbert george.herbert at gmail.com From marshall.eubanks at gmail.com Fri Mar 23 12:45:15 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Fri, 23 Mar 2012 13:45:15 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> Message-ID: On Fri, Mar 23, 2012 at 8:53 AM, Vitkovsky, Adam wrote: > That is why there's this neutrinos project > It's not faster than the speed of light though it can shoot through the Earth and no cables cost involved > > So far the speed is 0.1 bit per sec > I bet for $ 1.5 billion neutrino communication (anywhere on Earth) to its antipode in about 40 msec one way) could be developed (i.e., the bit rate improved), and I could see some real market advantages to anyone who had access to it, even at 100 kbps type bit rates. Given that, I wouldn't be too surprised to see some physicists and networking people quietly being hired away by an obscure new venture... Regards Marshall > Can't wait for the neutrino SFPs :) > > adam > > -----Original Message----- > From: Aled Morris [mailto:aledm at qix.co.uk] > Sent: Friday, March 23, 2012 1:31 PM > To: Eugen Leitl > Cc: NANOG list > Subject: Re: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms > > On 23 March 2012 11:53, Eugen Leitl wrote: > >> All three cables are being laid for the same reasons: Redundancy and speed. >> As it stands, it takes roughly 230 milliseconds for a packet to go from >> London to Tokyo; the new cables will reduce this by 30% to 170ms. This >> speed-up will be gained by virtue of a much shorter run: > > > > > If they could armor the cable sufficiently perhaps they could drill the > straigh line path through the Earth's crust (mantle and outer core) and do > London-Tokyo in less than 10,000km. > > Aled > From jeroen at mompl.net Fri Mar 23 13:45:56 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 23 Mar 2012 11:45:56 -0700 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <30864.1332510464@turing-police.cc.vt.edu> References: <20120323115345.GF9891@leitl.org> <30864.1332510464@turing-police.cc.vt.edu> Message-ID: <4F6CC4E4.5000005@mompl.net> Valdis.Kletnieks at vt.edu wrote: >> The massive drop in latency is expected to supercharge algorithmic stock >> market trading, where a difference of a few milliseconds can gain (or lose) >> millions of dollars. > > But it should be illegal to run a stock market that volatile. This can't end well. The average consumer gets a 15 minute artificial delay in trading, why not implement for all trades... -- Earthquake Magnitude: 4.8 Date: Friday, March 23, 2012 14:35:31 UTC Location: Tonga Latitude: -16.2478; Longitude: -174.0706 Depth: 119.50 km From cscora at apnic.net Fri Mar 23 13:58:56 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Mar 2012 04:58:56 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201203231858.q2NIwukk006800@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 24 Mar, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 404075 Prefixes after maximum aggregation: 171377 Deaggregation factor: 2.36 Unique aggregates announced to Internet: 195407 Total ASes present in the Internet Routing Table: 40484 Prefixes per ASN: 9.98 Origin-only ASes present in the Internet Routing Table: 32928 Origin ASes announcing only one prefix: 15486 Transit ASes present in the Internet Routing Table: 5438 Transit-only ASes present in the Internet Routing Table: 143 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 32 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 454 Unregistered ASNs in the Routing Table: 221 Number of 32-bit ASNs allocated by the RIRs: 2330 Number of 32-bit ASNs visible in the Routing Table: 2118 Prefixes from 32-bit ASNs in the Routing Table: 5181 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 893 Number of addresses announced to Internet: 2527640720 Equivalent to 150 /8s, 168 /16s and 188 /24s Percentage of available address space announced: 68.2 Percentage of allocated address space announced: 68.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 92.1 Total number of prefixes smaller than registry allocations: 172567 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 98560 Total APNIC prefixes after maximum aggregation: 32033 APNIC Deaggregation factor: 3.08 Prefixes being announced from the APNIC address blocks: 94960 Unique aggregates announced from the APNIC address blocks: 39434 APNIC Region origin ASes present in the Internet Routing Table: 4677 APNIC Prefixes per ASN: 20.30 APNIC Region origin ASes announcing only one prefix: 1235 APNIC Region transit ASes present in the Internet Routing Table: 731 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 167 Number of APNIC addresses announced to Internet: 641283424 Equivalent to 38 /8s, 57 /16s and 53 /24s Percentage of available APNIC address space announced: 81.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 150469 Total ARIN prefixes after maximum aggregation: 75801 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 121859 Unique aggregates announced from the ARIN address blocks: 49895 ARIN Region origin ASes present in the Internet Routing Table: 14936 ARIN Prefixes per ASN: 8.16 ARIN Region origin ASes announcing only one prefix: 5675 ARIN Region transit ASes present in the Internet Routing Table: 1576 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 16 Number of ARIN addresses announced to Internet: 805163776 Equivalent to 47 /8s, 253 /16s and 211 /24s Percentage of available ARIN address space announced: 64.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 101472 Total RIPE prefixes after maximum aggregation: 53082 RIPE Deaggregation factor: 1.91 Prefixes being announced from the RIPE address blocks: 92826 Unique aggregates announced from the RIPE address blocks: 57160 RIPE Region origin ASes present in the Internet Routing Table: 16364 RIPE Prefixes per ASN: 5.67 RIPE Region origin ASes announcing only one prefix: 7977 RIPE Region transit ASes present in the Internet Routing Table: 2638 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1437 Number of RIPE addresses announced to Internet: 502099720 Equivalent to 29 /8s, 237 /16s and 111 /24s Percentage of available RIPE address space announced: 80.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 39258 Total LACNIC prefixes after maximum aggregation: 8148 LACNIC Deaggregation factor: 4.82 Prefixes being announced from the LACNIC address blocks: 39012 Unique aggregates announced from the LACNIC address blocks: 19722 LACNIC Region origin ASes present in the Internet Routing Table: 1576 LACNIC Prefixes per ASN: 24.75 LACNIC Region origin ASes announcing only one prefix: 436 LACNIC Region transit ASes present in the Internet Routing Table: 295 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 17 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 494 Number of LACNIC addresses announced to Internet: 98599560 Equivalent to 5 /8s, 224 /16s and 130 /24s Percentage of available LACNIC address space announced: 65.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8829 Total AfriNIC prefixes after maximum aggregation: 2122 AfriNIC Deaggregation factor: 4.16 Prefixes being announced from the AfriNIC address blocks: 6909 Unique aggregates announced from the AfriNIC address blocks: 2226 AfriNIC Region origin ASes present in the Internet Routing Table: 525 AfriNIC Prefixes per ASN: 13.16 AfriNIC Region origin ASes announcing only one prefix: 163 AfriNIC Region transit ASes present in the Internet Routing Table: 119 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 4 Number of AfriNIC addresses announced to Internet: 31512064 Equivalent to 1 /8s, 224 /16s and 214 /24s Percentage of available AfriNIC address space announced: 47.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2491 11109 992 Korea Telecom (KIX) 17974 1758 503 64 PT TELEKOMUNIKASI INDONESIA 7545 1659 303 90 TPG Internet Pty Ltd 4755 1574 386 160 TATA Communications formerly 9583 1238 95 540 Sify Limited 9829 1207 1025 29 BSNL National Internet Backbo 7552 1167 1062 11 Vietel Corporation 4808 1097 2048 314 CNCGROUP IP network: China169 24560 1014 384 166 Bharti Airtel Ltd., Telemedia 18101 948 130 160 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3378 990 155 Windstream Communications Inc 6389 3372 3807 198 bellsouth.net, inc. 4323 2977 1060 385 Time Warner Telecom 18566 2093 383 179 Covad Communications 1785 1885 680 128 PaeTec Communications, Inc. 20115 1633 1558 628 Charter Communications 22773 1547 2910 111 Cox Communications, Inc. 30036 1402 253 744 Mediacom Communications Corp 7018 1279 9776 833 AT&T WorldNet Services 11492 1165 212 413 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1773 544 16 Corbina telecom 2118 1427 97 13 EUnet/RELCOM Autonomous Syste 15557 1034 2247 55 LDCOM NETWORKS 31148 672 37 9 FreeNet ISP 34984 666 188 174 BILISIM TELEKOM 12479 644 653 56 Uni2 Autonomous System 6830 641 1943 412 UPC Distribution Services 20940 632 203 488 Akamai Technologies European 8551 576 360 81 Bezeq International 3320 532 8442 398 Deutsche Telekom AG Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1807 329 130 TVCABLE BOGOTA 28573 1729 1099 60 NET Servicos de Comunicao S.A 8151 1495 3017 354 UniNet S.A. de C.V. 7303 1351 826 190 Telecom Argentina Stet-France 26615 901 684 29 Tim Brasil S.A. 27947 687 69 111 Telconet S.A 11172 636 91 73 Servicios Alestra S.A de C.V 22047 584 326 15 VTR PUNTO NET S.A. 3816 561 238 98 Empresa Nacional de Telecomun 6503 559 418 65 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1260 958 13 TEDATA 24863 844 274 37 LINKdotNET AS number 6713 489 649 18 Itissalat Al-MAGHRIB 3741 271 923 228 The Internet Solution 15706 227 32 6 Sudatel Internet Exchange Aut 12258 197 28 62 Vodacom Internet Company 24835 178 80 8 RAYA Telecom - Egypt 33776 158 12 20 Starcomms Nigeria Limited 36923 157 20 4 Swift Networks Limited 16637 156 647 81 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 7029 3378 990 155 Windstream Communications Inc 6389 3372 3807 198 bellsouth.net, inc. 4323 2977 1060 385 Time Warner Telecom 4766 2491 11109 992 Korea Telecom (KIX) 18566 2093 383 179 Covad Communications 1785 1885 680 128 PaeTec Communications, Inc. 10620 1807 329 130 TVCABLE BOGOTA 8402 1773 544 16 Corbina telecom 17974 1758 503 64 PT TELEKOMUNIKASI INDONESIA 28573 1729 1099 60 NET Servicos de Comunicao S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3372 3174 bellsouth.net, inc. 4323 2977 2592 Time Warner Telecom 18566 2093 1914 Covad Communications 1785 1885 1757 PaeTec Communications, Inc. 8402 1773 1757 Corbina telecom 17974 1758 1694 PT TELEKOMUNIKASI INDONESIA 10620 1807 1677 TVCABLE BOGOTA 28573 1729 1669 NET Servicos de Comunicao S.A 7545 1659 1569 TPG Internet Pty Ltd 4766 2491 1499 Korea Telecom (KIX) Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 54439 UNALLOCATED 8.25.174.0/24 3356 Level 3 Communicatio 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 23.27.0.0/20 54500 EGIHosting 23.27.16.0/20 54500 EGIHosting Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:28 /11:81 /12:234 /13:458 /14:824 /15:1477 /16:12183 /17:6238 /18:10432 /19:20530 /20:28718 /21:29647 /22:40184 /23:37536 /24:211741 /25:1218 /26:1456 /27:797 /28:167 /29:59 /30:17 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 3038 3378 Windstream Communications Inc 6389 2088 3372 bellsouth.net, inc. 18566 2042 2093 Covad Communications 4323 1808 2977 Time Warner Telecom 8402 1750 1773 Corbina telecom 10620 1704 1807 TVCABLE BOGOTA 30036 1350 1402 Mediacom Communications Corp 11492 1128 1165 Cable One 8452 1070 1260 TEDATA 1785 1066 1885 PaeTec Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:532 2:752 4:14 6:3 8:392 12:1973 13:1 14:600 15:12 16:3 17:7 20:8 23:147 24:1754 27:1244 31:936 32:62 33:2 34:2 36:8 37:295 38:781 40:120 41:3007 42:128 44:3 46:1453 47:3 49:342 50:625 52:13 54:6 55:11 56:3 57:37 58:960 59:493 60:278 61:1205 62:980 63:1992 64:4344 65:2276 66:4826 67:2007 68:1147 69:3185 70:903 71:437 72:1804 74:2705 75:491 76:320 77:965 78:982 79:502 80:1235 81:908 82:656 83:553 84:615 85:1191 86:723 87:915 88:343 89:1612 90:296 91:4632 92:519 93:1490 94:1454 95:1159 96:375 97:386 98:826 99:38 100:6 101:154 103:920 106:64 107:178 108:210 109:1551 110:754 111:900 112:444 113:558 114:630 115:767 116:908 117:730 118:908 119:1205 120:338 121:695 122:1661 123:1095 124:1363 125:1260 128:554 129:190 130:264 131:595 132:173 133:21 134:242 135:63 136:212 137:194 138:275 139:145 140:494 141:241 142:388 143:404 144:500 145:69 146:489 147:243 148:723 149:295 150:157 151:176 152:459 153:171 154:7 155:429 156:213 157:380 158:163 159:521 160:326 161:249 162:343 163:186 164:546 165:392 166:562 167:463 168:859 169:148 170:844 171:123 172:2 173:1836 174:734 175:434 176:461 177:591 178:1289 180:1125 181:73 182:769 183:277 184:441 185:1 186:2137 187:868 188:1147 189:1189 190:5547 192:5993 193:5595 194:4566 195:3640 196:1282 197:183 198:3620 199:4475 200:5767 201:1656 202:8463 203:8596 204:4353 205:2465 206:2804 207:2832 208:4050 209:3687 210:2757 211:1467 212:1965 213:1906 214:872 215:108 216:5091 217:1526 218:538 219:333 220:1230 221:552 222:325 223:326 End of report From george.herbert at gmail.com Fri Mar 23 15:16:59 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 23 Mar 2012 13:16:59 -0700 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> Message-ID: The physics is not conducive to improving the situation a lot. There's probably $1.5 billion in the ground already in neutrino detectors; the total combined detector bit rate is pretty poor. One experiment looking at neutrinos coming off the Fermilab accelerator had 473 million accelerator pulses with under 1.1 million detected neutrinos. On Fri, Mar 23, 2012 at 10:45 AM, Marshall Eubanks wrote: > On Fri, Mar 23, 2012 at 8:53 AM, Vitkovsky, Adam > wrote: >> That is why there's this neutrinos project >> It's not faster than the speed of light though it can shoot through the Earth and no cables cost involved >> >> So far the speed is 0.1 bit per sec >> > > I bet for $ 1.5 billion neutrino communication (anywhere on Earth) to > its antipode in about 40 msec one way) could be > developed (i.e., the bit rate improved), and I could see some real > market advantages to anyone who had access to it, even > at 100 kbps type bit rates. > > Given that, I wouldn't be too surprised to see some physicists and > networking people quietly being hired away by an > obscure new venture... > > Regards > Marshall > >> Can't wait for the neutrino SFPs :) >> >> adam >> >> -----Original Message----- >> From: Aled Morris [mailto:aledm at qix.co.uk] >> Sent: Friday, March 23, 2012 1:31 PM >> To: Eugen Leitl >> Cc: NANOG list >> Subject: Re: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms >> >> On 23 March 2012 11:53, Eugen Leitl wrote: >> >>> All three cables are being laid for the same reasons: Redundancy and speed. >>> As it stands, it takes roughly 230 milliseconds for a packet to go from >>> London to Tokyo; the new cables will reduce this by 30% to 170ms. This >>> speed-up will be gained by virtue of a much shorter run: >> >> >> >> >> If they could armor the cable sufficiently perhaps they could drill the >> straigh line path through the Earth's crust (mantle and outer core) and do >> London-Tokyo in less than 10,000km. >> >> Aled >> > -- -george william herbert george.herbert at gmail.com From jra at baylink.com Fri Mar 23 16:10:40 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 23 Mar 2012 17:10:40 -0400 (EDT) Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <4F6BFFE7.3090201@punk.co.nz> Message-ID: <9038704.7989.1332537040687.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Kris Price" > > I believe Google agrees with me. :-) > > Are they? Last I saw they were building out a layer 3 network -- no > wholesale access -- did this change? No, you're right; that was me being flippant. ("He thinks flippant is the name of a dolphin...") Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Fri Mar 23 16:13:58 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 23 Mar 2012 17:13:58 -0400 (EDT) Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <20120323131458.GN6834@macbook.bluepipe.net> Message-ID: <21108690.7991.1332537238533.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Phil Regnauld" > Subject: Re: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms > Vitkovsky, Adam (avitkovsky) writes: > > > > Can't wait for the neutrino SFPs :) > > You know the shipping cost on a 2 light year thick lead SFP ? Ah... *here's* the Whacky Weekend thread. I was wondering where it was. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From Valdis.Kletnieks at vt.edu Fri Mar 23 16:14:17 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Mar 2012 17:14:17 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: Your message of "Fri, 23 Mar 2012 13:16:59 -0700." References: <20120323115345.GF9891@leitl.org> Message-ID: <13579.1332537257@turing-police.cc.vt.edu> On Fri, 23 Mar 2012 13:16:59 -0700, George Herbert said: > The physics is not conducive to improving the situation a lot. > > There's probably $1.5 billion in the ground already in neutrino > detectors; the total combined detector bit rate is pretty poor. One > experiment looking at neutrinos coming off the Fermilab accelerator > had 473 million accelerator pulses with under 1.1 million detected > neutrinos. Note that each pulse was probably millions or even billions of neutrinos, so the detection rate was even worse than you'd think. I saw a statistic that every second, 50 trillion neutrinos pass through your body. And the number that will interact is well into the single digits. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From simon at darkmere.gen.nz Fri Mar 23 16:44:28 2012 From: simon at darkmere.gen.nz (Simon Lyall) Date: Sat, 24 Mar 2012 10:44:28 +1300 (NZDT) Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <13579.1332537257@turing-police.cc.vt.edu> References: <20120323115345.GF9891@leitl.org> <13579.1332537257@turing-police.cc.vt.edu> Message-ID: You guys joke but here is n little article from last week on the current state of Neutrino communications: http://www.economist.com/node/21550242 "The neutrinos themselves are created by smashing bunches of protons into a target made of graphite. They are detected roughly 1km away by researchers [..] . By modulating the pulses of protons the group was able to send a message in binary that, when translated, read ?neutrino?. " -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From bonomi at mail.r-bonomi.com Fri Mar 23 16:57:44 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 23 Mar 2012 16:57:44 -0500 (CDT) Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <4F6CC4E4.5000005@mompl.net> Message-ID: <201203232157.q2NLviuK063387@mail.r-bonomi.com> Jeroen van Aart wrote: > Valdis.Kletnieks at vt.edu wrote: > >> The massive drop in latency is expected to supercharge algorithmic stock > >> market trading, where a difference of a few milliseconds can gain (or lose) > >> millions of dollars. > > > > But it should be illegal to run a stock market that volatile. This can't end well. > > The average consumer gets a 15 minute artificial delay in trading, why > not implement for all trades... Virtually any consumer can get true real-time trading data if they're willing to pay some relatively modest fees for that access -- Last I knew, the most expensive 'real-time' fee charged by any exchange was under $200/mo. For everything traded on that exchange. For anybody doing short-term, 'tactical', trading, that is a "petty cash" expense. Imposing the 15-minute delay on 'everybody', would simply give the 'floor traders' the -exclusive' edge on those trading strategies. From cidr-report at potaroo.net Fri Mar 23 17:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Mar 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201203232200.q2NM01oh074091@wattle.apnic.net> BGP Update Report Interval: 15-Mar-12 -to- 22-Mar-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7029 81049 4.0% 44.6 -- WINDSTREAM - Windstream Communications Inc 2 - AS8402 72347 3.6% 34.1 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS786 72205 3.6% 353.9 -- JANET The JNT Association 4 - AS9829 42734 2.1% 62.3 -- BSNL-NIB National Internet Backbone 5 - AS24560 32672 1.6% 32.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 6 - AS12479 26875 1.3% 131.7 -- UNI2-AS France Telecom Espana SA 7 - AS28683 25791 1.3% 437.1 -- BENINTELECOM 8 - AS32528 22765 1.1% 7588.3 -- ABBOTT Abbot Labs 9 - AS5800 21139 1.1% 72.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 10 - AS6066 12856 0.6% 6428.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 11 - AS17974 11016 0.6% 8.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 12 - AS26615 10992 0.6% 14.0 -- Tim Celular S.A. 13 - AS7552 10764 0.5% 9.4 -- VIETEL-AS-AP Vietel Corporation 14 - AS9583 8846 0.4% 11.7 -- SIFY-AS-IN Sify Limited 15 - AS11456 8074 0.4% 25.6 -- NUVOX - Windstream Nuvox, Inc. 16 - AS36926 7871 0.4% 3935.5 -- CKL1-ASN 17 - AS16637 7807 0.4% 56.2 -- MTNNS-AS 18 - AS38735 7705 0.4% 226.6 -- GDS-AS-VN Global Data Service Joint Stock Company 19 - AS13277 7636 0.4% 3818.0 -- HP-MS HP-MS Autonomous System 20 - AS5089 7540 0.4% 47.4 -- NTL Virgin Media Limited TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 22765 1.1% 7588.3 -- ABBOTT Abbot Labs 2 - AS6066 12856 0.6% 6428.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 3 - AS36926 7871 0.4% 3935.5 -- CKL1-ASN 4 - AS13277 7636 0.4% 3818.0 -- HP-MS HP-MS Autonomous System 5 - AS26646 1983 0.1% 1983.0 -- TRAVELCLICKCORP1 - TravelCLICK Inc. 6 - AS17370 1944 0.1% 1944.0 -- MCAFEE-COM - McAfee, Inc. 7 - AS29933 3244 0.2% 1622.0 -- OFF-CAMPUS-TELECOMMUNICATIONS - Off Campus Telecommunications 8 - AS8657 1354 0.1% 1354.0 -- CPRM CPRM Autonomous System 9 - AS23266 1085 0.1% 1085.0 -- COMCAST-23266 - Comcast Cable Communications 10 - AS55665 981 0.1% 981.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 11 - AS8163 898 0.0% 898.0 -- METROTEL REDES S.A. 12 - AS57767 891 0.0% 891.0 -- RTTC-AS Federal State-owned Enterprise Russian Television and Radio Broadcasting Network 13 - AS16935 845 0.0% 845.0 -- KSC-NETWORKS - Kingland Systems Corp. 14 - AS13224 3912 0.2% 652.0 -- NAIROBINET 15 - AS4 4296 0.2% 576.0 -- Maria Irma Salazar 16 - AS37396 613 0.0% 613.0 -- ocean-five 17 - AS2728 2332 0.1% 583.0 -- APARTMENTCOMMUNICATIONPARTNERTSLLC - Apartment Communication Partners, LLC 18 - AS28861 516 0.0% 516.0 -- CARR-FUTURES-LONDON-AS Carr Futures Inc London 19 - AS48632 512 0.0% 512.0 -- BTS-HOLDINGS-PLC BTS Holdings PLC 20 - AS48018 512 0.0% 512.0 -- MTB-COMPUTER-SERVICES-LTD MTB Computer Services Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/24 11381 0.5% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/24 11381 0.5% AS32528 -- ABBOTT Abbot Labs 3 - 204.234.0.0/17 10973 0.5% AS7029 -- WINDSTREAM - Windstream Communications Inc 4 - 122.161.0.0/16 9991 0.5% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 5 - 182.64.0.0/16 8769 0.4% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 6 - 62.36.252.0/22 8407 0.4% AS12479 -- UNI2-AS France Telecom Espana SA 7 - 150.225.0.0/16 6430 0.3% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 8 - 204.29.239.0/24 6426 0.3% AS6066 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 9 - 62.36.249.0/24 6306 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 62.36.241.0/24 5920 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 11 - 62.36.210.0/24 5651 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 12 - 217.15.120.0/22 5173 0.2% AS56696 -- ASLIQUID-MPLS Liquid Telecommunications Ltd 13 - 41.223.56.0/24 3936 0.2% AS36926 -- CKL1-ASN 14 - 41.223.57.0/24 3935 0.2% AS36926 -- CKL1-ASN 15 - 194.209.13.0/24 3818 0.2% AS13277 -- HP-MS HP-MS Autonomous System 16 - 194.209.211.0/24 3818 0.2% AS13277 -- HP-MS HP-MS Autonomous System 17 - 202.153.174.0/24 3456 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 18 - 67.214.235.0/24 3238 0.1% AS29933 -- OFF-CAMPUS-TELECOMMUNICATIONS - Off Campus Telecommunications 19 - 194.63.9.0/24 3209 0.1% AS1273 -- CW Cable and Wireless Worldwide plc 20 - 109.124.113.0/24 2346 0.1% AS20632 -- PETERSTAR-AS OJSC MegaFon Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 23 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Mar 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201203232200.q2NM00rM074086@wattle.apnic.net> This report has been generated at Fri Mar 23 21:12:33 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 16-03-12 403663 234431 17-03-12 404038 234465 18-03-12 403961 234676 19-03-12 404155 234832 20-03-12 404462 235058 21-03-12 404718 235841 22-03-12 404981 235791 23-03-12 405211 237354 AS Summary 40590 Number of ASes in routing system 16973 Number of ASes announcing only one prefix 3419 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 111387168 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'). --- 23Mar12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 406982 237361 169621 41.7% All ASes AS6389 3372 201 3171 94.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3419 1853 1566 45.8% WINDSTREAM - Windstream Communications Inc AS4766 2495 1015 1480 59.3% KIXS-AS-KR Korea Telecom AS4323 2978 1499 1479 49.7% TWTC - tw telecom holdings, inc. AS22773 1547 120 1427 92.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS2118 1427 14 1413 99.0% RELCOM-AS OOO "NPO Relcom" AS18566 2093 705 1388 66.3% COVAD - Covad Communications Co. AS28573 1705 485 1220 71.6% NET Servicos de Comunicao S.A. AS4755 1573 415 1158 73.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1889 802 1087 57.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 1807 815 992 54.9% Telmex Colombia S.A. AS7552 1167 213 954 81.7% VIETEL-AS-AP Vietel Corporation AS8402 1714 778 936 54.6% CORBINA-AS OJSC "Vimpelcom" AS7303 1351 440 911 67.4% Telecom Argentina S.A. AS26615 901 29 872 96.8% Tim Celular S.A. AS8151 1494 683 811 54.3% Uninet S.A. de C.V. AS18101 949 164 785 82.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1097 345 752 68.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9394 887 208 679 76.6% CRNET CHINA RAILWAY Internet(CRNET) AS17974 1758 1100 658 37.4% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS3356 1092 454 638 58.4% LEVEL3 Level 3 Communications AS7545 1660 1026 634 38.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS30036 1402 773 629 44.9% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS17676 686 75 611 89.1% GIGAINFRA Softbank BB Corp. AS19262 996 401 595 59.7% VZGNI-TRANSIT - Verizon Online LLC AS15557 1034 455 579 56.0% LDCOMNET Societe Francaise du Radiotelephone S.A AS3549 1000 433 567 56.7% GBLX Global Crossing Ltd. AS22561 985 419 566 57.5% DIGITAL-TELEPORT - Digital Teleport Inc. AS4804 654 95 559 85.5% MPX-AS Microplex PTY LTD AS22047 584 31 553 94.7% VTR BANDA ANCHA S.A. Total 45716 16046 29670 64.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 37.202.48.0/21 AS6823 CCCB 3C1B Telekomunikasyon ve Internet Hiz. San. ve Tic. Ltd. Sti 37.202.128.0/17 AS34714 OPTICNET OPTICNET - SERV S.R.L. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 66.129.0.0/19 AS3901 ARRAKIS - Higher Technology Services 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS14208 74.91.49.0/24 AS14208 74.91.50.0/24 AS14208 74.91.51.0/24 AS14208 74.91.52.0/24 AS14208 74.91.53.0/24 AS14208 74.91.54.0/24 AS14208 74.91.55.0/24 AS14208 74.91.56.0/24 AS14208 74.91.57.0/24 AS14208 74.91.58.0/24 AS14208 74.91.59.0/24 AS14208 74.91.60.0/24 AS14208 74.91.61.0/24 AS14208 74.91.62.0/24 AS14208 74.91.63.0/24 AS14208 98.159.96.0/20 AS46975 109.233.240.0/21 AS50400 EST-ASN Elite System Technics LTD. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 190.108.32.0/24 AS52308 AGUAS DEL COLORADO SAPEM 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.86.32.0/20 AS18255 BRISBANE-AP Brisbane City Council 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.122.134.0/24 AS38615 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.133.224.0/19 AS4323 TWTC - tw telecom holdings, inc. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From mohta at necom830.hpcl.titech.ac.jp Fri Mar 23 17:13:54 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 24 Mar 2012 07:13:54 +0900 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <4F6BFFE7.3090201@punk.co.nz> <0B60F7E3-1075-4A26-8BD7-742C63420D22@puck.nether.net> <4F6C78DA.2060607@necom830.hpcl.titech.ac.jp> Message-ID: <4F6CF5A2.9080702@necom830.hpcl.titech.ac.jp> William Herrin wrote: >> However, with time slotted PON, unbundling must be >> at L2, which is as expensive as L3, which means >> there effectively is no unbundling. > > I strongly disagree. If this were true, there would be no market for > MPLS service: folks would simply buy Internet service and run VPNs. You agree with me. MPLS at L2 sucks because it is as expensive as, but less capable than, IP at L3. > If you take my packets off at the first hop and deliver them to a 3rd > party provider, If you are saying delivery as IP, your local provider is an ISP with monopoly. > Even if the cost for the unbundled L2 circuit was *identical* to the > cost of the bundled Internet circuit it would enable a huge range of > niche products that aren't practical now. See the reality of your example of MPLS. Masataka Ohta From george.herbert at gmail.com Fri Mar 23 17:34:42 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 23 Mar 2012 15:34:42 -0700 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> <13579.1332537257@turing-police.cc.vt.edu> Message-ID: >From the abstract: "The link achieved a decoded data rate of 0.1 bits/sec with a bit error rate of 1% over a distance of 1.035 km, including 240 m of earth." http://arxiv.org/pdf/1203.2847v1.pdf For practical communications, at longer distances, you probably lose beam intensity as a 1/R^2 function (the neutrino beam isn't precisely collimated), so 1,000 km away it will be 1 millionth as strong, or 0.0000001 baud, 1 bit per 115.74 days. At 2,000 km it would be less than 1 bit per year. Sure you want to do this? 8-) On Fri, Mar 23, 2012 at 2:44 PM, Simon Lyall wrote: > > You guys joke but here is n little article from last week on the current > state of Neutrino communications: > > http://www.economist.com/node/21550242 > > "The neutrinos themselves are created by smashing bunches of protons into a > target made of graphite. They are detected roughly 1km away by researchers > [..] . By modulating the pulses of protons the group was able to send a > message in binary that, when translated, read ?neutrino?. ? " > > > -- > Simon Lyall ?| ?Very Busy ?| ?Web: http://www.darkmere.gen.nz/ > "To stay awake all night adds a day to your life" - Stilgar | eMT. -- -george william herbert george.herbert at gmail.com From morrowc.lists at gmail.com Fri Mar 23 18:52:25 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 23 Mar 2012 19:52:25 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <4F6C9C35.8080603@foobar.org> References: <20120323115345.GF9891@leitl.org> <30864.1332510464@turing-police.cc.vt.edu> <4F6C93CA.1070704@bogus.com> <4F6C9C35.8080603@foobar.org> Message-ID: On Fri, Mar 23, 2012 at 11:52 AM, Nick Hilliard wrote: > On 23/03/2012 15:16, Joel jaeggli wrote: >> Notwithstanding how bad an idea high speed trading from the vantage >> point of those who don't participate in it, 60ms would place you at a >> competitive disadvantage to traders that are collocated at or near the >> exchange, such that if you're engaged in an arbitrage activity between >> two markets someone can frontrun your front-running. > > I'd be quite interested in seeing the MTTR for a sub-ice cable break which > happened in late october. hopefully it's harder to drag an anchor then ... so it won't happen? :) From tvhawaii at shaka.com Fri Mar 23 19:18:26 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Fri, 23 Mar 2012 14:18:26 -1000 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> Message-ID: <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> Randy Bush wrote: > what a silly question. lining the telcos' pockets. american so called > 'broadband' is a joke and a scam. > > randy Really. This is from the Governor's "Hawaii Broadband Initiative" speedtest website: "The indication of above average or below average is based on a comparison of the actual test result to the current NTIA definition of broadband which is 768 kbps download and 200 kbps upload. Any test result above the NTIA definition is considered above average, and any result below is considered below average." From gbonser at seven.com Fri Mar 23 19:32:37 2012 From: gbonser at seven.com (George Bonser) Date: Sat, 24 Mar 2012 00:32:37 +0000 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D4081C@RWC-MBX1.corp.seven.com> > If they could armor the cable sufficiently perhaps they could drill the > straigh line path through the Earth's crust (mantle and outer core) and > do London-Tokyo in less than 10,000km. > > Aled I suggested this once when it was decided that the latency from California to the UK was too high and that I should reduce it. The company wouldn't go for it, though. G From gbonser at seven.com Fri Mar 23 19:36:50 2012 From: gbonser at seven.com (George Bonser) Date: Sat, 24 Mar 2012 00:36:50 +0000 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <4F6C9C35.8080603@foobar.org> References: <20120323115345.GF9891@leitl.org> <30864.1332510464@turing-police.cc.vt.edu> <4F6C93CA.1070704@bogus.com> <4F6C9C35.8080603@foobar.org> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D4083C@RWC-MBX1.corp.seven.com> > > I'd be quite interested in seeing the MTTR for a sub-ice cable break > which happened in late october. > > Nick Well, you won't have to worry about people dragging anchor across the cable. Other than earthquake or volcanic eruption, I can't imagine what would damage a cable that time of year in that location. It would be interesting if they put some sensors on those cables to monitor ocean salinity and temperature at those depths, too. From mpalmer at hezmatt.org Fri Mar 23 20:50:22 2012 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 24 Mar 2012 12:50:22 +1100 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> References: <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> Message-ID: <20120324015022.GX17225@hezmatt.org> On Fri, Mar 23, 2012 at 02:18:26PM -1000, Michael Painter wrote: > Really. This is from the Governor's "Hawaii Broadband Initiative" speedtest website: > > "The indication of above average or below average is based on a > comparison of the actual test result to the current NTIA definition > of broadband which is 768 kbps download and 200 kbps upload. Any > test result above the NTIA definition is considered above average, > and any result below is considered below average." Just one more nail in the coffin of the word "average". - Matt -- I seem to have my life in reverse. When I was a wee'un, it seemed perfectly normal that one could pick up the phone and speak to anybody else in the world who also has a phone. Now I'm older and more experienced, I'm amazed that this could possibly work. -- Peter Corlett, in the Monastery From paul at paulgraydon.co.uk Fri Mar 23 20:54:35 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 23 Mar 2012 15:54:35 -1000 Subject: last mile, regulatory incentives, etc In-Reply-To: <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> Message-ID: <4F6D295B.3050208@paulgraydon.co.uk> On 03/23/2012 02:18 PM, Michael Painter wrote: > Randy Bush wrote: >> what a silly question. lining the telcos' pockets. american so called >> 'broadband' is a joke and a scam. >> >> randy > > Really. This is from the Governor's "Hawaii Broadband Initiative" > speedtest website: > > "The indication of above average or below average is based on a > comparison of the actual test result to the current NTIA definition of > broadband which is 768 kbps download and 200 kbps upload. Any test > result above the NTIA definition is considered above average, and any > result below is considered below average." > To be fair to the initiative at least its goal is for universal access to 1Gbps by 2018, something they term 'ultra-high-speed' (not sure where that definition comes from): http://hawaii.gov/gov/broadband-policy-outline/ Paul From marshall.eubanks at gmail.com Fri Mar 23 21:11:01 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Fri, 23 Mar 2012 22:11:01 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <13579.1332537257@turing-police.cc.vt.edu> References: <20120323115345.GF9891@leitl.org> <13579.1332537257@turing-police.cc.vt.edu> Message-ID: On Fri, Mar 23, 2012 at 5:14 PM, wrote: > On Fri, 23 Mar 2012 13:16:59 -0700, George Herbert said: >> The physics is not conducive to improving the situation a lot. >> >> There's probably $1.5 billion in the ground already in neutrino >> detectors; the total combined detector bit rate is pretty poor. ?One >> experiment looking at neutrinos coming off the Fermilab accelerator >> had 473 million accelerator pulses with under 1.1 million detected >> neutrinos. > > Note that each pulse was probably millions or even billions of neutrinos, so > the detection rate was even worse than you'd think. ?I saw a statistic that > every second, 50 trillion neutrinos pass through your body. ?And the number > that will interact is well into the single digits. > Small detection numbers are not, per se, fatal to communication. What fraction of the photons generated by a GPS satellite are captured by your phone? The neutrino interaction rate increases with neutrino energy, and sea water makes a good neutrino detector. You could, for a billion dollars, do a LOT better than they did. By the way, here is the original paper : http://arxiv.org/pdf/1203.2847v1.pdf Regards Marshall From owen at delong.com Fri Mar 23 22:22:38 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Mar 2012 20:22:38 -0700 Subject: last mile, regulatory incentives, etc In-Reply-To: <4F6D295B.3050208@paulgraydon.co.uk> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> <4F6D295B.3050208@paulgraydon.co.uk> Message-ID: <7066124B-04B7-4221-A7D7-CEC021066D18@delong.com> On Mar 23, 2012, at 6:54 PM, Paul Graydon wrote: > On 03/23/2012 02:18 PM, Michael Painter wrote: >> Randy Bush wrote: >>> what a silly question. lining the telcos' pockets. american so called >>> 'broadband' is a joke and a scam. >>> >>> randy >> >> Really. This is from the Governor's "Hawaii Broadband Initiative" speedtest website: >> >> "The indication of above average or below average is based on a comparison of the actual test result to the current NTIA definition of broadband which is 768 kbps download and 200 kbps upload. Any test result above the NTIA definition is considered above average, and any result below is considered below average." >> > To be fair to the initiative at least its goal is for universal access to 1Gbps by 2018, something they term 'ultra-high-speed' (not sure where that definition comes from): http://hawaii.gov/gov/broadband-policy-outline/ > > Paul Yep... That's I think the problem... Back when the initiative documents were written, 1Gbps was ulra-high-speed and 768/200k was average broadband. There is no provision for the terms to shift over time, so, the document gets more and more out of date as time goes by. I suspect that by 2018, 1Gbps will probably be above average, but, not by as much as the document probably thinks. Owen From Valdis.Kletnieks at vt.edu Fri Mar 23 22:35:22 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 23 Mar 2012 23:35:22 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: Your message of "Fri, 23 Mar 2012 14:18:26 -1000." <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> Message-ID: <10688.1332560122@turing-police.cc.vt.edu> On Fri, 23 Mar 2012 14:18:26 -1000, Michael Painter said: > "The indication of above average or below average is based on a comparison of the actual test result to the current NTIA > definition of broadband which is 768 kbps download and 200 kbps upload. Any test result above the NTIA definition is > considered above average, and any result below is considered below average." That's the national definition of "broadband" that we're stuck with. To show how totally cooked the books are, consider that when they compute "percent of people with access to residential broadband", they do it on a per-county basis - and if even *one* subscriber in one corner of the county has broadband, the entire county counts. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mysidia at gmail.com Fri Mar 23 22:59:23 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 23 Mar 2012 22:59:23 -0500 Subject: last mile, regulatory incentives, etc In-Reply-To: <4F6BA49C.7040004@necom830.hpcl.titech.ac.jp> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <4F6BA49C.7040004@necom830.hpcl.titech.ac.jp> Message-ID: 2012/3/22 Masataka Ohta : > William Herrin wrote: > The entire optics is shared by all the subscribers sharing > a fiber. > Thus, the problem is collision avoidance of simultaneous > transmission, which makes PON time shared with L2 protocols. Hm... i'm thinking one transceiver might malfunction and get stuck/frozen in the "transmitting pulse" state, thus making collision avoidance impossible, kind of like a shorted NIC on a shared bus topology LAN, if just one subscriber's equipment happens to have the right kind of failure, and that's neglecting the possibility of intentional attack. Passive optically-shared fiber networks don't sound so hot in that case. >> So, you share fiber by having one guy control one wavelength (color, >> e.g. red) and another guy control another wavelength (e.g. blue). > That's not a usual PON but WDN PON. -- -JH From marcelplug at gmail.com Fri Mar 23 23:08:11 2012 From: marcelplug at gmail.com (Marcel Plug) Date: Sat, 24 Mar 2012 00:08:11 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <10688.1332560122@turing-police.cc.vt.edu> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> <10688.1332560122@turing-police.cc.vt.edu> Message-ID: This article from arstechnica is right on topic. Its about how the city of Amsterdam built an open-access fibre network. It seems to me this is the right way to do it, or at least very close to the right way.. http://arstechnica.com/tech-policy/news/2010/03/how-amsterdam-was-wired-for-open-access-fiber.ars -Marcel On Fri, Mar 23, 2012 at 11:35 PM, wrote: > On Fri, 23 Mar 2012 14:18:26 -1000, Michael Painter said: > >> "The indication of above average or below average is based on a comparison of the actual test result to the current NTIA >> definition of broadband which is 768 kbps download and 200 kbps upload. Any test result above the NTIA definition is >> considered above average, and any result below is considered below average." > > That's the national definition of "broadband" that we're stuck with. ?To show > how totally cooked the books are, consider that when they compute "percent of > people with access to residential broadband", they do it on a per-county basis > - and if even *one* subscriber in one corner of the county has broadband, the > entire county counts. > From george.herbert at gmail.com Fri Mar 23 23:51:37 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 23 Mar 2012 21:51:37 -0700 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> <13579.1332537257@turing-police.cc.vt.edu> Message-ID: On Fri, Mar 23, 2012 at 7:11 PM, Marshall Eubanks wrote: > On Fri, Mar 23, 2012 at 5:14 PM, ? wrote: >> On Fri, 23 Mar 2012 13:16:59 -0700, George Herbert said: >>> The physics is not conducive to improving the situation a lot. >>> >>> There's probably $1.5 billion in the ground already in neutrino >>> detectors; the total combined detector bit rate is pretty poor. ?One >>> experiment looking at neutrinos coming off the Fermilab accelerator >>> had 473 million accelerator pulses with under 1.1 million detected >>> neutrinos. >> >> Note that each pulse was probably millions or even billions of neutrinos, so >> the detection rate was even worse than you'd think. ?I saw a statistic that >> every second, 50 trillion neutrinos pass through your body. ?And the number >> that will interact is well into the single digits. >> > > Small detection numbers are not, per se, fatal to communication. What > fraction of the photons generated by a GPS satellite are captured by > your phone? Much higher fraction than with neutrinos. Remember their MFPs are measured in light-years... > The neutrino interaction rate increases with neutrino energy, and sea > water makes a good neutrino detector. You could, for a billion > dollars, do > a LOT better than they did. On the detector end, sure. On the transmitter end, it's just not a well collimated beam due to physics, and no matter how hard you try the generation of neutrinos is a low-efficiency process. > By the way, here is the original paper : http://arxiv.org/pdf/1203.2847v1.pdf Yep. I meant to include the URL but forgot. -- -george william herbert george.herbert at gmail.com From tvhawaii at shaka.com Sat Mar 24 00:36:51 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Fri, 23 Mar 2012 19:36:51 -1000 Subject: last mile, regulatory incentives, etc References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> <4F6D295B.3050208@paulgraydon.co.uk> Message-ID: <6AABADDE33C24B32A62F3BE60B582C29@owner59e1f1502> Paul Graydon wrote: > To be fair to the initiative at least its goal is for universal access > to 1Gbps by 2018, something they term 'ultra-high-speed' (not sure where > that definition comes from): http://hawaii.gov/gov/broadband-policy-outline/ > > Paul A lofty goal to be sure, the biggest challenge of which may be to get those bits to/from where folks want them to go. RRDWDM? (Really, really, DWDM) From Valdis.Kletnieks at vt.edu Sat Mar 24 00:37:27 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 24 Mar 2012 01:37:27 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: Your message of "Sat, 24 Mar 2012 00:08:11 -0400." References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> <10688.1332560122@turing-police.cc.vt.edu> Message-ID: <15000.1332567447@turing-police.cc.vt.edu> On Sat, 24 Mar 2012 00:08:11 -0400, Marcel Plug said: > This article from arstechnica is right on topic. Its about how the > city of Amsterdam built an open-access fibre network. It seems to me > this is the right way to do it, or at least very close to the right > way.. Cue somebody denouncing projects like this done for the common good as socialism in 5.. 4.. 3.. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From joelja at bogus.com Sat Mar 24 00:56:23 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sat, 24 Mar 2012 06:56:23 +0100 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <4F6CC4E4.5000005@mompl.net> References: <20120323115345.GF9891@leitl.org> <30864.1332510464@turing-police.cc.vt.edu> <4F6CC4E4.5000005@mompl.net> Message-ID: <4F6D6207.6050801@bogus.com> On 3/23/12 19:45 , Jeroen van Aart wrote: > Valdis.Kletnieks at vt.edu wrote: >>> The massive drop in latency is expected to supercharge algorithmic stock >>> market trading, where a difference of a few milliseconds can gain (or >>> lose) >>> millions of dollars. >> >> But it should be illegal to run a stock market that volatile. This >> can't end well. > > The average consumer gets a 15 minute artificial delay in trading, why in data, not trading... and that really only applies to the sort of free feeds you're getting. Even the average consumer gets their ecn cleared market order filled in seconds inclusive of order entry. > not implement for all trades... From joelja at bogus.com Sat Mar 24 01:00:13 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sat, 24 Mar 2012 07:00:13 +0100 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D4081C@RWC-MBX1.corp.seven.com> References: <20120323115345.GF9891@leitl.org> <596B74B410EE6B4CA8A30C3AF1A155EA09D4081C@RWC-MBX1.corp.seven.com> Message-ID: <4F6D62ED.7030309@bogus.com> On 3/24/12 01:32 , George Bonser wrote: >> If they could armor the cable sufficiently perhaps they could drill the >> straigh line path through the Earth's crust (mantle and outer core) and >> do London-Tokyo in less than 10,000km. Current record depth of a borehole is under 12,500 meters which is a bit short of the goal. >> Aled > > I suggested this once when it was decided that the latency from California to the UK was too high and that I should reduce it. The company wouldn't go for it, though. Bandwidth delay product has undone many a well laid plan. > G > > > From joly at punkcast.com Sat Mar 24 03:23:52 2012 From: joly at punkcast.com (Joly MacFie) Date: Sat, 24 Mar 2012 04:23:52 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <4F6D62ED.7030309@bogus.com> References: <20120323115345.GF9891@leitl.org> <596B74B410EE6B4CA8A30C3AF1A155EA09D4081C@RWC-MBX1.corp.seven.com> <4F6D62ED.7030309@bogus.com> Message-ID: Hey $1.5Bn would get you less than half of Spotify right now, so it seems like a good deal. -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From nick at foobar.org Sat Mar 24 05:09:47 2012 From: nick at foobar.org (Nick Hilliard) Date: Sat, 24 Mar 2012 10:09:47 +0000 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D4081C@RWC-MBX1.corp.seven.com> References: <20120323115345.GF9891@leitl.org> <596B74B410EE6B4CA8A30C3AF1A155EA09D4081C@RWC-MBX1.corp.seven.com> Message-ID: <4F6D9D6B.9070305@foobar.org> On 24/03/2012 00:32, George Bonser wrote: > I suggested this once when it was decided that the latency from > California to the UK was too high and that I should reduce it. The > company wouldn't go for it, though. I assume they had a practical alternative to your proposition? Perhaps making light go faster? Nick From joseph.snyder at gmail.com Sat Mar 24 06:47:11 2012 From: joseph.snyder at gmail.com (Joseph Snyder) Date: Sat, 24 Mar 2012 07:47:11 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> <10688.1332560122@turing-police.cc.vt.edu> Message-ID: Any details on how much this cost, maybe I just missed it in the article. 40k. It sounds interesting but in the US this would only make sense in cities and most people don't live in MDUs. Where I live a lot of peoples driveways are a mile or two long. Marcel Plug wrote: This article from arstechnica is right on topic. Its about how the city of Amsterdam built an open-access fibre network. It seems to me this is the right way to do it, or at least very close to the right way.. http://arstechnica.com/tech-policy/news/2010/03/how-amsterdam-was-wired-for-open-access-fiber.ars -Marcel On Fri, Mar 23, 2012 at 11:35 PM, wrote: > On Fri, 23 Mar 2012 14:18:26 -1000, Michael Painter said: > >> "The indication of above average or below average is based on a comparison of the actual test result to the current NTIA >> definition of broadband which is 768 kbps download and 200 kbps upload. Any test result above the NTIA definition is >> considered above average, and any result below is considered below average." > > That's the national definition of "broadband" that we're stuck with. To show > how totally cooked the books are, consider that when they compute "percent of > people with access to residential broadband", they do it on a per-county basis > - and if even *one* subscriber in one corner of the county has broadband, the > entire county counts. > From marshall.eubanks at gmail.com Sat Mar 24 07:36:55 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Sat, 24 Mar 2012 08:36:55 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> <13579.1332537257@turing-police.cc.vt.edu> Message-ID: On Sat, Mar 24, 2012 at 12:51 AM, George Herbert wrote: > On Fri, Mar 23, 2012 at 7:11 PM, Marshall Eubanks > wrote: >> On Fri, Mar 23, 2012 at 5:14 PM, ? wrote: >>> On Fri, 23 Mar 2012 13:16:59 -0700, George Herbert said: >>>> The physics is not conducive to improving the situation a lot. >>>> >>>> There's probably $1.5 billion in the ground already in neutrino >>>> detectors; the total combined detector bit rate is pretty poor. ?One >>>> experiment looking at neutrinos coming off the Fermilab accelerator >>>> had 473 million accelerator pulses with under 1.1 million detected >>>> neutrinos. >>> >>> Note that each pulse was probably millions or even billions of neutrinos, so >>> the detection rate was even worse than you'd think. ?I saw a statistic that >>> every second, 50 trillion neutrinos pass through your body. ?And the number >>> that will interact is well into the single digits. >>> >> >> Small detection numbers are not, per se, fatal to communication. What >> fraction of the photons generated by a GPS satellite are captured by >> your phone? > > Much higher fraction than with neutrinos. ?Remember their MFPs are > measured in light-years... Actually, at the energy they used it's more like 0.1 light seconds. > >> The neutrino interaction rate increases with neutrino energy, and sea >> water makes a good neutrino detector. You could, for a billion >> dollars, do >> a LOT better than they did. > > On the detector end, sure. ?On the transmitter end, it's just not a > well collimated beam due to physics, and no matter how hard you try > the generation of neutrinos is a low-efficiency process. > The beam width was < 2 meters after 1 km, equivalent to ~12 km after 1 Earth radius. The beam can be made tighter by going to higher energy and using more or better post collision focusing magnets. The KM3NeT detector in the Mediterranean will be more sensitive, 3 km across and will cost order 200 million euros. With better magnets, the existing beam could be made to be the size of that detector at 1 Earth radius. So, existing technology could certainly communicate across the Atlantic or the Pacific. The real question, again, would be what it would take to get the bit rate up. Regards Marshall >> By the way, here is the original paper : http://arxiv.org/pdf/1203.2847v1.pdf > > Yep. ?I meant to include the URL but forgot. > > > > -- > -george william herbert > george.herbert at gmail.com From joseph.snyder at gmail.com Sat Mar 24 08:06:15 2012 From: joseph.snyder at gmail.com (Joseph Snyder) Date: Sat, 24 Mar 2012 09:06:15 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> <10688.1332560122@turing-police.cc.vt.edu> Message-ID: <75c3a6a8-d695-4632-8f70-43ba717cf41e@email.android.com> Lol too early in the morning, that much for so few, but if you are going to govt fund copper replacement, it's probably the way to go. Not sure how costly that would be in the US since even in the cities there are a lot of duplexes. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Joseph Snyder wrote: Any details on how much this cost, maybe I just missed it in the article. 40k. It sounds interesting but in the US this would only make sense in cities and most people don't live in MDUs. Where I live a lot of peoples driveways are a mile or two long. Marcel Plug wrote: This article from arstechnica is right on topic. Its about how the city of Amsterdam built an open-access fibre network. It seems to me this is the right way to do it, or at least very close to the right way.. http://arstechnica.com/tech-policy/news/2010/03/how-amsterdam-was-wired-for-open-access-fiber.ars -Marcel On Fri, Mar 23, 2012 at 11:35 PM, wrote: > On Fri, 23 Mar 2012 14:18:26 -1000, Michael Painter said: > >> "The indication of above average or below average is based on a comparison of the actual test result to the current NTIA >> definition of broadband which is 768 kbps download and 200 kbps upload. Any test result above the NTIA definition is >> considered above average, and any result below is considered below average." > > That's the national definition of "broadband" that we're stuck with. To show > how totally cooked the books are, consider that when they compute "percent of > people with access to residential broadband", they do it on a per-county basis > - and if even *one* subscriber in one corner of the county has broadband, the > entire county counts. > From mohta at necom830.hpcl.titech.ac.jp Sat Mar 24 08:17:11 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 24 Mar 2012 22:17:11 +0900 Subject: last mile, regulatory incentives, etc In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <4F6BA49C.7040004@necom830.hpcl.titech.ac.jp> Message-ID: <4F6DC957.2060907@necom830.hpcl.titech.ac.jp> Jimmy Hess wrote: >> The entire optics is shared by all the subscribers sharing >> a fiber. >> Thus, the problem is collision avoidance of simultaneous >> transmission, which makes PON time shared with L2 protocols. > > Hm... i'm thinking one transceiver might malfunction and get > stuck/frozen in the "transmitting pulse" state, thus making > collision avoidance impossible, kind of like a shorted NIC on a shared > bus topology LAN, if just one subscriber's equipment happens to have > the right kind of failure, and that's neglecting the possibility of > intentional attack. That is a real problem harming healthy development of broadband Internet. > Passive optically-shared fiber networks don't sound so hot in that case. Worse, as optical fibers are so cheap these days, SS (single star) costs less than PON, because PON requires more complicated wiring. Even worse, if people are deceived to recognize PON cheaper than SS, it is impossible to have optical Internet in sparsely populated area where optical Internet with SS is possible. It can be said that PON was promoted by ILECs only to keep their monopoly. Masataka Ohta From joseph.snyder at gmail.com Sat Mar 24 08:34:07 2012 From: joseph.snyder at gmail.com (Joseph Snyder) Date: Sat, 24 Mar 2012 09:34:07 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <75c3a6a8-d695-4632-8f70-43ba717cf41e@email.android.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> <10688.1332560122@turing-police.cc.vt.edu> <75c3a6a8-d695-4632-8f70-43ba717cf41e@email.android.com> Message-ID: For those who didn't Google it. http://www.ftthcouncil.org/en/knowledge-center/case-studies/amsterdam-city-fiber-project-analysis -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Joseph Snyder wrote: Lol too early in the morning, that much for so few, but if you are going to govt fund copper replacement, it's probably the way to go. Not sure how costly that would be in the US since even in the cities there are a lot of duplexes. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Joseph Snyder wrote: Any details on how much this cost, maybe I just missed it in the article. 40k. It sounds interesting but in the US this would only make sense in cities and most people don't live in MDUs. Where I live a lot of peoples driveways are a mile or two long. Marcel Plug wrote: This article from arstechnica is right on topic. Its about how the city of Amsterdam built an open-access fibre network. It seems to me this is the right way to do it, or at least very close to the right way.. http://arstechnica.com/tech-policy/news/2010/03/how-amsterdam-was-wired-for-open-access-fiber.ars -Marcel On Fri, Mar 23, 2012 at 11:35 PM, wrote: > On Fri, 23 Mar 2012 14:18:26 -1000, Michael Painter said: > >> "The indication of above average or below average is based on a comparison of the actual test result to the current NTIA >> definition of broadband which is 768 kbps download and 200 kbps upload. Any test result above the NTIA definition is >> considered above average, and any result below is considered below average." > > That's the national definition of "broadband" that we're stuck with. To show > how totally cooked the books are, consider that when they compute "percent of > people with access to residential broadband", they do it on a per-county basis > - and if even *one* subscriber in one corner of the county has broadband, the > entire county counts. > From owen at delong.com Sat Mar 24 09:13:39 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Mar 2012 07:13:39 -0700 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <75c3a6a8-d695-4632-8f70-43ba717cf41e@email.android.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> <10688.1332560122@turing-police.cc.vt.edu> <75c3a6a8-d695-4632-8f70-43ba717cf41e@email.android.com> Message-ID: We've been funding it for years without getting it because of the stupid way in which it has been funded. I suggest you look into USF in more detail. Owen On Mar 24, 2012, at 6:06 AM, Joseph Snyder wrote: > Lol too early in the morning, that much for so few, but if you are going to govt fund copper replacement, it's probably the way to go. Not sure how costly that would be in the US since even in the cities there are a lot of duplexes. > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > Joseph Snyder wrote: > > Any details on how much this cost, maybe I just missed it in the article. 40k. It sounds interesting but in the US this would only make sense in cities and most people don't live in MDUs. Where I live a lot of peoples driveways are a mile or two long. > > Marcel Plug wrote: > > This article from arstechnica is right on topic. Its about how the > city of Amsterdam built an open-access fibre network. It seems to me > this is the right way to do it, or at least very close to the right > way.. > > http://arstechnica.com/tech-policy/news/2010/03/how-amsterdam-was-wired-for-open-access-fiber.ars > > -Marcel > > On Fri, Mar 23, 2012 at 11:35 PM, wrote: >> On Fri, 23 Mar 2012 14:18:26 -1000, Michael Painter said: >> >>> "The indication of above average or below average is based on a comparison of the actual test result to the current NTIA >>> definition of broadband which is 768 kbps download and 200 kbps upload. Any test result above the NTIA definition is >>> considered above average, and any result below is considered below average." >> >> That's the national definition of "broadband" that we're stuck with. To show >> how totally cooked the books are, consider that when they compute "percent of >> people with access to residential broadband", they do it on a per-county basis >> - and if even *one* subscriber in one corner of the county has broadband, the >> entire county counts. >> From joseph.snyder at gmail.com Sat Mar 24 10:30:32 2012 From: joseph.snyder at gmail.com (Joseph Snyder) Date: Sat, 24 Mar 2012 11:30:32 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> <10688.1332560122@turing-police.cc.vt.edu> <75c3a6a8-d695-4632-8f70-43ba717cf41e@email.android.com> Message-ID: USF is more of a free for all get ISPs to build in 80% of the locations that nobody would build in their right mind vs a mini monopoly model for l2 that I equate this with. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Owen DeLong wrote: We've been funding it for years without getting it because of the stupid way in which it has been funded. I suggest you look into USF in more detail. Owen On Mar 24, 2012, at 6:06 AM, Joseph Snyder wrote: > Lol too early in the morning, that much for so few, but if you are going to govt fund copper replacement, it's probably the way to go. Not sure how costly that would be in the US since even in the cities there are a lot of duplexes. > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > Joseph Snyder wrote: > > Any details on how much this cost, maybe I just missed it in the article. 40k. It sounds interesting but in the US this would only make sense in cities and most people don't live in MDUs. Where I live a lot of peoples driveways are a mile or two long. > > Marcel Plug wrote: > > This article from arstechnica is right on topic. Its about how the > city of Amsterdam built an open-access fibre network. It seems to me > this is the right way to do it, or at least very close to the right > way.. > > http://arstechnica.com/tech-policy/news/2010/03/how-amsterdam-was-wired-for-open-access-fiber.ars > > -Marcel > > On Fri, Mar 23, 2012 at 11:35 PM, wrote: >> On Fri, 23 Mar 2012 14:18:26 -1000, Michael Painter said: >> >>> "The indication of above average or below average is based on a comparison of the actual test result to the current NTIA >>> definition of broadband which is 768 kbps download and 200 kbps upload. Any test result above the NTIA definition is >>> considered above average, and any result below is considered below average." >> >> That's the national definition of "broadband" that we're stuck with. To show >> how totally cooked the books are, consider that when they compute "percent of >> people with access to residential broadband", they do it on a per-county basis >> - and if even *one* subscriber in one corner of the county has broadband, the >> entire county counts. >> From frnkblk at iname.com Sat Mar 24 13:41:43 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 24 Mar 2012 13:41:43 -0500 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> Message-ID: <02af01cd09ed$c288b250$479a16f0$@iname.com> Around the 2004 timeframe the RBOCs were having a discussion with the FCC, basically saying that if the FCC did not apply unbundling to their fiber builds they would build fiber, and that if the FCC did apply unbundling rules they would not. The FCC wanted fiber deployed, so they withheld applying unbundling rules. Frank -----Original Message----- From: Jimmy Hess [mailto:mysidia at gmail.com] Sent: Wednesday, March 21, 2012 8:47 PM To: John T. Yocum Cc: nanog at nanog.org Subject: Re: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) On Wed, Mar 21, 2012 at 2:28 PM, John T. Yocum wrote: > VZ wants to get rid of their copper plant. It's expensive to maintain, and As opposed to fiber plant which is indestructible and cheap to maintain? Well, if VZ owns the copper, if it's not being used to provide a service, and the price of copper keeps going up, it's only a matter of time before VZ should want to take their bits of unused cable back. How useful is leaving a dormant loop in place just because someone might theoretically want it someday? Seems like a waste for VZ not to reclaim it so it can be recycled/put to good use. > it requires that they sell service to competitors. Once they've disconnected > their customers from it, they can just eliminate the copper plant. POTS You sure the regulations won't eventually be updated to apply some rules to whatever POTS is being replaced with? Possibly years before they could finish eliminating their copper plant, which doesn't likely happen until the pricing allows POTS customers to get FiOS delivery installed for free as a cheaper alternative to POTS delivery. -- -JH From owen at delong.com Sat Mar 24 13:47:40 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Mar 2012 11:47:40 -0700 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <02af01cd09ed$c288b250$479a16f0$@iname.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <02af01cd09ed$c288b250$479a16f0$@iname.com> Message-ID: <616FD43B-9DFC-4033-8AEC-247A570F767F@delong.com> Right, but a better approach would have been for the FCC to say "If you don't build fiber, you won't keep getting USF money." The FCC failed to look at the public interest and got rolled by the RBOCs again. Owen On Mar 24, 2012, at 11:41 AM, Frank Bulk wrote: > Around the 2004 timeframe the RBOCs were having a discussion with the FCC, > basically saying that if the FCC did not apply unbundling to their fiber > builds they would build fiber, and that if the FCC did apply unbundling > rules they would not. The FCC wanted fiber deployed, so they withheld > applying unbundling rules. > > Frank > > -----Original Message----- > From: Jimmy Hess [mailto:mysidia at gmail.com] > Sent: Wednesday, March 21, 2012 8:47 PM > To: John T. Yocum > Cc: nanog at nanog.org > Subject: Re: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) > > On Wed, Mar 21, 2012 at 2:28 PM, John T. Yocum > wrote: >> VZ wants to get rid of their copper plant. It's expensive to maintain, and > > As opposed to fiber plant which is indestructible and cheap to maintain? > > > Well, if VZ owns the copper, if it's not being used to provide a > service, and the price of > copper keeps going up, it's only a matter of time before VZ should > want to take their bits of unused cable back. How useful is leaving > a dormant loop in place just because someone might theoretically want > it someday? > > Seems like a waste for VZ not to reclaim it so it can be recycled/put > to good use. > >> it requires that they sell service to competitors. Once they've > disconnected >> their customers from it, they can just eliminate the copper plant. POTS > > You sure the regulations won't eventually be updated to apply some > rules to whatever POTS is being replaced with? Possibly years > before they could finish eliminating their copper plant, which > doesn't likely happen until the pricing allows POTS customers to get FiOS > delivery installed for free as a cheaper alternative to POTS delivery. > > -- > -JH > > > From cfillekes at gmail.com Sat Mar 24 14:41:01 2012 From: cfillekes at gmail.com (C. A. Fillekes) Date: Sat, 24 Mar 2012 14:41:01 -0500 Subject: is sbcglobal throttling Cuban traffic? Message-ID: Reports from around the country are that traceroutes through sbcglobal (in Austin, Houston and NJ) are failing with timeout to havanatimes.org -- yet when we go in through TOR or Comcast or using overseas services, their routing is just fine. What gives? From frnkblk at iname.com Sat Mar 24 14:41:25 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 24 Mar 2012 14:41:25 -0500 Subject: last mile, regulatory incentives, etc In-Reply-To: <4F6C0FED.4070100@snappydsl.net> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <4F6C0FED.4070100@snappydsl.net> Message-ID: <02f001cd09f6$19733d80$4c59b880$@iname.com> It's easy to ridicule the outliers, but the reality is that without USF the majority of rural America that has Internet connectivity today wouldn't be online. Yes, the price-cap carriers didn't do much in rural America, but that's because there was little economic incentive to do so. Rate-of-return carriers had the incentive to invest to earn a return, and they did that. Many of the independents serve small communities and there is an element of local pride in providing good service, and coops seek to serve their members well, and do the same thing. BTW, the FCC in their recent USF/ICC rulings has put a cap on the funding per customer per year to $5K, so you won't see any more of the examples listed in the Connected Planet article. Frank -----Original Message----- From: Faisal Imtiaz [mailto:faisal at snappydsl.net] Sent: Friday, March 23, 2012 12:54 AM To: nanog at nanog.org Subject: Re: last mile, regulatory incentives, etc So do a quick research on USF and see who gets paid from it... Please don't read this if you have just eaten.. you might puke .. http://connectedplanetonline.com/commentary/real-story-usf-data-071510/ http://republicans.energycommerce.house.gov/Media/file/PDFs/2011usf/Response toQuestion1.pdf If you have more time.. read these for your enjoyment.. http://energycommerce.house.gov/news/PRArticle.aspx?NewsID=8737 Then one can understand how come folks like Century Tel can gobble up Qwest, Savvis, Sprint, and a few others rather quickly !!! I believe the current USF contribution is about 19% !!! Faisal Imtiaz Snappy Internet& Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 3/23/2012 1:37 AM, Randy Bush wrote: >>>> Yes, I find it quite "amusing" that I am paying additional fees on >>>> all of my telecommunications services to subsidize high speed PON >>>> networks in rural bumf*ck while I can't get anything like it in San >>>> Jose, California. >>> That's OK, you're all in the same boat - the subsidized users can't >>> get it either. :) >> So where are these "subsidies" going? > what a silly question. lining the telcos' pockets. american so called > 'broadband' is a joke and a scam. > > randy > > From frnkblk at iname.com Sat Mar 24 14:42:36 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 24 Mar 2012 14:42:36 -0500 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <20120322185915.GA25250@luke.xen.prgmr.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <20120322185915.GA25250@luke.xen.prgmr.com> Message-ID: <02f101cd09f6$440fbfa0$cc2f3ee0$@iname.com> There's more than just the cost of fiber -- there's also the cost of locating and taxes. Any maintenance if there's cuts and the costs if you need to move the fiber for a project. I've been many times where you were, frustrated that I didn't know the dark fiber options for a potential opportunity, but you have to remind yourself don't have a *right* to know where *private* fiber is. It's not just the physical property, the lack of documentation is a competitive advantage. Frank -----Original Message----- From: Luke S. Crawford [mailto:lsc at prgmr.com] Sent: Thursday, March 22, 2012 1:59 PM To: nanog at nanog.org Subject: Re: last mile, regulatory incentives, etc (was: att fiber, et al) I'm trying to do just that right now, actually. 55 s. market to 250 Stockton in San Jose. I dono if it's five thousand feet, but it's not twice that. The cheapest fiber pair I can rent from someone else I've found is $5K/month; the cheapest build-out I've found is $150K, so even if I'm only using one pair in that, if I can get money at anything like a reasonable interest rate, if I plan on sticking around more than 5 years it makes sense to lay new fiber. Which is weird, as this is probably one of the densest masses of existing fiber in the world, going from a 'center of the universe' data center to a minor data center. The big problem here, I think, is that it's quite difficult to figure out who has what fiber where, and even once you know who owns it, to find out who to talk to at a company that might know what 'dark fiber' is, much less know how much they might rent it to you for. I spent several hours last month on the phone with XO and I kept getting redirected to someone trying to sell me a T1. I've got other projects right now, but once I'm done with that, I'm going to be spending a bunch of time pestering the PUC and other people that might know who owns fiber between here and there. But from the amount of time it takes to just find someone at those companies that even knows what dark fiber is? I think I might be better off putting in the effort to do whatever regulatory red tape is required to own fiber in the ground. So yeah; really? in my corner of the world, the problem is the same problem you see everywhere else in this industry. Any useful information is guarded jealously. In this case, where does the fiber run? I mean, I have pretty good maps of the Santa Clara municipal fiber network; but the private networks are impossible. From frnkblk at iname.com Sat Mar 24 14:42:48 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 24 Mar 2012 14:42:48 -0500 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> Message-ID: <02f201cd09f6$4b251a60$e16f4f20$@iname.com> How many munis serve the rural like they do the urban? In the vast majority of cases the munis end up doing what ILECs only wish they could do -- serve the most profitable customers. Frank -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Thursday, March 22, 2012 12:52 PM To: NANOG Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) Oh, it's *much* worse than that, John. The *right*, long term solution to all of these problems is for municipalities to do the fiber build, properly engineered, and even subbed out to a contractor to build and possibly operate... offering *only* layer 1 service at wholesale. Any comer can light up each city's pop, and offer retail service over the FTTH fiber to that customer at whatever rate they like, and the city itself doesn't offer layer 2 or 3 service at all. High-speed optical data *is* the next natural monopoly, after power and water/sewer delivery, and it's time to just get over it and do it right. As you might imagine, this environment -- one where the LEC doesn't own the physical plant -- scares the ever-lovin' daylights out of Verizon (among others), so much so that they *have gotten it made illegal* in several states, and they're lobbying to expand that footprint. See, among other sites: http://www.muninetworks.org/ As you might imagine, I am a fairly strong proponent of muni layer 1 -- or even layer 2, where the municipality supplies (matching) ONTs, and services have to fit over GigE -- fiber delivery of high-speed data service. I believe Google agrees with me. :-) Cheers, -- jra Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From caldcv at gmail.com Sat Mar 24 14:45:48 2012 From: caldcv at gmail.com (Chris) Date: Sat, 24 Mar 2012 15:45:48 -0400 Subject: is sbcglobal throttling Cuban traffic? In-Reply-To: References: Message-ID: 4 te-9-1-ur01.northeast.fl.jacksvil.comcast.net (68.86.168.61) 914.785 ms 916.728 ms 917.681 ms 5 te-0-5-0-0-ar02.southside.fl.jacksvil.comcast.net (68.86.168.69) 1018.016 ms 1111.482 ms * 6 te-1-1-0-1-cr01.denver.co.ibone.comcast.net (68.86.95.189) 1324.773 ms 852.297 ms 523.514 ms 7 pos-1-15-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.86.197) 554.344 ms 571.771 ms 573.842 ms 8 pos-4-11-0-0-cr01.ashburn.va.ibone.comcast.net (68.86.88.229) 574.285 ms 577.734 ms 579.187 ms 9 pos-0-3-0-0-pe01.ashburn.va.ibone.comcast.net (68.86.86.142) 578.127 ms 578.586 ms 588.765 ms 10 80.150.169.197 (80.150.169.197) 594.101 ms 594.680 ms 595.115 ms 11 f-ed3-i.F.DE.NET.DTAG.DE (62.154.14.190) 598.569 ms * * 12 xe-3-0-1.atuin.as6724.net (62.157.249.198) 446.536 ms 907.048 ms 1233.020 ms 13 xe-10-3-0.morla.as6724.net (81.169.144.33) 1239.439 ms 1273.024 ms 1274.223 ms 14 te4-2.fiddlersriddle.as6724.net (81.169.144.34) 1275.161 ms 1275.986 ms 1276.924 ms 15 w9c.rzone.de (81.169.145.156) 1277.882 ms 1279.583 ms 1297.408 ms I've never had Denver jump before Atlanta but it seems your issue is overseas in Europe and not Cuba. -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From frnkblk at iname.com Sat Mar 24 14:49:48 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 24 Mar 2012 14:49:48 -0500 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <4F6BFFE7.3090201@punk.co.nz> <0B60F7E3-1075-4A26-8BD7-742C63420D22@puck.nether.net> <4F6C78DA.2060607@necom830.hpcl.titech.ac.jp> Message-ID: <02f301cd09f7$45dc73e0$d1955ba0$@iname.com> >From my own experience in my $DAYJOB, separating capital decisions at the L1 and L2 layers would end up adding cost. As mentioned elsewhere, GPON and similar shared medium approaches do not lend themselves well to structural separation. The most practical approach is dark fiber runs from the customer to as few centralized places as possible. The CLEC would co-locate their equipment at those centralized places. The CLEC is then free to use ActiveE, GPON, whatever-the-next-gen-of-PON. Structural separation works best when the cost to build to a customer are roughly the same. Wherever there's significant disparaties, those will be exploited and people will overbuild to the highest-margin/lowest cost customers to avoid the averaged cost of L1 network. Frank -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, March 23, 2012 9:28 AM To: Masataka Ohta Cc: nanog at nanog.org Subject: Re: Muni Fiber (was: Re: last mile, regulatory incentives, etc) It doesn't promote local monopoly if you don't allow the L1 company to provide L2+ services. If the L1 company is required to be independent of and treat all L2+ services companies equally, then, the ILEC, CLEC, et. all have the same cost per customer. Owen From cfillekes at gmail.com Sat Mar 24 15:06:20 2012 From: cfillekes at gmail.com (C. A. Fillekes) Date: Sat, 24 Mar 2012 15:06:20 -0500 Subject: is sbcglobal throttling Cuban traffic? In-Reply-To: References: Message-ID: Again, the common element in the timeouts seem to be sbcglobal _not_ comcast. $ traceroute havanatimes.org traceroute to havanatimes.org (81.169.145.156), 64 hops max, 40 byte packets ... 3 108-85-132-3.lightspeed.austtx.sbcglobal.net (108.85.132.3) 27.394 ms 23.129 ms 23.454 ms 4 75.8.128.82 (75.8.128.82) 24.498 ms * * 5 75.8.128.26 (75.8.128.26) 26.134 ms 23.820 ms 23.206 ms 6 * * * 7 12.83.68.141 (12.83.68.141) 23.601 ms 22.763 ms 23.122 ms 8 * * * 9 * * * 10 * * * ... and this just in, from Houston. traceroute to havanatimes.org (81.169.145.156), 64 hops max, 40 byte packets [skipping my internal firewalls] 3 99-116-244-2.lightspeed.hstntx.sbcglobal.net (99.116.244.2) 15.049 ms 13.259 ms 15.272 ms 4 * 71.144.128.132 (71.144.128.132) 12.526 ms 13.189 ms 5 * * * 6 12.83.36.1 (12.83.36.1) 14.793 ms 12.83.86.93 (12.83.86.93) 12.256 ms 10.375 ms 7 * * * 8 * * * 9 * * * 10 * * * ... from the same site in Houston, but going through Comcast: It's fine from Comcast in Houston. 3 te-5-6-ur01.royalton.tx.houston.comcast.net (68.85.250.97) 8.520 ms 9.263 ms 7.439 ms [skipping a zillion internal comcast hops] 11 80.150.169.197 (80.150.169.197) 52.592 ms 58.171 ms 61.386 ms 12 f-ed3-i.F.DE.NET.DTAG.DE (62.154.14.190) 148.515 ms 198.582 ms 134.282 ms 13 xe-3-0-1.atuin.as6724.net (62.157.249.198) 135.565 ms 135.564 ms 135.349 ms 14 xe-10-3-0.morla.as6724.net (81.169.144.33) 136.368 ms 137.703 ms 136.021 ms 15 te4-2.fiddlersriddle.as6724.net (81.169.144.34) 138.861 ms 137.925 ms 139.025 ms 16 w9c.rzone.de (81.169.145.156) 139.272 ms 138.359 ms 140.591 ms Friends in Alaska and NJ can get through (but not if they use sbcglobal routers as their first hop). Fargo, ND times out as well. On Sat, Mar 24, 2012 at 2:41 PM, C. A. Fillekes wrote: > Reports from around the country are that traceroutes through sbcglobal > (in Austin, Houston and NJ) are failing with timeout to > havanatimes.org -- yet when we go in through TOR or Comcast or using > overseas services, their routing is just fine. ?What gives? From jhellenthal at dataix.net Sat Mar 24 15:24:57 2012 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Sat, 24 Mar 2012 16:24:57 -0400 Subject: is sbcglobal throttling Cuban traffic? In-Reply-To: References: Message-ID: <20120324202457.GC30901@DataIX.net> >From this location it looks aweful... and I am on a sbcglobal line. Console> traceroute -a havanatimes.org ...[INTERNAL]... 3 [AS0] adsl-99-181-143-254.dsl.klmzmi.sbcglobal.net (99.181.143.254) 19.510 ms 27.116 ms 19.387 ms 4 [AS7132] dist2-vlan60.klmzmi.ameritech.net (67.36.55.243) 19.482 ms 18.178 ms 19.939 ms 5 [AS7132] bb2-10g4-0.klmzmi.sbcglobal.net (151.164.38.108) 19.897 ms 26.879 ms 19.883 ms 6 * * * ... It stops there not even a ping. On Sat, Mar 24, 2012 at 02:41:01PM -0500, C. A. Fillekes wrote: > Reports from around the country are that traceroutes through sbcglobal > (in Austin, Houston and NJ) are failing with timeout to > havanatimes.org -- yet when we go in through TOR or Comcast or using > overseas services, their routing is just fine. What gives? -- ;s =; From randy at psg.com Sat Mar 24 15:39:15 2012 From: randy at psg.com (Randy Bush) Date: Sat, 24 Mar 2012 21:39:15 +0100 Subject: is sbcglobal throttling Cuban traffic? In-Reply-To: <20120324202457.GC30901@DataIX.net> References: <20120324202457.GC30901@DataIX.net> Message-ID: from paris :) rair.psg.com:/Users/randy> traceroute -a havanatimes.org traceroute to havanatimes.org (81.169.145.156), 64 hops max, 52 byte packets 1 [AS8151] 192.168.2.1 (192.168.2.1) 37.716 ms 79.322 ms 1.435 ms 2 * * * 3 * * * 4 * * * 5 * [AS12670] reverse.completel.net (213.244.0.225) 28.126 ms 28.912 ms 6 [AS12670] reverse.completel.net (213.244.0.226) 37.078 ms 37.996 ms 30.224 ms 7 [AS12670] reverse.completel.net (213.244.0.230) 33.167 ms 39.857 ms 31.280 ms 8 [AS12670] reverse.completel.net (213.244.0.242) 72.771 ms 53.188 ms 43.874 ms 9 [AS1299] prs-b6-link.telia.net (213.248.93.41) 46.922 ms 48.623 ms 45.503 ms 10 [AS1299] prs-bb2-link.telia.net (80.91.246.56) 39.203 ms [AS1299] prs-bb1-link.telia.net (80.91.246.54) 50.166 ms [AS1299] prs-bb2-link.telia.net (80.91.246.56) 45.533 ms 11 [AS1299] ffm-bb1-link.telia.net (80.91.245.100) 73.785 ms [AS1299] ffm-bb1-link.telia.net (80.91.245.102) 57.945 ms [AS1299] ffm-bb1-link.telia.net (80.91.245.100) 55.093 ms 12 [AS1299] ffm-b7-link.telia.net (80.91.254.93) 75.182 ms [AS1299] ffm-b7-link.telia.net (80.91.247.75) 47.499 ms [AS1299] ffm-b7-link.telia.net (80.91.254.253) 48.189 ms 13 [AS1299] xe-10-2-0.morla.as6724.net (213.248.94.78) 52.179 ms 48.434 ms 105.630 ms 14 [AS6724] te4-2.fiddlersriddle.as6724.net (81.169.144.34) 83.134 ms 60.910 ms 60.176 ms 15 [AS6724] w9c.rzone.de (81.169.145.156) 57.661 ms 67.233 ms 77.722 ms From jeff.tantsura at ericsson.com Sat Mar 24 17:36:33 2012 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Sat, 24 Mar 2012 18:36:33 -0400 Subject: is sbcglobal throttling Cuban traffic? In-Reply-To: References: <20120324202457.GC30901@DataIX.net> Message-ID: <15E7A32F-5D6C-4C7A-AD7E-F8B017887034@ericsson.com> 81.169.144 belongs to a German company based in Berlin :) Regards, Jeff On Mar 24, 2012, at 13:39, "Randy Bush" wrote: > 81.169.145.156 From cfillekes at gmail.com Sat Mar 24 17:53:20 2012 From: cfillekes at gmail.com (C. A. Fillekes) Date: Sat, 24 Mar 2012 17:53:20 -0500 Subject: why is sbcglobal throttling havanatimes.org ? Message-ID: Curious that so many routers owned by the same US company would all be timing out on havanatimes.org with the server located in a former eastern bloc nation. Oh well, it's back now. Cold war over. On Sat, Mar 24, 2012 at 5:36 PM, Jeff Tantsura wrote: > 81.169.144 belongs to a German company based in Berlin :) > > Regards, > Jeff > > On Mar 24, 2012, at 13:39, "Randy Bush" wrote: > >> 81.169.145.156 > From lsc at prgmr.com Sat Mar 24 20:46:58 2012 From: lsc at prgmr.com ('Luke S. Crawford') Date: Sat, 24 Mar 2012 21:46:58 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <02f101cd09f6$440fbfa0$cc2f3ee0$@iname.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <20120322185915.GA25250@luke.xen.prgmr.com> <02f101cd09f6$440fbfa0$cc2f3ee0$@iname.com> Message-ID: <20120325014657.GA4528@luke.xen.prgmr.com> On Sat, Mar 24, 2012 at 02:42:36PM -0500, Frank Bulk wrote: > I've been many times where you were, frustrated that I didn't know the dark > fiber options for a potential opportunity, but you have to remind yourself > don't have a *right* to know where *private* fiber is. It's not just the > physical property, the lack of documentation is a competitive advantage. Considering that nearly all of this fiber runs over public right of ways granted by the government (and sometimes through the use of force by the government) it's not really private in the sense that it would be if you bury fiber on land you own, or on land owned by private individuals that have given you the right to run fiber over or through the land through some voluntary exchange of value. The public right of ways are created by the government as a public good, and as such, I think the people have a right to know what goes on in them. (Actually, I was talking to a far more experienced friend the other day, and he says that I should be able to contact the PUC and get exactly this data, though often this, too, is somewhat difficult, so when I re-start this project in a few months, that's the direction I am going to attack first.) Legal issues aside, treating a lack of documentation as a competitive advantage makes any transaction vastly less efficient when you consider both parties. I don't do business that way, and when I have a choice? I don't do business with companies that do. Yes, it is legal, and I am not suggesting that should change. But it's still an asshole move that (from a perspective that considers both parties) destroys value. I talked to the silicon valley power people (the operators of the Santa Clara municipal fiber network) and they gave me a cost per mile and a very detailed map (down to what side of the street the fiber is on) - they wouldn't let me have a copy of the map that actually documented the 'pull boxes', but still, it was enough information that I could look at a building and tell pretty quickly if I was wasting their time or not by getting a quote. Talking to anyone else? no maps (or ridiculously vague maps) and no cost per mile. I have to pick two endpoints and ask how much. In my case, the endpoints depend almost entirely on how much it costs, this means I waste a whole lot of salesperson time, and my own time. It's a vastly less efficient way to do business. From owen at delong.com Sun Mar 25 10:33:40 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Mar 2012 08:33:40 -0700 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <02f201cd09f6$4b251a60$e16f4f20$@iname.com> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> Message-ID: <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> Who cares? It's time to stop letting rural deployments stand in the way of municipal deployments. It's a natural part of living outside of a population center that it costs more to bring utility services to you. I'm not entirely opposed (though somewhat) to subsidizing that to some extent, but, I'm tired of municipal deployments being blocked by this sense of equal entitlement to rural. The rural builds cost more, take longer, and yield lower revenues. It makes no sense to let that stand in the way of building out municipalities. Nothing prevents rural residents who have the means and really want their buildout prioritized from building a collective to get it done. Subsidizing rural build-out is one thing. Failing to build out municipalities because of some sense of rural entitlement? That's just stupid. Owen Sent from my iPad On Mar 24, 2012, at 12:42 PM, "Frank Bulk" wrote: > How many munis serve the rural like they do the urban? > > In the vast majority of cases the munis end up doing what ILECs only wish they could do -- serve the most profitable customers. > > Frank > > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Thursday, March 22, 2012 12:52 PM > To: NANOG > Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) > > > > Oh, it's *much* worse than that, John. > > The *right*, long term solution to all of these problems is for > municipalities to do the fiber build, properly engineered, and even > subbed out to a contractor to build and possibly operate... > > offering *only* layer 1 service at wholesale. Any comer can light up > each city's pop, and offer retail service over the FTTH fiber to that > customer at whatever rate they like, and the city itself doesn't offer > layer 2 or 3 service at all. > > High-speed optical data *is* the next natural monopoly, after power > and water/sewer delivery, and it's time to just get over it and do it > right. > > As you might imagine, this environment -- one where the LEC doesn't own > the physical plant -- scares the ever-lovin' daylights out of Verizon > (among others), so much so that they *have gotten it made illegal* in > several states, and they're lobbying to expand that footprint. > > See, among other sites: http://www.muninetworks.org/ > > As you might imagine, I am a fairly strong proponent of muni layer 1 -- > or even layer 2, where the municipality supplies (matching) ONTs, and > services have to fit over GigE -- fiber delivery of high-speed data > service. > > I believe Google agrees with me. :-) > > Cheers, > -- jra > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > > > From jra at baylink.com Sun Mar 25 10:47:58 2012 From: jra at baylink.com (Jay Ashworth) Date: Sun, 25 Mar 2012 11:47:58 -0400 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> Message-ID: <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> Well, for my part, /most of the poiny/ of muni is The Public Good; if /actual/ bond financed muni fiber is skipping the Hard Parts, it deserves to lose. Time to assemble some stats, I guess. -- jra -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Owen DeLong wrote: Who cares? It's time to stop letting rural deployments stand in the way of municipal deployments. It's a natural part of living outside of a population center that it costs more to bring utility services to you. I'm not entirely opposed (though somewhat) to subsidizing that to some extent, but, I'm tired of municipal deployments being blocked by this sense of equal entitlement to rural. The rural builds cost more, take longer, and yield lower revenues. It makes no sense to let that stand in the way of building out municipalities. Nothing prevents rural residents who have the means and really want their buildout prioritized from building a collective to get it done. Subsidizing rural build-out is one thing. Failing to build out municipalities because of some sense of rural entitlement? That's just stupid. Owen Sent from my iPad On Mar 24, 2012, at 12:42 PM, "Frank Bulk" wrote: > How many munis serve the rural like they do the urban? > > In the vast majority of cases the munis end up doing what ILECs only wish they could do -- serve the most profitable customers. > > Frank > > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Thursday, March 22, 2012 12:52 PM > To: NANOG > Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) > > > > Oh, it's *much* worse than that, John. > > The *right*, long term solution to all of these problems is for > municipalities to do the fiber build, properly engineered, and even > subbed out to a contractor to build and possibly operate... > > offering *only* layer 1 service at wholesale. Any comer can light up > each city's pop, and offer retail service over the FTTH fiber to that > customer at whatever rate they like, and the city itself doesn't offer > layer 2 or 3 service at all. > > High-speed optical data *is* the next natural monopoly, after power > and water/sewer delivery, and it's time to just get over it and do it > right. > > As you might imagine, this environment -- one where the LEC doesn't own > the physical plant -- scares the ever-lovin' daylights out of Verizon > (among others), so much so that they *have gotten it made illegal* in > several states, and they're lobbying to expand that footprint. > > See, among other sites: http://www.muninetworks.org/ > > As you might imagine, I am a fairly strong proponent of muni layer 1 -- > or even layer 2, where the municipality supplies (matching) ONTs, and > services have to fit over GigE -- fiber delivery of high-speed data > service. > > I believe Google agrees with me. :-) > > Cheers, > -- jra > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > > > From bicknell at ufp.org Sun Mar 25 10:56:02 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 25 Mar 2012 08:56:02 -0700 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> Message-ID: <20120325155602.GA84752@ussenterprise.ufp.org> In a message written on Sun, Mar 25, 2012 at 11:47:58AM -0400, Jay Ashworth wrote: > Well, for my part, /most of the poiny/ of muni is The Public Good; if /actual/ bond financed muni fiber is skipping the Hard Parts, it deserves to lose. I agree. If a commercial company goes in to serve folks with fiber they expect a relatively short ROI, 3-5 years typically. This is why rural customers aren't "profitable"; they can't get money from a bank or wall-street for a longer time so they are trying to spread out the build costs over too short of a recoupment period. Fiber has a 20-50 year life. Munis could finance fiber with a 20 year bond at a much lower interest rate than any corporation. By spreading out the costs over 20 years these customers become profitable, often quite so. While in the CBD you might find more than one fiber provider passing a building, for 99.999% of residential users there will only ever be ONE fiber provider to the home. It's hard enough to make the first fiber cost effective, there's no way to go into an already served area incurring all the costs for < 50% of the customers up front. In many small towns muni-fiber in a single star topology to a central switching station where multiple providers can co-locate would bring competitive services at a very attractive cost for both the end user and the services (IP, telephony, video) provider. It's also a topology and technology that easily has 20-50 years of life. -- 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 nick at foobar.org Sun Mar 25 11:29:04 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 25 Mar 2012 17:29:04 +0100 Subject: Muni Fiber In-Reply-To: <20120325155602.GA84752@ussenterprise.ufp.org> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> Message-ID: <4F6F47D0.6020106@foobar.org> On 25/03/2012 16:56, Leo Bicknell wrote: > Fiber has a 20-50 year life. most of the expense of laying fibre is associated with ducting + wayleave. Once you have that in place, blowing new fibre is relatively inexpensive. So rather than amortising the cost according to the lifetime of the fibre, it makes much more sense to amortise over the lifetime of the ducting. Nick From owen at delong.com Sun Mar 25 10:44:08 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Mar 2012 08:44:08 -0700 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <02f301cd09f7$45dc73e0$d1955ba0$@iname.com> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <4F6BFFE7.3090201@punk.co.nz> <0B60F7E3-1075-4A26-8BD7-742C63420D22@puck.nether.net> <4F6C78DA.2060607@necom830.hpcl.titech.ac.jp> <02f301cd09f7$45dc73e0$d1955ba0$@iname.com> Message-ID: That is why I believe that the L1 buildout should be done by or under contract to the local authority (whether that be a municipality, county, special district, or whatever) and then leased to L2+ service providers on an equal cost per subscriber basis. Now it doesn't matter which subscribers cost more or less to build out, they all cost the same to serve. Yes, the more expensive subscribers are being subsidized by the less expensive ones. Overall, I don't really have a problem with this as I don't think that the discrepancies within a given authority area will be that large. I do think that we should require each authority to build out to all end sites within their jurisdiction not served by a smaller authority. For example, Contra Cost County, California would be required to build out El Sobrante (unincorporated area of the county), but, not Pinole, Rodeo, Crockett, Hercules, etc. (since they would be required to be built out by their cities). Yes, it's likely that the L2+ providers would have a higher cost per customer to serve El Sobrante than to serve the cities. However, since that increased cost would apply equally to all L2+ providers, it would easily be passed on to those subscribers and they would, therefore end up paying roughly the true cost of their choice to live in an unincorporated lower-density area. Yes, higher-density authorities would have a better chance of attracting greater competition and diversity in L2+ providers. However, nothing would prevent or exclude smaller authorities from working out colocation deals with nearby larger (or even groups of smaller) authorities and bringing the termination points of multiple authorities together in the same location. Likewise, nothing would prevent authorities from building inexpensive backhaul facilities to adjacent larger centers. If you cleanly separate the L1 infrastructure from the L2+ services providers, you really do have opportunities to do better for the subscriber base overall. Yes, the L1 buildout will cost slightly more than an optimal monopoly build-out by a service provider. However, that small increase in cost yields huge benefits on the other side in terms of reduced barriers to competition, increased diversity, and more price pressure on the L2+ services side of things. Owen Sent from my iPad On Mar 24, 2012, at 12:49 PM, "Frank Bulk" wrote: >> From my own experience in my $DAYJOB, separating capital decisions at the L1 > and L2 layers would end up adding cost. As mentioned elsewhere, GPON and > similar shared medium approaches do not lend themselves well to structural > separation. The most practical approach is dark fiber runs from the > customer to as few centralized places as possible. The CLEC would co-locate > their equipment at those centralized places. The CLEC is then free to use > ActiveE, GPON, whatever-the-next-gen-of-PON. > > Structural separation works best when the cost to build to a customer are > roughly the same. Wherever there's significant disparaties, those will be > exploited and people will overbuild to the highest-margin/lowest cost > customers to avoid the averaged cost of L1 network. > > Frank > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, March 23, 2012 9:28 AM > To: Masataka Ohta > Cc: nanog at nanog.org > Subject: Re: Muni Fiber (was: Re: last mile, regulatory incentives, etc) > > > > It doesn't promote local monopoly if you don't allow the L1 company to > provide L2+ services. > > If the L1 company is required to be independent of and treat all L2+ > services companies equally, then, the ILEC, CLEC, et. all have the same cost > per customer. > > Owen > > > From bicknell at ufp.org Sun Mar 25 12:58:20 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 25 Mar 2012 10:58:20 -0700 Subject: Muni Fiber In-Reply-To: <4F6F47D0.6020106@foobar.org> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F47D0.6020106@foobar.org> Message-ID: <20120325175820.GA89077@ussenterprise.ufp.org> In a message written on Sun, Mar 25, 2012 at 05:29:04PM +0100, Nick Hilliard wrote: > most of the expense of laying fibre is associated with ducting + wayleave. > Once you have that in place, blowing new fibre is relatively inexpensive. > So rather than amortising the cost according to the lifetime of the fibre, > it makes much more sense to amortise over the lifetime of the ducting. Maybe. In rural deployments it's much more likely the fiber is aerial, it's far cheaper to attach to existing poles with few cables on them than it is to bury the fiber. Even in urban areas where buried duct is the norm, being able to use old ducts varies a lot with the geography and how active the area is to other development. I've seen plenty of ducts where it had been cut and repaired several times before use that running a new cable through it was impossible and it simply had to be replaced. In other locations 20 years later a new cable goes through like butter. But I think it's all a bit of a tangent; when talking about _residential_ fiber it's prudent to run 2-6 strands to every home day one, and then, well, there's basically never a point in running more. The chance of blowing more fiber down the duct later is near zero. It's also why I'm not a fan of *PON schemes, eliminate the splitter and run a single star topology. 20 years from now Petabit optics will look different than today's GigE in some way, but I'll bet money they are tuned to run on single mode fiber. They may not like the splitters and the like though. By doing a star back to a wiring center you enable all technologies. GPON today, direct GigE or 10GE where necessary, and all future technologies. -- 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 joseph.snyder at gmail.com Sun Mar 25 13:14:32 2012 From: joseph.snyder at gmail.com (Joseph Snyder) Date: Sun, 25 Mar 2012 14:14:32 -0400 Subject: Muni Fiber In-Reply-To: <20120325175820.GA89077@ussenterprise.ufp.org> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F47D0.6020106@foobar.org> <20120325175820.GA89077@ussenterprise.ufp.org> Message-ID: <36aef257-0af6-4d1c-a0ad-c98471ae2eaf@email.android.com> Hmm even most urban environments aren't worth deploying in or are probably marginal profit. So I would expect 30-45% of population of the US to not be worth or marginally worth deploying. I am assuming most urban less than 250k and probably spread out. Not to mention to provide transit without services to residential is a margins game to begin with and without at least a 20-30% take rate it probably isn't worth the cost of l3 infrastructure. On the other hand for actual dense urban environments it makes perfect sense as long as the are willing to maintain it. I see the possibilities, but have a gut feeling it would become a political mess and unreliable, not to mention cost us more than we pay now. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Leo Bicknell wrote: In a message written on Sun, Mar 25, 2012 at 05:29:04PM +0100, Nick Hilliard wrote: > most of the expense of laying fibre is associated with ducting + wayleave. > Once you have that in place, blowing new fibre is relatively inexpensive. > So rather than amortising the cost according to the lifetime of the fibre, > it makes much more sense to amortise over the lifetime of the ducting. Maybe. In rural deployments it's much more likely the fiber is aerial, it's far cheaper to attach to existing poles with few cables on them than it is to bury the fiber. Even in urban areas where buried duct is the norm, being able to use old ducts varies a lot with the geography and how active the area is to other development. I've seen plenty of ducts where it had been cut and repaired several times before use that running a new cable through it was impossible and it simply had to be replaced. In other locations 20 years later a new cable goes through like butter. But I think it's all a bit of a tangent; when talking about _residential_ fiber it's prudent to run 2-6 strands to every home day one, and then, well, there's basically never a point in running more. The chance of blowing more fiber down the duct later is near zero. It's also why I'm not a fan of *PON schemes, eliminate the splitter and run a single star topology. 20 years from now Petabit optics will look different than today's GigE in some way, but I'll bet money they are tuned to run on single mode fiber. They may not like the splitters and the like though. By doing a star back to a wiring center you enable all technologies. GPON today, direct GigE or 10GE where necessary, and all future technologies. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From nick at foobar.org Sun Mar 25 13:15:47 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 25 Mar 2012 19:15:47 +0100 Subject: Muni Fiber In-Reply-To: <20120325175820.GA89077@ussenterprise.ufp.org> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F47D0.6020106@foobar.org> <20120325175820.GA89077@ussenterprise.ufp.org> Message-ID: <4F6F60D3.6030703@foobar.org> > wiring center you enable all technologies. GPON today, direct GigE > or 10GE where necessary, and all future technologies. yep, agreed - much more sensible, much more resilient to failure and only marginally more expensive. It'll never be done though. Too much to lose by creating a topology which allows you to unbundle the tail. Nick From bicknell at ufp.org Sun Mar 25 13:34:05 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 25 Mar 2012 11:34:05 -0700 Subject: Muni Fiber In-Reply-To: <4F6F60D3.6030703@foobar.org> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F47D0.6020106@foobar.org> <20120325175820.GA89077@ussenterprise.ufp.org> <4F6F60D3.6030703@foobar.org> Message-ID: <20120325183405.GA90100@ussenterprise.ufp.org> In a message written on Sun, Mar 25, 2012 at 07:15:47PM +0100, Nick Hilliard wrote: > It'll never be done though. Too much to lose by creating a topology which > allows you to unbundle the tail. Only if it is your capital building the tail. Today's Internet companies are still trying to achive penetration to the 30-40% of households that are cheap to reach, and profitable as customers in commercial timescales (3-5 years). As we reach saturation in that market (less than 10 years from now, I think) they will have to look to the "unprofitable" customers as the only real source of new business. The economics then change. While it's better to have it be your asset and create a customer lock-in, when the risk is high enough it will be seen as better to have a municipality or other take on the risk even if it means unbundled competition. Phone provides the history here; telephone companies started out with only the most profitable companies. To reach the commercially unprofitable ones they turned to government, in the form of things like the Rural Electrification Act (governemnt backed loans to rural providers) and the Universal Service Fund. These government subsidies were also a _major_ driver in the argument that copper local loops should be unbundled since in a lot of cases government had paid for them, not private companies. Politically the makings of a similar situation already exist. Goverment has swung the USF funds to fuel rual broadband, strongly favoring FTTx where it makes sense. While companies like Verizon enjoy not having to share their fiber lines now, these same forces will conspire to drive unbundling in fiber, just as it did in copper. What they are getting now is simply a first mover advantage. Government at the end of the day will fund the 20-40% of America which is profitable in the long run, but not in commercial time scales. They will also fund the 10% of America which will never be profitable, no mater what. It happened with Electricity and Telephone, and I suspect the societal drivers to do the same with the Internet will be even stronger. Companies will have to accept an unbundled tail to get access to this 30-50% of the market; and while they aren't interested now, they will be very soon. -- 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 jcdill.lists at gmail.com Sun Mar 25 14:37:24 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 25 Mar 2012 12:37:24 -0700 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <20120325155602.GA84752@ussenterprise.ufp.org> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> Message-ID: <4F6F73F4.3070204@gmail.com> On 25/03/12 8:56 AM, Leo Bicknell wrote: > In a message written on Sun, Mar 25, 2012 at 11:47:58AM -0400, Jay Ashworth wrote: >> Well, for my part, /most of the poiny/ of muni is The Public Good; if /actual/ bond financed muni fiber is skipping the Hard Parts, it deserves to lose. It doesn't matter if it's a bond-financed project or a privately funded (privately owned) project - they are using a public resource (the street/poles) to lay their lines, and usually also using the power of the municipality's right to eminent domain to put in or use poles (or underground conduits) to run lines across private properties. As part of the Public Good contract to use these public resources, they should be required to service both the the easy parts and the hard parts, no matter the source of the financing or the ownership of the lines. > If a commercial company goes in to serve folks with fiber they > expect a relatively short ROI, 3-5 years typically. This is why > rural customers aren't "profitable"; they can't get money from a > bank or wall-street for a longer time so they are trying to spread > out the build costs over too short of a recoupment period. > > Fiber has a 20-50 year life. The biggest problem is determining how certain that lifespan is. Remember how Netflix looked like an awesome business to deliver DVDs by mail in 2002, and had one of the most successful IPOs of the era? Less than 10 years later we have widespread broadband and companies can deliver that same content by copper/fiber/802.11. Now Netflix is in the position of being in direct business conflict with the companies they rely on to carry their product to their customers (e.g. Comcast) and their future is very uncertain. Can you promise that fiber has a *feasible* lifetime of 20-50 years? Maybe in 5-10 years all consumer data will be transferred via wireless, and investment in municipal wired data systems (fiber and copper) becomes worthless. This is why most modern build-outs have to show a ROI of under 5 years. We just don't know what new technology breakthroughs might happen, which could make a project that requires a 10-30 year payback schedule go bankrupt when a new technology makes the prior one obsolete. jc From mohta at necom830.hpcl.titech.ac.jp Sun Mar 25 14:39:46 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 26 Mar 2012 04:39:46 +0900 Subject: Muni Fiber In-Reply-To: <4F6F60D3.6030703@foobar.org> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F47D0.6020106@foobar.org> <20120325175820.GA89077@ussenterprise.ufp.org> <4F6F60D3.6030703@foobar.org> Message-ID: <4F6F7482.1000109@necom830.hpcl.titech.ac.jp> Nick Hilliard wrote: >> wiring center you enable all technologies. GPON today, direct GigE >> or 10GE where necessary, and all future technologies. > > yep, agreed - much more sensible, much more resilient to failure and only > marginally more expensive. You should suspect cost figures provided by those who want to keep their monopoly. At least, if population density is below some threshold, SS is less expensive than PON, because the expected number of subscribers to share a fiber with reasonably short drop cables is small. > It'll never be done though. Too much to lose by creating a topology which > allows you to unbundle the tail. It is still possible to unbundle PON if regulators want to do so. See our paper: Competition Promoting Unbundling of PON http://dl.acm.org/citation.cfm?id=1914349 Masataka Ohta From Valdis.Kletnieks at vt.edu Sun Mar 25 15:00:49 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 25 Mar 2012 16:00:49 -0400 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: Your message of "Sun, 25 Mar 2012 12:37:24 -0700." <4F6F73F4.3070204@gmail.com> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> Message-ID: <92177.1332705649@turing-police.cc.vt.edu> On Sun, 25 Mar 2012 12:37:24 -0700, JC Dill said: > *feasible* lifetime of 20-50 years? Maybe in 5-10 years all consumer > data will be transferred via wireless And that would be using what spectrum and what technology? Consider what the release of one Apple product did to the associated carrier's wireless net. Then consider the current tendency for "unlimited wireless data" to mean 2-3G per month. Where's the economic incentive for all these carriers to build out enough capacity to move "all consumer data" (or a large fraction anyhow), and lower their prices to match? Sure, it may happen *eventually*, but for it to happen in 5-10 years, it would have to be in motion *now*. So who's already in motion? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From tvhawaii at shaka.com Sun Mar 25 15:15:13 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Sun, 25 Mar 2012 10:15:13 -1000 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> <1BC9AEBB-3B43-4620-A56D-7A19BE1366BA@delong.com> <48045.1332454293@turing-police.cc.vt.edu> <04189B1AE8D841DBAB59425EF5BCEC71@owner59e1f1502> <10688.1332560122@turing-police.cc.vt.edu> Message-ID: ----- Original Message ----- From: To: "Michael Painter" Cc: Sent: Friday, March 23, 2012 5:35 PM Subject: Re: last mile, regulatory incentives, etc (was: att fiber, et al) That's the national definition of "broadband" that we're stuck with. To show how totally cooked the books are, consider that when they compute "percent of people with access to residential broadband", they do it on a per-county basis - and if even *one* subscriber in one corner of the county has broadband, the entire county counts. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ummhmm. More and more lately, I'm reminded of a saying my old, now deceased, friend used to use when talking about poker in Milwaukee. "We knew it was a crooked game, but it was the only game in town." From mohta at necom830.hpcl.titech.ac.jp Sun Mar 25 15:14:43 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 26 Mar 2012 05:14:43 +0900 Subject: Muni Fiber In-Reply-To: <4F6F47D0.6020106@foobar.org> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F47D0.6020106@foobar.org> Message-ID: <4F6F7CB3.5060800@necom830.hpcl.titech.ac.jp> Nick Hilliard wrote: > most of the expense of laying fibre is associated with ducting + wayleave. Another important expense of FTTH is at the last yards of dropping cables fro the laed fiber, where SS needs simple closures and shorter dropping cables than PON. Masataka Ohta From bicknell at ufp.org Sun Mar 25 15:44:32 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 25 Mar 2012 13:44:32 -0700 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <4F6F73F4.3070204@gmail.com> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> Message-ID: <20120325204432.GA93993@ussenterprise.ufp.org> In a message written on Sun, Mar 25, 2012 at 12:37:24PM -0700, JC Dill wrote: > their future is very uncertain. Can you promise that fiber has a > *feasible* lifetime of 20-50 years? Maybe in 5-10 years all consumer > data will be transferred via wireless, and investment in municipal wired > data systems (fiber and copper) becomes worthless. You have offered a two part problem. The initial question is, will fiber put in the ground today still be able to do something useful in 20-50 years. I believe the answer to that is yes. There is fiber that was installed in the early 1980's that is still in use today. It's predecessor technology, copper wires to the home, has been in use far longer and with today's DSL technolgy has done far more than ever intended. High quality transmission media in the ground has long life, and new, well designed fiber would be no exception. The second part of your question is really "might fiber be replaced with some disruptive technology?" That is always a risk, but I actually think the avenues for advancement are few. Wireless of some type is probably the only viable competitor, and it's anything but cheap at scale. The real way to address the second part is to look at the outgoing technology, copper/dsl. Even though phone lines were designed to just carry 8khz voice, we've found it far cheaper and easier to design DSL technology around those properties rather than replace it with fiber or wireless. The reason? Build cost mostly. Diging to bury new fiber is expensive, and even with wireless permitting new transmitter locations and spectrum are very expensive. Can I _guarantee_ no better technology will come along? No. However I would posit even if it does come along the life span of fiber is still 20 years just due to the build cost and timeframe of the new tech. It's if it doesn't come along the timeline grows to more like 50 years. There's risk in any technology investment, however I think having a high bandwidth, high reliability, cheap to operate pipe into the home will always have enormous value, and right now fiber is the best tech to that and thus the best place to invest. -- 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 frnkblk at iname.com Sun Mar 25 22:45:02 2012 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 25 Mar 2012 22:45:02 -0500 Subject: Muni Fiber In-Reply-To: <20120325175820.GA89077@ussenterprise.ufp.org> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F47D0.6020106@foobar.org> <20120325175820.GA89077@ussenterprise.ufp.org> Message-ID: <030e01cd0b02$d76234b0$86269e10$@iname.com> Most rural GPON deployments I see today are homerun back to the CO or a hut -- there's few that have passive splitters in a cabinet. They also want their GPON to be future-proofed. Frank -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Sunday, March 25, 2012 12:58 PM To: nanog at nanog.org Subject: Re: Muni Fiber In a message written on Sun, Mar 25, 2012 at 05:29:04PM +0100, Nick Hilliard wrote: > most of the expense of laying fibre is associated with ducting + wayleave. > Once you have that in place, blowing new fibre is relatively inexpensive. > So rather than amortising the cost according to the lifetime of the fibre, > it makes much more sense to amortise over the lifetime of the ducting. Maybe. In rural deployments it's much more likely the fiber is aerial, it's far cheaper to attach to existing poles with few cables on them than it is to bury the fiber. Even in urban areas where buried duct is the norm, being able to use old ducts varies a lot with the geography and how active the area is to other development. I've seen plenty of ducts where it had been cut and repaired several times before use that running a new cable through it was impossible and it simply had to be replaced. In other locations 20 years later a new cable goes through like butter. But I think it's all a bit of a tangent; when talking about _residential_ fiber it's prudent to run 2-6 strands to every home day one, and then, well, there's basically never a point in running more. The chance of blowing more fiber down the duct later is near zero. It's also why I'm not a fan of *PON schemes, eliminate the splitter and run a single star topology. 20 years from now Petabit optics will look different than today's GigE in some way, but I'll bet money they are tuned to run on single mode fiber. They may not like the splitters and the like though. By doing a star back to a wiring center you enable all technologies. GPON today, direct GigE or 10GE where necessary, and all future technologies. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From jared at puck.nether.net Mon Mar 26 03:54:18 2012 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 26 Mar 2012 04:54:18 -0400 Subject: Muni Fiber In-Reply-To: <4F6F7CB3.5060800@necom830.hpcl.titech.ac.jp> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F47D0.6020106@foobar.org> <4F6F7CB3.5060800@necom830.hpcl.titech.ac.jp> Message-ID: On Mar 25, 2012, at 4:14 PM, Masataka Ohta wrote: > Nick Hilliard wrote: > >> most of the expense of laying fibre is associated with ducting + wayleave. > > Another important expense of FTTH is at the last yards of > dropping cables fro the laed fiber, where SS needs simple > closures and shorter dropping cables than PON. These enclosures (including all electronics but SFP) are around $350. SFP is another $110 for 10km bidi optics w/ DOM. The cable cost to reach the home with connectors can run around $1-2/meter, excluding pole attach or burying costs. The cable cost quickly comes to rival the cost of the enclosure. - Jared From joshua.klubi at gmail.com Mon Mar 26 04:09:31 2012 From: joshua.klubi at gmail.com (joshua.klubi at gmail.com) Date: Mon, 26 Mar 2012 09:09:31 +0000 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> Message-ID: But they also deserve to have or enjoy the benefits that comes with living in the big cities -- Sent from my Nokia N9 On 25/03/2012 15:47 Jay Ashworth wrote: Well, for my part, /most of the poiny/ of muni is The Public Good; if /actual/ bond financed muni fiber is skipping the Hard Parts, it deserves to lose. Time to assemble some stats, I guess. -- jra -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Owen DeLong wrote: Who cares? It's time to stop letting rural deployments stand in the way of municipal deployments. It's a natural part of living outside of a population center that it costs more to bring utility services to you. I'm not entirely opposed (though somewhat) to subsidizing that to some extent, but, I'm tired of municipal deployments being blocked by this sense of equal entitlement to rural. The rural builds cost more, take longer, and yield lower revenues. It makes no sense to let that stand in the way of building out municipalities. Nothing prevents rural residents who have the means and really want their buildout prioritized from building a collective to get it done. Subsidizing rural build-out is one thing. Failing to build out municipalities because of some sense of rural entitlement? That's just stupid. Owen Sent from my iPad On Mar 24, 2012, at 12:42 PM, "Frank Bulk" wrote: > How many munis serve the rural like they do the urban? > > In the vast majority of cases the munis end up doing what ILECs only wish they could do -- serve the most profitable customers. > > Frank > > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Thursday, March 22, 2012 12:52 PM > To: NANOG > Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) > > > > Oh, it's *much* worse than that, John. > > The *right*, long term solution to all of these problems is for > municipalities to do the fiber build, properly engineered, and even > subbed out to a contractor to build and possibly operate... > > offering *only* layer 1 service at wholesale. Any comer can light up > each city's pop, and offer retail service over the FTTH fiber to that > customer at whatever rate they like, and the city itself doesn't offer > layer 2 or 3 service at all. > > High-speed optical data *is* the next natural monopoly, after power > and water/sewer delivery, and it's time to just get over it and do it > right. > > As you might imagine, this environment -- one where the LEC doesn't own > the physical plant -- scares the ever-lovin' daylights out of Verizon > (among others), so much so that they *have gotten it made illegal* in > several states, and they're lobbying to expand that footprint. > > See, among other sites: http://www.muninetworks.org/ > > As you might imagine, I am a fairly strong proponent of muni layer 1 -- > or even layer 2, where the municipality supplies (matching) ONTs, and > services have to fit over GigE -- fiber delivery of high-speed data > service. > > I believe Google agrees with me. :-) > > Cheers, > -- jra > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink owen at delong.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.muninetworks.org/ 2000 Land Rover DII > St Petersburg FL USA http://www.muninetworks.org/ +1 727 647 1274 > > > From oscar.vives at gmail.com Mon Mar 26 05:16:53 2012 From: oscar.vives at gmail.com (Tei) Date: Mon, 26 Mar 2012 12:16:53 +0200 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> Message-ID: On 23 March 2012 13:31, Aled Morris wrote: > On 23 March 2012 11:53, Eugen Leitl wrote: > >> All three cables are being laid for the same reasons: Redundancy and speed. >> As it stands, it takes roughly 230 milliseconds for a packet to go from >> London to Tokyo; the new cables will reduce this by 30% to 170ms. This >> speed-up will be gained by virtue of a much shorter run: > > > > > If they could armor the cable sufficiently perhaps they could drill the > straigh line path through the Earth's crust (mantle and outer core) and do > London-Tokyo in less than 10,000km. > > Aled I imagine a easier solution. Use a random number generator in both sides, with the same seed. Then use a slower way to send "packets re-sync" that will contain the delta from the generated number, to the real actual number. I suppose this speeds are needed for some "fast speed transaction", that are leeching money from the background noise on the market. This is not like the Roman empire, where you could make a lot of money buying wheat wen theres a dry year in egypt. note: I could be wrong. -- -- ?in del ?ensaje. From mohta at necom830.hpcl.titech.ac.jp Mon Mar 26 07:23:37 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 26 Mar 2012 21:23:37 +0900 Subject: Muni Fiber In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F47D0.6020106@foobar.org> <4F6F7CB3.5060800@necom830.hpcl.titech.ac.jp> Message-ID: <4F705FC9.3020408@necom830.hpcl.titech.ac.jp> Jared Mauch wrote: >> Another important expense of FTTH is at the last yards of >> dropping cables fro the laed fiber, where SS needs simple >> closures and shorter dropping cables than PON. > These enclosures (including all electronics but SFP) are around $350. What? What do you mean "including all electronics" inside closures of PON or SS? > SFP is another $110 for 10km bidi optics w/ DOM. > > The cable cost to reach the home with connectors can run around $1-2/meter, excluding pole attach or burying costs. What costs is not material but installation. Masataka Ohta From jloiacon at csc.com Mon Mar 26 07:42:40 2012 From: jloiacon at csc.com (Joe Loiacono) Date: Mon, 26 Mar 2012 08:42:40 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: References: <20120323115345.GF9891@leitl.org> Message-ID: Tei wrote on 03/26/2012 06:16:53 AM: > I imagine a easier solution. Use a random number generator in both > sides, with the same seed. Then use a slower way to send "packets > re-sync" that will contain the delta from the generated number, to the > real actual number. > > I suppose this speeds are needed for some "fast speed transaction", > that are leeching money from the background noise on the market. > > This is not like the Roman empire, where you could make a lot of money > buying wheat wen theres a dry year in egypt. > > note: I could be wrong. Noted. Joe From Valdis.Kletnieks at vt.edu Mon Mar 26 07:57:15 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 26 Mar 2012 08:57:15 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: Your message of "Mon, 26 Mar 2012 12:16:53 +0200." References: <20120323115345.GF9891@leitl.org> Message-ID: <128551.1332766635@turing-police.cc.vt.edu> On Mon, 26 Mar 2012 12:16:53 +0200, Tei said: > I imagine a easier solution. Use a random number generator in both > sides, with the same seed. Then use a slower way to send "packets > re-sync" that will contain the delta from the generated number, to the > real actual number. Congrats. You've just re-invented the crytpo method called "xor with a pseudorandom bitstream". And no, it doesn't minimize your round-trip latency at all. > I suppose this speeds are needed for some "fast speed transaction", > that are leeching money from the background noise on the market. Unfortunately, you are correct on that point. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From rodrick.brown at gmail.com Mon Mar 26 07:59:34 2012 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Mon, 26 Mar 2012 08:59:34 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <4F6CC4E4.5000005@mompl.net> References: <20120323115345.GF9891@leitl.org> <30864.1332510464@turing-police.cc.vt.edu> <4F6CC4E4.5000005@mompl.net> Message-ID: On Mar 23, 2012, at 2:45 PM, Jeroen van Aart wrote: > Valdis.Kletnieks at vt.edu wrote: >>> The massive drop in latency is expected to supercharge algorithmic stock >>> market trading, where a difference of a few milliseconds can gain (or lose) >>> millions of dollars. >> But it should be illegal to run a stock market that volatile. This can't end well. > > The average consumer gets a 15 minute artificial delay in trading, why not implement for all trades... The average consumer shouldn't be day trading with shit market data thats delayed or worse with level 1 depth of the markets they're just asking to be taken by the heavy quant firms. HIgh frequency trading does provide a service to the financial markets as a whole despite what the media and government politicians will have you think. Transaction cost has plummeted over the years and do has the barrister to enter the markets. > -- > Earthquake Magnitude: 4.8 > Date: Friday, March 23, 2012 14:35:31 UTC > Location: Tonga > Latitude: -16.2478; Longitude: -174.0706 > Depth: 119.50 km > From Valdis.Kletnieks at vt.edu Mon Mar 26 08:32:18 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 26 Mar 2012 09:32:18 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: Your message of "Mon, 26 Mar 2012 08:59:34 -0400." References: <20120323115345.GF9891@leitl.org> <30864.1332510464@turing-police.cc.vt.edu> <4F6CC4E4.5000005@mompl.net> Message-ID: <129926.1332768738@turing-police.cc.vt.edu> On Mon, 26 Mar 2012 08:59:34 -0400, Rodrick Brown said: > HIgh frequency trading does provide a service to the financial markets as a > whole despite what the media and government politicians will have you think. OK, I'll bite. What benefit does the market *as a whole* get from the ability to do trades in 60ms rather than 120ms? (Hint - the fact you can extract money via more arbitrage transactions per minute is a benefit to the trader, not the market as a whole - if you extract $100M from the market, it came from somewhere....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jared at puck.nether.net Mon Mar 26 09:07:10 2012 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 26 Mar 2012 10:07:10 -0400 Subject: Muni Fiber In-Reply-To: <4F705FC9.3020408@necom830.hpcl.titech.ac.jp> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F47D0.6020106@foobar.org> <4F6F7CB3.5060800@necom830.hpcl.titech.ac.jp> <4F705FC9.3020408@necom830.hpcl.titech.ac.jp> Message-ID: <93B21AEE-203C-4D3A-B730-22E34B4F13AA@puck.nether.net> Active Ethernet solution outdoor enclosure sfp+2xGE+2xPOTS is about 350 without optics Inside device is closer to 150-160. ... Certainly agree on install costs. Jared On Mar 26, 2012, at 8:23 AM, Masataka Ohta wrote: > Jared Mauch wrote: > >>> Another important expense of FTTH is at the last yards of >>> dropping cables fro the laed fiber, where SS needs simple >>> closures and shorter dropping cables than PON. > >> These enclosures (including all electronics but SFP) are around $350. > > What? > > What do you mean "including all electronics" inside closures > of PON or SS? > >> SFP is another $110 for 10km bidi optics w/ DOM. >> >> The cable cost to reach the home with connectors can run around $1-2/meter, excluding pole attach or burying costs. > > What costs is not material but installation. > > Masataka Ohta From jra at baylink.com Mon Mar 26 09:42:01 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 26 Mar 2012 10:42:01 -0400 (EDT) Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: Message-ID: <26504213.8041.1332772921725.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "joshua klubi" > But they also deserve to have or enjoy the benefits that comes with > living in the big cities Well, "deserve" is a strong word... but the underlying thought is my primary reason for believing that municipal fiber is a good solution, and I'll expand that thought one more layer: The Public Good is not often all that cost effective; sometimes, it's a money loser. That's why corporations can almost always be depended on *not* to be working in its interest, absent regulations to force them to do so, such as the Universal Service Obligation, imposed on AT&T in one form or another all the way back to the Communications Act, and expanded in TCA96. This is one of many things that seems to militate in favor of municipally owned and operated layer 1 fiber builds -- is *is* the obligation *of a municipality* to operate in favor of the Public Good: it *is the Public*, in a very real sense. And the members of that body politic, properly informed, can make sure that such a build will be, by direction, equally accessible to all in their area: it will be a bond issue, and such items are generally ballot questions. Or at least, they can try; you can't make people vote. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From nathan at atlasnetworks.us Mon Mar 26 11:22:05 2012 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 26 Mar 2012 16:22:05 +0000 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C287C9E5A71@EX-MB-1.corp.atlasnetworks.us> > -----Original Message----- > From: joshua.klubi at gmail.com [mailto:joshua.klubi at gmail.com] > Sent: Monday, March 26, 2012 2:10 AM > To: Owen DeLong; Frank Bulk; Jay Ashworth > Cc: NANOG > Subject: Re: Muni Fiber (was: Re: last mile, regulatory incentives, > etc) > > But they also deserve to have or enjoy the benefits that comes with > living in the big cities I grew up in a rural area served by dialup for the first 15 years of my life, so please don't misunderstand what I'm about to say. No, they don't. Living in a rural area is a different set of value propositions than living in the Big City, and we shouldn't pretend otherwise. Do people living in the big cities reap the benefits of living in the country? No ambient noise, no air pollution, low crime rates, neighbors you know and can trust your children with? No, they don't. That isn't to say that broadband technology won't (or shouldn't) find ways of serving people in rural areas with increasingly usable levels of throughput while decreasing jitter and loss; it already is (and should), and the situation is constantly improving. But I think it's a mistake to say that people who have made the decision to live in the Big City should expect to enjoy the same benefits as people who have made the decision to live in rural towns, and vice versa. They'll never be the same, and unless I'm very much mistaken, that's actually OK. Nathan Eisenberg From rps at maine.edu Mon Mar 26 11:32:29 2012 From: rps at maine.edu (Ray Soucy) Date: Mon, 26 Mar 2012 12:32:29 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: Here in Maine, after seeing no strong proposals were being put forward by others, we went after American Recovery and Reinvestment Act funds to address a major lack of middle-mile infrastructure in the state. Verizon had stopped making new investments in Maine for nearly 10 years before pulling out and dumping a very old, very high maintenance copper plant on Fairpoint. It was nearly criminal. Even worse, the Fairpoint business plan was to continue to make large investments in copper ignoring the realities that fiber is the only way to reach areas in a cost effective way with such low population density. So the University of Maine System and Great Works Internet prepared a proposal for a public-private partnership to build out high capacity, diverse, middle-mile infrastructure in Maine; and instead of the University of Maine System or Great Works Internet managing it, we set it up so that a new independent private company would be created to manage the infrastructure and would be regulated as a public utility by the state; very similar to the power company model. The result is that Maine now has a new public utility classification of "dark fiber provider", and a company building out that fiber. It's called Maine Fiber Company: http://www.mainefiberco.com/ The way Maine Fiber Company was setup was key. They're forbidden to offer lit services; so they're a dark fiber only provider. They're require to provide open access to the fiber at a fair and published rate to anyone interested. Since the build was subsidized in part by Recovery Act funds, the rates are low enough to encourage new services in the state. One of the big problems in a state like Maine, and probably the majority of the US, is that companies like Fairpoint and Time Warner Cable (the two providers in Maine) end up building out redundant infrastructure at great cost. Not redundant as in diverse, mind you, but literally running fiber on the same utility polls, taking the same path, and both going down when hit by a truck. Because areas of the state are very low population, they often can't justify building a diverse path, so historically, one accident could, and often has, taken out services for entire counties. For the last few years MFC has been working to build out the high capacity fiber rings described, and this summer we're finally at a point where people can begin making use of MFC infrastructure. For us, it means expanding our R&E network, MaineREN, to interconnect the public universities in Maine. But for other service providers like Great Works Internet, it means being able to survive as Fairpoint tries to push out their competitors: See the following link for that story "Fairpoint Bankruptcy Exacerbates Circuit War": http://www.pressherald.com/archive/fairpoint-bankruptcy-exacerbates-circuit-war_2009-11-12.html I think the model setup in Maine is something really powerful. It will drive down the price of delivering broadband significantly; it will open up and promote competition so that consumers aren't stuck paying premium rates for 20th century services, and it will provide much needed redundancy of services. It also helps the bigger companies like Fairpoint and Time Warner Cable if they're willing to make use of it (to my recollection Fairpoint decided to not even bid for the build out; that's how opposed they were to it) Personally, I think this is a model that might be useful to replicate at a municipal level as well: Dark fiber to the home as a public utility; service provider of your choice to light it up. I think we're a few years away from seeing that kind of effort, though, but after a few years of seeing the effect that Maine Fiber Company will have on the state, there might be people open to the idea. For now, I'm thankful to have the middle-mile taken care of. I know a few other states decided to go after recovery act money for broadband; does anyone know if something like the Maine model is being replicated anywhere else in the US? On Thu, Mar 22, 2012 at 12:26 PM, Jared Mauch wrote: > > On Mar 22, 2012, at 11:05 AM, chris wrote: > > > I'm all for VZ being able to reclaim it as long as they open their fiber > > which I don't see happening unless its by force via government. At the > end > > of the day there needs to be the ability to allow competitors in so of > > course they shouldnt be allowed to rip out the regulated part and replace > > it with a unregulated one. > > I think this partly captures the incentive case here, but there is also a > larger one at play. Over the years the copper infrastructure was installed > and extended through various incentive programs. You can see the > modern-day reflection of that in the RUS (used to manage rural > electrification act, part of USDA) and NTIA (Department of Commerce). > > The barriers to entry are significant for a new player in the marketplace. > The cost is putting the cabling in the ground vs the cost of the cable > itself. One can easily pick up hardware for $250 to light a single strand > of 9/125 SM fiber @ 10km for a 1Gb/s ethernet link. That's low enough you > could likely get a consumer to buy the hardware. The real cost is the > installation per strand foot/mile. > > In the past this has been subsidized for copper plant. There is no reason > in my mind that the fiber plant should be treated differently from this > standpoint. I can find fiber optic cabling for $0.25/ft. The problem here > is a multi-dimensional one that I've seen play out in a few markets: > > Verizon selling assets to Fairpoint (NH, ME, VT). These are high cost > areas due to low-density population. For the sale to go through, Fairpoint > had to agree to build into these higher cost areas. The result was > bankruptcy for Fairpoint. > > Verizon sold assets in Michigan (and other states) to Frontier. I've not > tracked this one as closely, but I suspect the economics of this are fairly > complex. > > I've also spoken to some small ISPs and their general cost of building > fiber to the home tends to be $2500/subscriber in upfront capital. This > covers just the installation cost. Due to years of subsidy and regulation, > people are unwilling to pay this amount to install a telecommunications > service whereas a new home requiring a connection to the water, sewers, > natural gas or electric grid may pay $10k or more to connect. Many people > wouldn't think of buying a home without electric service, but without > modern telecommunication service? I've seen this play out after the fact > with friends asking how to get service. Satellite, Fixed wireless or just > cellular data quickly become their fallbacks. The demand is there, the > challenge becomes recovering the build cost. > > It is my firm belief that without a regulatory regime it will not be > feasible to connect many communities robustly to modern communications > infrastructure. This could clearly change if the carriers involved see fit > to replace this infrastructure, but with their current debt loads, I think > it will be challenging to say the least. > > Taking a look at Verizon - Their most recent quarterly balance sheet shows: > > http://finance.yahoo.com/q/bs?s=VZ > > Assets: 230.461 Billion USD > Liabilities: 194.491 Billion USD. > > This is not a lot of money, considering they have growing liabilities on a > quarterly basis as part of their debt load (Long-term debt of $50 Billion). > > A large fiber build would easily cost a few billion dollars and have lots > of regulatory barriers. In my county it costs $200 to go over or under any > public road (just for the permit). This starts to add up quickly. > > I do think we need a new last-mile regime in many areas, be it more "fair" > access similar to pole attach fees or the removal of local barriers to > build this infrastructure. > > Some school and other governments here in Michigan would love to > sell/lease their excess fiber capacity to the private sector, but are > worried about turning a profit when it was built with taxpayer funds and > problems associated with that. I'd like to see these barriers removed. If > it's there, lets make it of value. If the school system turns a profit on > their enterprise, that's fine, it can lower the tax burden elsewhere. > > Me? I'd be willing to pay $2500 to have Fiber built to my home. I might > even pay more. At this point, my research continues on building the fiber > and arranging my own easements for where to place it. I suspect you just > need a few geeks that are willing to part with some extra $ for fiber > bragging rights and one can build it. > > - Jared > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mfidelman at meetinghouse.net Mon Mar 26 11:34:44 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 26 Mar 2012 12:34:44 -0400 Subject: Muni Fiber In-Reply-To: <8C26A4FDAE599041A13EB499117D3C287C9E5A71@EX-MB-1.corp.atlasnetworks.us> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <8C26A4FDAE599041A13EB499117D3C287C9E5A71@EX-MB-1.corp.atlasnetworks.us> Message-ID: <4F709AA4.7080707@meetinghouse.net> Nathan Eisenberg wrote: >> -----Original Message----- >> From: joshua.klubi at gmail.com [mailto:joshua.klubi at gmail.com] >> >> But they also deserve to have or enjoy the benefits that comes with >> living in the big cities > > I grew up in a rural area served by dialup for the first 15 years of my life, so please don't misunderstand what I'm about to say. No, they don't. > > Living in a rural area is a different set of value propositions than living in the Big City, and we shouldn't pretend otherwise. Do people living in the big cities reap the benefits of living in the country? No ambient noise, no air pollution, low crime rates, neighbors you know and can trust your children with? No, they don't. > > That isn't to say that broadband technology won't (or shouldn't) find ways of serving people in rural areas with increasingly usable levels of throughput while decreasing jitter and loss; it already is (and should), and the situation is constantly improving. But I think it's a mistake to say that people who have made the decision to live in the Big City should expect to enjoy the same benefits as people who have made the decision to live in rural towns, and vice versa. They'll never be the same, and unless I'm very much mistaken, that's actually OK. There's truth to what you say, but there is another side that often gets missed. The rational for universal telephone service isn't just that rural residents need access, but that folks in denser areas need to be able to reach them - the value of a network connection lies not only in who can reach you, but who you can reach. A similar argument applies to broadband. In today's economy, supply chains are spread all across the map - extending networks into rural areas, is not just for the benefit of those who live in those rural areas. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From davidpeahi at gmail.com Mon Mar 26 12:53:32 2012 From: davidpeahi at gmail.com (david peahi) Date: Mon, 26 Mar 2012 10:53:32 -0700 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: I have discovered that the Federal School Lunch E-Rate program has built out an entirely parallel fiber optic infrastructure in the USA, bypassing telco fiber in many urban areas such as Los Angeles/Southern California. There are now companies that exist solely to construct E-Rate fiber. Sunesys is one such company. E-Rate builds out fiber to schools and libraries, and the telcos apparently have lobbied to ensure that a lateral to a library, for example, does not become a local fiber hub, but the backbone fiber can be used by anyone, with laterals built to order. I do not work for any of these E-Rate companies, but have discovered their potential use for connecting my network locations together. On Thu, Mar 22, 2012 at 9:26 AM, Jared Mauch wrote: > > On Mar 22, 2012, at 11:05 AM, chris wrote: > > > I'm all for VZ being able to reclaim it as long as they open their fiber > > which I don't see happening unless its by force via government. At the > end > > of the day there needs to be the ability to allow competitors in so of > > course they shouldnt be allowed to rip out the regulated part and replace > > it with a unregulated one. > > I think this partly captures the incentive case here, but there is also a > larger one at play. Over the years the copper infrastructure was installed > and extended through various incentive programs. You can see the > modern-day reflection of that in the RUS (used to manage rural > electrification act, part of USDA) and NTIA (Department of Commerce). > > The barriers to entry are significant for a new player in the marketplace. > The cost is putting the cabling in the ground vs the cost of the cable > itself. One can easily pick up hardware for $250 to light a single strand > of 9/125 SM fiber @ 10km for a 1Gb/s ethernet link. That's low enough you > could likely get a consumer to buy the hardware. The real cost is the > installation per strand foot/mile. > > In the past this has been subsidized for copper plant. There is no reason > in my mind that the fiber plant should be treated differently from this > standpoint. I can find fiber optic cabling for $0.25/ft. The problem here > is a multi-dimensional one that I've seen play out in a few markets: > > Verizon selling assets to Fairpoint (NH, ME, VT). These are high cost > areas due to low-density population. For the sale to go through, Fairpoint > had to agree to build into these higher cost areas. The result was > bankruptcy for Fairpoint. > > Verizon sold assets in Michigan (and other states) to Frontier. I've not > tracked this one as closely, but I suspect the economics of this are fairly > complex. > > I've also spoken to some small ISPs and their general cost of building > fiber to the home tends to be $2500/subscriber in upfront capital. This > covers just the installation cost. Due to years of subsidy and regulation, > people are unwilling to pay this amount to install a telecommunications > service whereas a new home requiring a connection to the water, sewers, > natural gas or electric grid may pay $10k or more to connect. Many people > wouldn't think of buying a home without electric service, but without > modern telecommunication service? I've seen this play out after the fact > with friends asking how to get service. Satellite, Fixed wireless or just > cellular data quickly become their fallbacks. The demand is there, the > challenge becomes recovering the build cost. > > It is my firm belief that without a regulatory regime it will not be > feasible to connect many communities robustly to modern communications > infrastructure. This could clearly change if the carriers involved see fit > to replace this infrastructure, but with their current debt loads, I think > it will be challenging to say the least. > > Taking a look at Verizon - Their most recent quarterly balance sheet shows: > > http://finance.yahoo.com/q/bs?s=VZ > > Assets: 230.461 Billion USD > Liabilities: 194.491 Billion USD. > > This is not a lot of money, considering they have growing liabilities on a > quarterly basis as part of their debt load (Long-term debt of $50 Billion). > > A large fiber build would easily cost a few billion dollars and have lots > of regulatory barriers. In my county it costs $200 to go over or under any > public road (just for the permit). This starts to add up quickly. > > I do think we need a new last-mile regime in many areas, be it more "fair" > access similar to pole attach fees or the removal of local barriers to > build this infrastructure. > > Some school and other governments here in Michigan would love to > sell/lease their excess fiber capacity to the private sector, but are > worried about turning a profit when it was built with taxpayer funds and > problems associated with that. I'd like to see these barriers removed. If > it's there, lets make it of value. If the school system turns a profit on > their enterprise, that's fine, it can lower the tax burden elsewhere. > > Me? I'd be willing to pay $2500 to have Fiber built to my home. I might > even pay more. At this point, my research continues on building the fiber > and arranging my own easements for where to place it. I suspect you just > need a few geeks that are willing to part with some extra $ for fiber > bragging rights and one can build it. > > - Jared > From chuckchurch at gmail.com Mon Mar 26 13:01:27 2012 From: chuckchurch at gmail.com (Chuck Church) Date: Mon, 26 Mar 2012 14:01:27 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: <005901cd0b7a$77c49520$674dbf60$@gmail.com> -----Original Message----- From: david peahi [mailto:davidpeahi at gmail.com] Sent: Monday, March 26, 2012 1:54 PM To: Jared Mauch Cc: nanog at nanog.org Subject: Re: last mile, regulatory incentives, etc (was: att fiber, et al) >I have discovered that the Federal School Lunch E-Rate program has built out an entirely parallel fiber optic infrastructure in the USA Lunch lady Doris has added a fiber splice kit to her collection of hairnets... Chuck From rodrick.brown at gmail.com Mon Mar 26 09:34:42 2012 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Mon, 26 Mar 2012 10:34:42 -0400 Subject: $1.5 billion: The cost of cutting London-Tokyo latency by 60ms In-Reply-To: <129926.1332768738@turing-police.cc.vt.edu> References: <20120323115345.GF9891@leitl.org> <30864.1332510464@turing-police.cc.vt.edu> <4F6CC4E4.5000005@mompl.net> <129926.1332768738@turing-police.cc.vt.edu> Message-ID: On Mar 26, 2012, at 9:32 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 26 Mar 2012 08:59:34 -0400, Rodrick Brown said: >> HIgh frequency trading does provide a service to the financial markets as a >> whole despite what the media and government politicians will have you think. > > OK, I'll bite. What benefit does the market *as a whole* get from the ability > to do trades in 60ms rather than 120ms? (Hint - the fact you can extract > money via more arbitrage transactions per minute is a benefit to the trader, > not the market as a whole - if you extract $100M from the market, it came > from somewhere....) In its core very liquid markets and market efficiency. The faster a trade executes is the faster the market can recover and self correct themselves from trading mishaps. Faster speeds has provided higher volume of shares traded which has directly lead to higher profits, higher tax income for governments, and the less likely-hood of being front-run by dishonest brokers and most of all lower transaction cost for the average market precipitant. HFT like anything else in the modern world is prime for abuse for anyone looking to manipulate the markets by taking advantage of certain rules or loopholes that legislation has not yet discovered or plugged. That being said I strongly believe high speed trading has done more good than bad for the financial markets as a whole. Lowering access time to the markets will only open up a new can of worms which will easily be circumvented by other loopholes and abused by those with the know how! Sorry for the off topic rant! From jmaimon at ttec.com Mon Mar 26 13:24:13 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 26 Mar 2012 14:24:13 -0400 Subject: Verizon, FiOS, and CLEC/UNE orders (was AT&T diversity) In-Reply-To: <616FD43B-9DFC-4033-8AEC-247A570F767F@delong.com> References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <02af01cd09ed$c288b250$479a16f0$@iname.com> <616FD43B-9DFC-4033-8AEC-247A570F767F@delong.com> Message-ID: <4F70B44D.1090604@ttec.com> Owen DeLong wrote: > Right, but a better approach would have been for the FCC to say "If you don't > build fiber, you won't keep getting USF money." > > The FCC failed to look at the public interest and got rolled by the RBOCs again. > > Owen > Regulatory capture. Nobody is immune. The only effective maintenance treatment is periodic upheaval. Joe From rps at maine.edu Mon Mar 26 14:46:04 2012 From: rps at maine.edu (Ray Soucy) Date: Mon, 26 Mar 2012 15:46:04 -0400 Subject: last mile, regulatory incentives, etc (was: att fiber, et al) In-Reply-To: References: <16083253.7473.1332356332235.JavaMail.root@benjamin.baylink.com> <4F6A28F6.1030705@mtcc.com> <4F6A2BEB.1000809@fluidhosting.com> <3E6EAB00-BA61-458A-BE17-43F7CE003C1E@puck.nether.net> Message-ID: It varies from state to state ... In Maine, we've run an E-rate filing consortium for several years that uses E-rate funds and makes up the difference with a state telecommunications tax so schools and libraries don't need to pay for service. Up until a year or two ago, Verizon was always contracted to provide transport services exclusively; this was mainly T1 and ATM circuits. Unfortunately, we were at a point where requests for more bandwidth than 1.5 Mbps were either being ignored, or being delivered via multiple T1 drops (hundreds of locations with dual T1 connections). Of course this was a big cash flow for the ILEC, but our K12 schools being connected at 1.5 or 3 Mbps in 2010 was not acceptable to us (especially when they were still able to bill 500-800 a month per circuit). In response to not being able to get movement on newer transport, we opened up the process to competitive bid and got services from other providers in the state depending on location; this resulted in Fairpoint delivering Ethernet over copper services to remain competitive with Time Warner Cable and others, and ultimately Fairpoint still was awarded the vast majority of contracts; without the competitive process that wouldn't have happened. Most upgrades were modest; 1.5M locations moved up to 10M, and ATM sites moved to a verity of rates between 20 and 100M depending on the size of the location, but an upgrade is an upgrade, and 1.5 Mbps today is unusable for a single person, let alone an entire school. With the build-out of MaineREN, our facilities based R&E network, we've picked up a few large schools directly because it's cheaper to do so; instead of schools receiving 100M service, we can deliver 1G for less money, and re-direct funds to increase our transit capacity. Maine Fiber Company and the MaineREN expansion will make that an attractive option for more schools, but only a handful that are directly along the route. To make sure Fairpoint, Time Warner, and others were able to realize ROI, we signed multi-year contracts with them. So in our case, E-rate has actually helped the private sector considerably, and we don't see that really changing. It's not in the interest of a state to compete with commercial providers if they want the state to have a healthy market. It was also the primary driver for us to push for the creation of a new public utility for dark fiber rather than having the University own everything, which is the direction most seem to go. That said, every market is different. The biggest problem I've seen is that as soon as "E-rate" is mentioned the price inflates because providers start to drool over public funding. Meanwhile everyone wants to pay lower taxes; seems counter-productive. Don't get me started on "E-rate consultants", most of them take a % cut of the awarded funds as compensation for filling out federal forms that can be completed in 30 min. Thankfully that's been limited to some extent here by the filing consortium, but I've heard stories from other states about some of these guys pulling in close to 7 digits. On Mon, Mar 26, 2012 at 1:53 PM, david peahi wrote: > I have discovered that the Federal School Lunch E-Rate program has built > out an entirely parallel fiber optic infrastructure in the USA, bypassing > telco fiber in many urban areas such as Los Angeles/Southern California. > There are now companies that exist solely to construct E-Rate fiber. > Sunesys is one such company. > E-Rate builds out fiber to schools and libraries, and the telcos apparently > have lobbied to ensure that a lateral to a library, for example, does not > become a local fiber hub, but the backbone fiber can be used by anyone, > with laterals built to order. > I do not work for any of these E-Rate companies, but have discovered their > potential use for connecting my network locations together. > > On Thu, Mar 22, 2012 at 9:26 AM, Jared Mauch > wrote: > > > > > On Mar 22, 2012, at 11:05 AM, chris wrote: > > > > > I'm all for VZ being able to reclaim it as long as they open their > fiber > > > which I don't see happening unless its by force via government. At the > > end > > > of the day there needs to be the ability to allow competitors in so of > > > course they shouldnt be allowed to rip out the regulated part and > replace > > > it with a unregulated one. > > > > I think this partly captures the incentive case here, but there is also a > > larger one at play. Over the years the copper infrastructure was > installed > > and extended through various incentive programs. You can see the > > modern-day reflection of that in the RUS (used to manage rural > > electrification act, part of USDA) and NTIA (Department of Commerce). > > > > The barriers to entry are significant for a new player in the > marketplace. > > The cost is putting the cabling in the ground vs the cost of the cable > > itself. One can easily pick up hardware for $250 to light a single > strand > > of 9/125 SM fiber @ 10km for a 1Gb/s ethernet link. That's low enough > you > > could likely get a consumer to buy the hardware. The real cost is the > > installation per strand foot/mile. > > > > In the past this has been subsidized for copper plant. There is no > reason > > in my mind that the fiber plant should be treated differently from this > > standpoint. I can find fiber optic cabling for $0.25/ft. The problem > here > > is a multi-dimensional one that I've seen play out in a few markets: > > > > Verizon selling assets to Fairpoint (NH, ME, VT). These are high cost > > areas due to low-density population. For the sale to go through, > Fairpoint > > had to agree to build into these higher cost areas. The result was > > bankruptcy for Fairpoint. > > > > Verizon sold assets in Michigan (and other states) to Frontier. I've not > > tracked this one as closely, but I suspect the economics of this are > fairly > > complex. > > > > I've also spoken to some small ISPs and their general cost of building > > fiber to the home tends to be $2500/subscriber in upfront capital. This > > covers just the installation cost. Due to years of subsidy and > regulation, > > people are unwilling to pay this amount to install a telecommunications > > service whereas a new home requiring a connection to the water, sewers, > > natural gas or electric grid may pay $10k or more to connect. Many > people > > wouldn't think of buying a home without electric service, but without > > modern telecommunication service? I've seen this play out after the fact > > with friends asking how to get service. Satellite, Fixed wireless or > just > > cellular data quickly become their fallbacks. The demand is there, the > > challenge becomes recovering the build cost. > > > > It is my firm belief that without a regulatory regime it will not be > > feasible to connect many communities robustly to modern communications > > infrastructure. This could clearly change if the carriers involved see > fit > > to replace this infrastructure, but with their current debt loads, I > think > > it will be challenging to say the least. > > > > Taking a look at Verizon - Their most recent quarterly balance sheet > shows: > > > > http://finance.yahoo.com/q/bs?s=VZ > > > > Assets: 230.461 Billion USD > > Liabilities: 194.491 Billion USD. > > > > This is not a lot of money, considering they have growing liabilities on > a > > quarterly basis as part of their debt load (Long-term debt of $50 > Billion). > > > > A large fiber build would easily cost a few billion dollars and have lots > > of regulatory barriers. In my county it costs $200 to go over or under > any > > public road (just for the permit). This starts to add up quickly. > > > > I do think we need a new last-mile regime in many areas, be it more > "fair" > > access similar to pole attach fees or the removal of local barriers to > > build this infrastructure. > > > > Some school and other governments here in Michigan would love to > > sell/lease their excess fiber capacity to the private sector, but are > > worried about turning a profit when it was built with taxpayer funds and > > problems associated with that. I'd like to see these barriers removed. > If > > it's there, lets make it of value. If the school system turns a profit > on > > their enterprise, that's fine, it can lower the tax burden elsewhere. > > > > Me? I'd be willing to pay $2500 to have Fiber built to my home. I might > > even pay more. At this point, my research continues on building the > fiber > > and arranging my own easements for where to place it. I suspect you just > > need a few geeks that are willing to part with some extra $ for fiber > > bragging rights and one can build it. > > > > - Jared > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From jra at baylink.com Mon Mar 26 14:46:44 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 26 Mar 2012 15:46:44 -0400 (EDT) Subject: Muni Fiber In-Reply-To: <4F6F60D3.6030703@foobar.org> Message-ID: <7420396.8381.1332791204059.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Nick Hilliard" > > wiring center you enable all technologies. GPON today, direct GigE > > or 10GE where necessary, and all future technologies. > > yep, agreed - much more sensible, much more resilient to failure and > only marginally more expensive. > > It'll never be done though. Too much to lose by creating a topology > which allows you to unbundle the tail. A municipality hasn't much to lose; they can declare a monopoly. Which was rather precisely the point. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From jra at baylink.com Mon Mar 26 14:51:35 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 26 Mar 2012 15:51:35 -0400 (EDT) Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <4F6F73F4.3070204@gmail.com> Message-ID: <4781749.8383.1332791495681.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "JC Dill" > On 25/03/12 8:56 AM, Leo Bicknell wrote: > > In a message written on Sun, Mar 25, 2012 at 11:47:58AM -0400, Jay > > Ashworth wrote: > >> Well, for my part, /most of the poiny/ of muni is The Public Good; > >> if /actual/ bond financed muni fiber is skipping the Hard Parts, it > >> deserves to lose. > > It doesn't matter if it's a bond-financed project or a privately > funded (privately owned) project - they are using a public resource (the > street/poles) to lay their lines, and usually also using the power of > the municipality's right to eminent domain to put in or use poles (or > underground conduits) to run lines across private properties. As part > of the Public Good contract to use these public resources, they should > be required to service both the the easy parts and the hard parts, no > matter the source of the financing or the ownership of the lines. Yup; that's what I said. But it cannot be privately financed; *it must be the property of the municipality*, legally. I don't care if they sub out the actual trench and splice, or even the operation of layer 1... but they have to own it; that's the whole point. > > Fiber has a 20-50 year life. > > The biggest problem is determining how certain that lifespan is. > Remember how Netflix looked like an awesome business to deliver DVDs by > mail in 2002, and had one of the most successful IPOs of the era? Less > than 10 years later we have widespread broadband and companies can > deliver that same content by copper/fiber/802.11. Now Netflix is in the > position of being in direct business conflict with the companies they > rely on to carry their product to their customers (e.g. Comcast) and > their future is very uncertain. Can you promise that fiber has a > *feasible* lifetime of 20-50 years? Maybe in 5-10 years all consumer > data will be transferred via wireless, and investment in municipal > wired data systems (fiber and copper) becomes worthless. His assertion wasn't economic life, it was *functional* life; I think we're pretty close to 50 years from the first deployment of optical fiber, and I think it's still serviceable. The question here is: did you design layer 1 properly, so as to make it cost-competitive for a long time (see the other thread on this). Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From rps at maine.edu Mon Mar 26 14:53:19 2012 From: rps at maine.edu (Ray Soucy) Date: Mon, 26 Mar 2012 15:53:19 -0400 Subject: Muni Fiber In-Reply-To: <7420396.8381.1332791204059.JavaMail.root@benjamin.baylink.com> References: <4F6F60D3.6030703@foobar.org> <7420396.8381.1332791204059.JavaMail.root@benjamin.baylink.com> Message-ID: True, but it's the one monopoly where you get a vote. I'm not sure it's fair to call a municipality a monopoly ... but that's just me. On Mon, Mar 26, 2012 at 3:46 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Nick Hilliard" > > > > wiring center you enable all technologies. GPON today, direct GigE > > > or 10GE where necessary, and all future technologies. > > > > yep, agreed - much more sensible, much more resilient to failure and > > only marginally more expensive. > > > > It'll never be done though. Too much to lose by creating a topology > > which allows you to unbundle the tail. > > A municipality hasn't much to lose; they can declare a monopoly. > > Which was rather precisely the point. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 > 1274 > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From jra at baylink.com Mon Mar 26 14:58:47 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 26 Mar 2012 15:58:47 -0400 (EDT) Subject: Muni Fiber In-Reply-To: Message-ID: <12434755.8395.1332791927186.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ray Soucy" > On Mon, Mar 26, 2012 at 3:46 PM, Jay Ashworth wrote: > > > It'll never be done though. Too much to lose by creating a > > > topology which allows you to unbundle the tail. > > > > A municipality hasn't much to lose; they can declare a monopoly. > > > > Which was rather precisely the point. > True, but it's the one monopoly where you get a vote. > I'm not sure it's fair to call a municipality a monopoly ... but > that's just me. I wasn't clear (again; I have to work harder on that -- it made sense to *me* :-)... A municipality can declare a monopoly on the installation of fiber within its jurisdictional bounds, and *require* anyone who wants to connect its residents to use its fiber; it *owns* (or has easements on) all the spaces necessary to do subterranean fiber (and I believe it leases such easements to power utilities to erect their poles, and may therefore have control over that as well, though I'd have to research that point. Clearly, I think that's a feature, not a but (if you've been following the thread)... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From shadowedstrangerlists at gmail.com Mon Mar 26 19:04:18 2012 From: shadowedstrangerlists at gmail.com (Jacob Broussard) Date: Mon, 26 Mar 2012 17:04:18 -0700 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <92177.1332705649@turing-police.cc.vt.edu> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> Message-ID: Who knows what technology will be like in 5-10 years? That's the whole point of what he was trying to say. Maybe wireless carriers will use visible wavelength lasers to recievers on top of customer's houses for all we know. 10 years is a LONG time for tech, and anything can happen. On Mar 25, 2012 1:01 PM, wrote: > On Sun, 25 Mar 2012 12:37:24 -0700, JC Dill said: > > > *feasible* lifetime of 20-50 years? Maybe in 5-10 years all consumer > > data will be transferred via wireless > > And that would be using what spectrum and what technology? Consider what > the > release of one Apple product did to the associated carrier's wireless net. > Then consider the current tendency for "unlimited wireless data" to mean > 2-3G > per month. > > Where's the economic incentive for all these carriers to build out enough > capacity to move "all consumer data" (or a large fraction anyhow), and > lower > their prices to match? > > Sure, it may happen *eventually*, but for it to happen in 5-10 years, it > would > have to be in motion *now*. So who's already in motion? > From bill at herrin.us Mon Mar 26 19:45:24 2012 From: bill at herrin.us (William Herrin) Date: Mon, 26 Mar 2012 20:45:24 -0400 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> Message-ID: On Mon, Mar 26, 2012 at 8:04 PM, Jacob Broussard wrote: > Who knows what technology will be like in 5-10 years? ?That's the whole > point of what he was trying to say. ?Maybe wireless carriers will use > visible wavelength lasers to recievers on top of customer's houses for all > we know. ?10 years is a LONG time for tech, and anything can happen. Hi Jacob, The scientists doing the basic research now know. It's referred to as the "technology pipeline." When someone says, "that's in the pipeline" they mean that the basic science has been discovered to make something possible and now engineers are in the process of figuring out how to make it _viable_. The pipeline tends to be 5 to 10 years long, so basic science researchers are making the discoveries *now* which will be reflected in deployed technologies 10 years from now. There is *nothing* promising in the pipeline for wireless tech that has any real chance of leading to a wide scale replacement for fiber optic cable. *Nothing.* Which means that in 10 years, wireless will be better, faster and cheaper but it won't have made significant inroads replacing fiber to the home and business. 20 years is a long time. 10 years, not so much. Even for the long times, we can find the future by examining the past. The duration of use of the predecessor technology (twisted pair) was about 50 years ubiquitously deployed to homes. From that we can make an educated guess about the current one (fiber). Fiber to the home started about 10 years ago leaving about 40 more before something better might replace it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rps at maine.edu Tue Mar 27 08:41:26 2012 From: rps at maine.edu (Ray Soucy) Date: Tue, 27 Mar 2012 09:41:26 -0400 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> Message-ID: Ignoring the fact that we haven't reached our limits with fiber yet ... If you're talking broadband, I think it's pretty reasonable to suggest that a fiber plant will last 20 years with minor maintenance just given the history of how long we've used copper. When its 2012 and you have people who are still on DSL with 768K "broadband", it's nice to toss around the theory that technology moves fast and that 20 years from now everyone will have Terabit to the home over wireless, but I really don't see it. Back in the 90s I was sure everyone would have 100M to the home by now. The next major speed boost for broadband will be over fiber. And because the bottleneck at that point becomes equipment, we'll continue to see a healthy round of upgrades in speed over the same fiber plant. If people got serious about FTTH, I think a _very_ optimistic timeline would be something like: 2015 - First communities coming online, 100M to the home (probably Gigabit line rate, but throttled). 2020 - Gigabit to the home starting to become common 2030 - Gigabit to the home "typical" 2035 - 10G to the home starting to become common 2040 - Newer optics require better fiber for back haul, minor upgrades to middle-mile needed to push speeds. 2050 - People finally agree to invest in those upgrades after "suffering" 10 years of "only" 10G to the home. On Mon, Mar 26, 2012 at 8:45 PM, William Herrin wrote: > On Mon, Mar 26, 2012 at 8:04 PM, Jacob Broussard > wrote: > > Who knows what technology will be like in 5-10 years? That's the whole > > point of what he was trying to say. Maybe wireless carriers will use > > visible wavelength lasers to recievers on top of customer's houses for > all > > we know. 10 years is a LONG time for tech, and anything can happen. > > Hi Jacob, > > The scientists doing the basic research now know. It's referred to as > the "technology pipeline." When someone says, "that's in the pipeline" > they mean that the basic science has been discovered to make something > possible and now engineers are in the process of figuring out how to > make it _viable_. The pipeline tends to be 5 to 10 years long, so > basic science researchers are making the discoveries *now* which will > be reflected in deployed technologies 10 years from now. > > There is *nothing* promising in the pipeline for wireless tech that > has any real chance of leading to a wide scale replacement for fiber > optic cable. *Nothing.* Which means that in 10 years, wireless will be > better, faster and cheaper but it won't have made significant inroads > replacing fiber to the home and business. > > 20 years is a long time. 10 years, not so much. Even for the long > times, we can find the future by examining the past. The duration of > use of the predecessor technology (twisted pair) was about 50 years > ubiquitously deployed to homes. From that we can make an educated > guess about the current one (fiber). Fiber to the home started about > 10 years ago leaving about 40 more before something better might > replace it. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mfidelman at meetinghouse.net Tue Mar 27 09:02:57 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 27 Mar 2012 10:02:57 -0400 Subject: Muni Fiber In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> Message-ID: <4F71C891.6020102@meetinghouse.net> Ray Soucy wrote: > > If people got serious about FTTH, I think a _very_ optimistic timeline > would be something like: Not optimistic at all, technically or operationally. Politically and legally are another matter: > > 2015 - First communities coming online, 100M to the home (probably Gigabit > line rate, but throttled). There's been quite a lot of FTTH for quite a few years now. In addition to the Verizon FIOS stuff - up to 135mbps down/ 35mbps up available where I am (though I've been quite happy with lower speeds). Municipal electric utilities have been deploying fiber right and left. Probably 200 systems operational. The two that come to mind immediately are: Chattanooga, TN - GigE FTTH Today - http://chattanoogagig.com/ - Grant County PUD (public utility district), OR has had the fiber in for a few years, selling wholesale - not sure what specific retail services are available There'd probably be a lot more available if the big telcos and cable companies weren't doing everything they can to block municipal bids. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From jim at impactbusiness.com Tue Mar 27 09:16:28 2012 From: jim at impactbusiness.com (Jim Gonzalez) Date: Tue, 27 Mar 2012 10:16:28 -0400 Subject: OWA blocked by China Message-ID: <00dd01cd0c24$3b865df0$b29319d0$@impactbusiness.com> Hello, One of my customers has workers in China. There outlook web access is blocked by the China Firewall. I was just wondering if anyone had this issue ? I have not tried any work arounds as of yet just gathering info Thanks in advance Jim Gonzalez From jra at baylink.com Tue Mar 27 09:33:53 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 27 Mar 2012 10:33:53 -0400 (EDT) Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: Message-ID: <21126055.8613.1332858833621.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ray Soucy" > Ignoring the fact that we haven't reached our limits with fiber yet > ... Not close, and we're at 100G already. > The next major speed boost for broadband will be over fiber. And because > the bottleneck at that point becomes equipment, we'll continue to see a > healthy round of upgrades in speed over the same fiber plant. And, much more to the point, ONTs will go over the edge of the Consumer Pricing S-curve. Bet *cash* on this. But another more interesting point being missed here is this: Assuming pointopoint fiber, *you can provision different classes of service appropriately*. If some client wants to pay for 40G fiber? Cool. You can do that. That in itself seems to positively skew the potential for muni layer 1 installs, to me. And it doesn't *preclude* the muni operating a standardized layer 2 for those carriers who don't want to do that part themselves; economy of scale will actually be productive there, I suspect. Anyone want to start Level 1 Communications? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From lyle at lcrcomputer.net Tue Mar 27 09:36:30 2012 From: lyle at lcrcomputer.net (Lyle Giese) Date: Tue, 27 Mar 2012 09:36:30 -0500 Subject: OWA blocked by China In-Reply-To: <00dd01cd0c24$3b865df0$b29319d0$@impactbusiness.com> References: <00dd01cd0c24$3b865df0$b29319d0$@impactbusiness.com> Message-ID: <4F71D06E.3070202@lcrcomputer.net> On 03/27/12 09:16, Jim Gonzalez wrote: > Hello, > > One of my customers has workers in China. There outlook web > access is blocked by the China Firewall. I was just wondering if anyone had > this issue ? I have not tried any work arounds as of yet just gathering info > > > Thanks in advance > > Jim Gonzalez > > > Common practice in China. Typically the block comes and goes. Here today, gone tomorrow. However if the OWA server is on a dynamic IP or you use a dynamic IP address service for ip address resolution, then it will be blocked all the time by China. It's just the way things are done over there. Lyle Giese LCR Computer Services, Inc. From leigh.porter at ukbroadband.com Tue Mar 27 09:39:56 2012 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 27 Mar 2012 14:39:56 +0000 Subject: OWA blocked by China In-Reply-To: <4F71D06E.3070202@lcrcomputer.net> References: <00dd01cd0c24$3b865df0$b29319d0$@impactbusiness.com> <4F71D06E.3070202@lcrcomputer.net> Message-ID: Are there any issues with general https there also? -- Leigh > -----Original Message----- > From: Lyle Giese [mailto:lyle at lcrcomputer.net] > Sent: 27 March 2012 15:39 > To: nanog at nanog.org > Subject: Re: OWA blocked by China > > On 03/27/12 09:16, Jim Gonzalez wrote: > > Hello, > > > > One of my customers has workers in China. There > > outlook web access is blocked by the China Firewall. I was just > > wondering if anyone had this issue ? I have not tried any work > arounds > > as of yet just gathering info > > > > > > Thanks in advance > > > > Jim Gonzalez > > > > > > > Common practice in China. Typically the block comes and goes. Here > today, gone tomorrow. > > However if the OWA server is on a dynamic IP or you use a dynamic IP > address service for ip address resolution, then it will be blocked all > the time by China. > > It's just the way things are done over there. > > Lyle Giese > LCR Computer Services, Inc. > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud > service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From lyle at lcrcomputer.net Tue Mar 27 09:43:57 2012 From: lyle at lcrcomputer.net (Lyle Giese) Date: Tue, 27 Mar 2012 09:43:57 -0500 Subject: OWA blocked by China In-Reply-To: References: <00dd01cd0c24$3b865df0$b29319d0$@impactbusiness.com> <4F71D06E.3070202@lcrcomputer.net> Message-ID: <4F71D22D.5080208@lcrcomputer.net> On 03/27/12 09:39, Leigh Porter wrote: > Are there any issues with general https there also? > > -- > Leigh > > >> -----Original Message----- >> From: Lyle Giese [mailto:lyle at lcrcomputer.net] >> Sent: 27 March 2012 15:39 >> To: nanog at nanog.org >> Subject: Re: OWA blocked by China >> >> On 03/27/12 09:16, Jim Gonzalez wrote: >>> Hello, >>> >>> One of my customers has workers in China. There >>> outlook web access is blocked by the China Firewall. I was just >>> wondering if anyone had this issue ? I have not tried any work >> arounds >>> as of yet just gathering info >>> >>> >>> Thanks in advance >>> >>> Jim Gonzalez >>> >>> >>> >> Common practice in China. Typically the block comes and goes. Here >> today, gone tomorrow. >> >> However if the OWA server is on a dynamic IP or you use a dynamic IP >> address service for ip address resolution, then it will be blocked all >> the time by China. >> >> It's just the way things are done over there. >> >> Lyle Giese >> LCR Computer Services, Inc. >> >> Not in general, it appears that most of the blocks seem to occur at the DNS level from my experience. However we have seen blocks on port 80 or 443 but infrequently. I have had a customer with sales persons in China for about 10 years now and they are ones that are quick to complain. So we have gone through the cycles of various blocks over the years. But putting their in house server on a static IP address and getting their OWA server address resolution out of dynamic name resolution services seemed to help the most. Lyle Giese LCR Computer Services, Inc. From tshaw at oitc.com Tue Mar 27 09:45:25 2012 From: tshaw at oitc.com (TR Shaw) Date: Tue, 27 Mar 2012 10:45:25 -0400 Subject: OWA blocked by China In-Reply-To: <00dd01cd0c24$3b865df0$b29319d0$@impactbusiness.com> References: <00dd01cd0c24$3b865df0$b29319d0$@impactbusiness.com> Message-ID: On Mar 27, 2012, at 10:16 AM, Jim Gonzalez wrote: > Hello, > > One of my customers has workers in China. There outlook web > access is blocked by the China Firewall. I was just wondering if anyone had > this issue ? I have not tried any work arounds as of yet just gathering info > Jim Try a tunnel? Tom From straterra at fuhell.com Tue Mar 27 09:50:53 2012 From: straterra at fuhell.com (Thomas York) Date: Tue, 27 Mar 2012 10:50:53 -0400 Subject: OWA blocked by China In-Reply-To: References: <00dd01cd0c24$3b865df0$b29319d0$@impactbusiness.com> Message-ID: <008501cd0c29$0383bc90$0a8b35b0$@fuhell.com> Good luck with that. I have three plants in China and China Telecom loves batting down our VPN tunnels. They've left the current solution alone for a few months now. It appears they try to do DPI on SSL/IPSec to see if it's a VPN tunnel. I placed our SSL OpenVPN tunnel inside of a GRE tunnel. For some reason, they don't seem to be doing DPI on it and mostly leave it alone now. I'm sure it'll change at some point soon, though. -- Thomas York -----Original Message----- From: TR Shaw [mailto:tshaw at oitc.com] Sent: Tuesday, March 27, 2012 10:45 AM To: Jim Gonzalez Cc: nanog at nanog.org Subject: Re: OWA blocked by China On Mar 27, 2012, at 10:16 AM, Jim Gonzalez wrote: > Hello, > > One of my customers has workers in China. There outlook > web access is blocked by the China Firewall. I was just wondering if > anyone had this issue ? I have not tried any work arounds as of yet > just gathering info > Jim Try a tunnel? Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7138 bytes Desc: not available URL: From rps at maine.edu Tue Mar 27 09:57:51 2012 From: rps at maine.edu (Ray Soucy) Date: Tue, 27 Mar 2012 10:57:51 -0400 Subject: Muni Fiber In-Reply-To: <4F71C891.6020102@meetinghouse.net> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> <4F71C891.6020102@meetinghouse.net> Message-ID: "Politically and legally are another matter" being key ;-) It was a long hard fight even in Maine to get a dark fiber utility (over a year of going before the legislature). The ILEC lobbyists are very influential and want to maintain the status quo at all costs. A lot of the examples you listed are pilot projects that providers do mostly for PR purposes so they can say "we provide FTTH" with a "* in select areas" footnote. They rarely see any large scale adoption and are usually operated at a loss. I think the key problem is that building out fiber doesn't make business sense if each provider in an area has to build out identical infrastructure and doesn't have the safety of a monopoly. As mentioned, providers are also concerned with the time it will take to realize ROI. The result is that we need to subsidize this infrastructure if we want it, but we end up with no competition and poor service if the service provider is the one getting those subsidies. Aside from very urban areas where the density can support the investment, the only solution becomes to create an open access public utility to maintain the fiber plant, cans, huts, etc. and prohibit them from offering any lit services over that fiber. As for rural areas not needing broadband; I think it's a matter of national interest that everyone has access to broadband. Just like power. When we make an effort to lift everyone up, we all do better. The Internet, like the Interstate highway system, is a time machine. It shortens distances between people and makes us more productive. Even better, it allows businesses to locate anywhere. On Tue, Mar 27, 2012 at 10:02 AM, Miles Fidelman wrote: > Ray Soucy wrote: > >> >> If people got serious about FTTH, I think a _very_ optimistic timeline >> would be something like: >> > > Not optimistic at all, technically or operationally. Politically and > legally are another matter: > >> >> 2015 - First communities coming online, 100M to the home (probably Gigabit >> line rate, but throttled). >> > > There's been quite a lot of FTTH for quite a few years now. In addition > to the Verizon FIOS stuff - up to 135mbps down/ 35mbps up available where I > am (though I've been quite happy with lower speeds). > > Municipal electric utilities have been deploying fiber right and left. > Probably 200 systems operational. The two that come to mind immediately > are: > > Chattanooga, TN - GigE FTTH Today - http://chattanoogagig.com/ - > > Grant County PUD (public utility district), OR has had the fiber in for a > few years, selling wholesale - not sure what specific retail services are > available > > There'd probably be a lot more available if the big telcos and cable > companies weren't doing everything they can to block municipal bids. > > > > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Tue Mar 27 10:03:44 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Mar 2012 08:03:44 -0700 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> Message-ID: Actual public financed non-muni fiber is skipping the easy parts and deploying only a few of the hard parts. (current actual results of USF) How is that an improvement? Owen On Mar 25, 2012, at 8:47 AM, Jay Ashworth wrote: > Well, for my part, /most of the poiny/ of muni is The Public Good; if /actual/ bond financed muni fiber is skipping the Hard Parts, it deserves to lose. > > Time to assemble some stats, I guess. > -- jra > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > Owen DeLong wrote: > Who cares? > > It's time to stop letting rural deployments stand in the way of municipal deployments. > > It's a natural part of living outside of a population center that it costs more to bring utility services to you. I'm not entirely opposed (though somewhat) to subsidizing that to some extent, but, I'm tired of municipal deployments being blocked by this sense of equal entitlement to rural. > > The rural builds cost more, take longer, and yield lower revenues. It makes no sense to let that stand in the way of building out municipalities. Nothing prevents rural residents who have the means and really want their buildout prioritized from building a collective to get it done. > > Subsidizing rural build-out is one thing. Failing to build out municipalities because of some sense of rural entitlement? That's just stupid. > > Owen > > > Sent from my iPa > d > > On Mar 24, 2012, at 12:42 PM, "Frank Bulk" wrote: > > > How many munis serve the rural like they do the urban? > > > > In the vast majority of cases the munis end up doing what ILECs only wish they could do -- serve the most profitable customers. > > > > Frank > > > > -----Original Message----- > > From: Jay Ashworth [mailto:jra at baylink.com] > > Sent: Thursday, March 22, 2012 12:52 PM > > To: NANOG > > Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) > > > > > > > > Oh, it's *much* worse than that, John. > > > > The *right*, long term solution to all of these problems is for > > municipalities to do the fiber build, properly engineered, and even > > subbed out to a contractor to build and possibly operate... > > > > offering *only* layer 1 service at wholesale. Any comer > can > light up > > each city's pop, and offer retail service over the FTTH fiber to that > > customer at whatever rate they like, and the city itself doesn't offer > > layer 2 or 3 service at all. > > > > High-speed optical data *is* the next natural monopoly, after power > > and water/sewer delivery, and it's time to just get over it and do it > > right. > > > > As you might imagine, this environment -- one where the LEC doesn't own > > the physical plant -- scares the ever-lovin' daylights out of Verizon > > (among others), so much so that they *have gotten it made illegal* in > > several states, and they're lobbying to expand that footprint. > > > > See, among other sites: http://www.muninetworks.org/ > > > > As you might imagine, I am a fairly strong proponent of muni layer 1 -- > > or even layer 2, where the municipality suppli > es > (matching) ONTs, and > > services have to fit over GigE -- fiber delivery of high-speed data > > service. > > > > I believe Google agrees with me. :-) > > > > Cheers, > > -- jra > > > > Cheers, > > -- jra > > -- > > Jay R. Ashworth Baylink jra at baylink.com > > Designer The Things I Think RFC 2100 > > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > > > > > > From owen at delong.com Tue Mar 27 10:19:46 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Mar 2012 08:19:46 -0700 Subject: Muni Fiber In-Reply-To: <20120325183405.GA90100@ussenterprise.ufp.org> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F47D0.6020106@foobar.org> <20120325175820.GA89077@ussenterprise.ufp.org> <4F6F60D3.6030703@foobar.org> <20120325183405.GA90100@ussenterprise.ufp.org> Message-ID: <72636209-A7EF-4AB8-A145-55D6B3A06EAD@delong.com> > > Politically the makings of a similar situation already exist. > Goverment has swung the USF funds to fuel rual broadband, strongly > favoring FTTx where it makes sense. While companies like Verizon > enjoy not having to share their fiber lines now, these same forces > will conspire to drive unbundling in fiber, just as it did in copper. > What they are getting now is simply a first mover advantage. > It's a bigger first mover advantage. They've learned their lesson from the copper unbundling and they are being allowed to deploy fiber in ways that will make it hard (impossible) to sell it on an unbundled basis later. > Government at the end of the day will fund the 20-40% of America > which is profitable in the long run, but not in commercial time > scales. They will also fund the 10% of America which will never > be profitable, no mater what. It happened with Electricity and > Telephone, and I suspect the societal drivers to do the same with > the Internet will be even stronger. Companies will have to accept an > unbundled tail to get access to this 30-50% of the market; and while > they aren't interested now, they will be very soon. Maybe, but, if what is happening now is allowed to continue, it will: 1. Not encourage competition anywhere. 2. Allow existing monopolies to preserve and extend those monopolies. 3. Cost even more than it already has. 4. Continue to lag behind the rest of the world. 5. Result in an inferior solution. What is needed is for regulators to step up with a bold vision for the public good. We need to encourage (or even require) local authorities to deploy (themselves or by contract) independent L1 infrastructure (yes, I like the 4-8 strands per residence star topology idea) to every structure within their jurisdiction and make it available to L2+ service providers on an equal-cost-per-subscriber basis in each jurisdiction. Yes, this means that the cost per subscriber will be lower in denser jurisdictions than it will be in less dense jurisdictions. However, users in those jurisdictions should expect to pay more for services and the ability to attract L2+ service providers can be achieved in a variety of ways. The important thing is to make sure that if public money is being used to build infrastructure, it becomes infrastructure that is useful to said public and not just a subsidy to some corporation for extending its monopoly in a manner that is often contrary to the public good. Unfortunately, that is exactly where the money is going today. Owen From sean.frasier at twcable.com Tue Mar 27 10:34:28 2012 From: sean.frasier at twcable.com (Frasier, Sean) Date: Tue, 27 Mar 2012 11:34:28 -0400 Subject: NANOG Digest, Vol 50, Issue 113 Message-ID: <1478BE618E5EC24BB62290CC564410D35B8B47B5@PRVPEXVS10.corp.twcable.com> Rrlr ----- Original Message ----- From: nanog-request at nanog.org To: nanog at nanog.org Sent: Tue Mar 27 11:22:36 2012 Subject: NANOG Digest, Vol 50, Issue 113 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: OWA blocked by China (TR Shaw) 2. RE: OWA blocked by China (Thomas York) 3. Re: Muni Fiber (Ray Soucy) 4. Re: Muni Fiber (was: Re: last mile, regulatory incentives, etc) (Owen DeLong) 5. Re: Muni Fiber (Owen DeLong) ---------------------------------------------------------------------- Message: 1 Date: Tue, 27 Mar 2012 10:45:25 -0400 From: TR Shaw To: Jim Gonzalez Cc: nanog at nanog.org Subject: Re: OWA blocked by China Message-ID: Content-Type: text/plain; charset=us-ascii On Mar 27, 2012, at 10:16 AM, Jim Gonzalez wrote: > Hello, > > One of my customers has workers in China. There outlook web > access is blocked by the China Firewall. I was just wondering if anyone had > this issue ? I have not tried any work arounds as of yet just gathering info > Jim Try a tunnel? Tom ------------------------------ Message: 2 Date: Tue, 27 Mar 2012 10:50:53 -0400 From: "Thomas York" To: , Cc: nanog at nanog.org Subject: RE: OWA blocked by China Message-ID: <008501cd0c29$0383bc90$0a8b35b0$@fuhell.com> Content-Type: text/plain; charset="us-ascii" Good luck with that. I have three plants in China and China Telecom loves batting down our VPN tunnels. They've left the current solution alone for a few months now. It appears they try to do DPI on SSL/IPSec to see if it's a VPN tunnel. I placed our SSL OpenVPN tunnel inside of a GRE tunnel. For some reason, they don't seem to be doing DPI on it and mostly leave it alone now. I'm sure it'll change at some point soon, though. -- Thomas York -----Original Message----- From: TR Shaw [mailto:tshaw at oitc.com] Sent: Tuesday, March 27, 2012 10:45 AM To: Jim Gonzalez Cc: nanog at nanog.org Subject: Re: OWA blocked by China On Mar 27, 2012, at 10:16 AM, Jim Gonzalez wrote: > Hello, > > One of my customers has workers in China. There outlook > web access is blocked by the China Firewall. I was just wondering if > anyone had this issue ? I have not tried any work arounds as of yet > just gathering info > Jim Try a tunnel? Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7138 bytes Desc: not available URL: ------------------------------ Message: 3 Date: Tue, 27 Mar 2012 10:57:51 -0400 From: Ray Soucy To: Miles Fidelman Cc: NANOG Subject: Re: Muni Fiber Message-ID: Content-Type: text/plain; charset=ISO-8859-1 "Politically and legally are another matter" being key ;-) It was a long hard fight even in Maine to get a dark fiber utility (over a year of going before the legislature). The ILEC lobbyists are very influential and want to maintain the status quo at all costs. A lot of the examples you listed are pilot projects that providers do mostly for PR purposes so they can say "we provide FTTH" with a "* in select areas" footnote. They rarely see any large scale adoption and are usually operated at a loss. I think the key problem is that building out fiber doesn't make business sense if each provider in an area has to build out identical infrastructure and doesn't have the safety of a monopoly. As mentioned, providers are also concerned with the time it will take to realize ROI. The result is that we need to subsidize this infrastructure if we want it, but we end up with no competition and poor service if the service provider is the one getting those subsidies. Aside from very urban areas where the density can support the investment, the only solution becomes to create an open access public utility to maintain the fiber plant, cans, huts, etc. and prohibit them from offering any lit services over that fiber. As for rural areas not needing broadband; I think it's a matter of national interest that everyone has access to broadband. Just like power. When we make an effort to lift everyone up, we all do better. The Internet, like the Interstate highway system, is a time machine. It shortens distances between people and makes us more productive. Even better, it allows businesses to locate anywhere. On Tue, Mar 27, 2012 at 10:02 AM, Miles Fidelman wrote: > Ray Soucy wrote: > >> >> If people got serious about FTTH, I think a _very_ optimistic timeline >> would be something like: >> > > Not optimistic at all, technically or operationally. Politically and > legally are another matter: > >> >> 2015 - First communities coming online, 100M to the home (probably Gigabit >> line rate, but throttled). >> > > There's been quite a lot of FTTH for quite a few years now. In addition > to the Verizon FIOS stuff - up to 135mbps down/ 35mbps up available where I > am (though I've been quite happy with lower speeds). > > Municipal electric utilities have been deploying fiber right and left. > Probably 200 systems operational. The two that come to mind immediately > are: > > Chattanooga, TN - GigE FTTH Today - http://chattanoogagig.com/ - > > Grant County PUD (public utility district), OR has had the fiber in for a > few years, selling wholesale - not sure what specific retail services are > available > > There'd probably be a lot more available if the big telcos and cable > companies weren't doing everything they can to block municipal bids. > > > > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ ------------------------------ Message: 4 Date: Tue, 27 Mar 2012 08:03:44 -0700 From: Owen DeLong To: Jay Ashworth Cc: NANOG Subject: Re: Muni Fiber (was: Re: last mile, regulatory incentives, etc) Message-ID: Content-Type: text/plain; charset=us-ascii Actual public financed non-muni fiber is skipping the easy parts and deploying only a few of the hard parts. (current actual results of USF) How is that an improvement? Owen On Mar 25, 2012, at 8:47 AM, Jay Ashworth wrote: > Well, for my part, /most of the poiny/ of muni is The Public Good; if /actual/ bond financed muni fiber is skipping the Hard Parts, it deserves to lose. > > Time to assemble some stats, I guess. > -- jra > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > Owen DeLong wrote: > Who cares? > > It's time to stop letting rural deployments stand in the way of municipal deployments. > > It's a natural part of living outside of a population center that it costs more to bring utility services to you. I'm not entirely opposed (though somewhat) to subsidizing that to some extent, but, I'm tired of municipal deployments being blocked by this sense of equal entitlement to rural. > > The rural builds cost more, take longer, and yield lower revenues. It makes no sense to let that stand in the way of building out municipalities. Nothing prevents rural residents who have the means and really want their buildout prioritized from building a collective to get it done. > > Subsidizing rural build-out is one thing. Failing to build out municipalities because of some sense of rural entitlement? That's just stupid. > > Owen > > > Sent from my iPa > d > > On Mar 24, 2012, at 12:42 PM, "Frank Bulk" wrote: > > > How many munis serve the rural like they do the urban? > > > > In the vast majority of cases the munis end up doing what ILECs only wish they could do -- serve the most profitable customers. > > > > Frank > > > > -----Original Message----- > > From: Jay Ashworth [mailto:jra at baylink.com] > > Sent: Thursday, March 22, 2012 12:52 PM > > To: NANOG > > Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) > > > > > > > > Oh, it's *much* worse than that, John. > > > > The *right*, long term solution to all of these problems is for > > municipalities to do the fiber build, properly engineered, and even > > subbed out to a contractor to build and possibly operate... > > > > offering *only* layer 1 service at wholesale. Any comer > can > light up > > each city's pop, and offer retail service over the FTTH fiber to that > > customer at whatever rate they like, and the city itself doesn't offer > > layer 2 or 3 service at all. > > > > High-speed optical data *is* the next natural monopoly, after power > > and water/sewer delivery, and it's time to just get over it and do it > > right. > > > > As you might imagine, this environment -- one where the LEC doesn't own > > the physical plant -- scares the ever-lovin' daylights out of Verizon > > (among others), so much so that they *have gotten it made illegal* in > > several states, and they're lobbying to expand that footprint. > > > > See, among other sites: http://www.muninetworks.org/ > > > > As you might imagine, I am a fairly strong proponent of muni layer 1 -- > > or even layer 2, where the municipality suppli > es > (matching) ONTs, and > > services have to fit over GigE -- fiber delivery of high-speed data > > service. > > > > I believe Google agrees with me. :-) > > > > Cheers, > > -- jra > > > > Cheers, > > -- jra > > -- > > Jay R. Ashworth Baylink jra at baylink.com > > Designer The Things I Think RFC 2100 > > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > > > > > > ------------------------------ Message: 5 Date: Tue, 27 Mar 2012 08:19:46 -0700 From: Owen DeLong To: Leo Bicknell Cc: nanog at nanog.org Subject: Re: Muni Fiber Message-ID: <72636209-A7EF-4AB8-A145-55D6B3A06EAD at delong.com> Content-Type: text/plain; charset=us-ascii > > Politically the makings of a similar situation already exist. > Goverment has swung the USF funds to fuel rual broadband, strongly > favoring FTTx where it makes sense. While companies like Verizon > enjoy not having to share their fiber lines now, these same forces > will conspire to drive unbundling in fiber, just as it did in copper. > What they are getting now is simply a first mover advantage. > It's a bigger first mover advantage. They've learned their lesson from the copper unbundling and they are being allowed to deploy fiber in ways that will make it hard (impossible) to sell it on an unbundled basis later. > Government at the end of the day will fund the 20-40% of America > which is profitable in the long run, but not in commercial time > scales. They will also fund the 10% of America which will never > be profitable, no mater what. It happened with Electricity and > Telephone, and I suspect the societal drivers to do the same with > the Internet will be even stronger. Companies will have to accept an > unbundled tail to get access to this 30-50% of the market; and while > they aren't interested now, they will be very soon. Maybe, but, if what is happening now is allowed to continue, it will: 1. Not encourage competition anywhere. 2. Allow existing monopolies to preserve and extend those monopolies. 3. Cost even more than it already has. 4. Continue to lag behind the rest of the world. 5. Result in an inferior solution. What is needed is for regulators to step up with a bold vision for the public good. We need to encourage (or even require) local authorities to deploy (themselves or by contract) independent L1 infrastructure (yes, I like the 4-8 strands per residence star topology idea) to every structure within their jurisdiction and make it available to L2+ service providers on an equal-cost-per-subscriber basis in each jurisdiction. Yes, this means that the cost per subscriber will be lower in denser jurisdictions than it will be in less dense jurisdictions. However, users in those jurisdictions should expect to pay more for services and the ability to attract L2+ service providers can be achieved in a variety of ways. The important thing is to make sure that if public money is being used to build infrastructure, it becomes infrastructure that is useful to said public and not just a subsidy to some corporation for extending its monopoly in a manner that is often contrary to the public good. Unfortunately, that is exactly where the money is going today. Owen End of NANOG Digest, Vol 50, Issue 113 ************************************** This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From jared at puck.nether.net Tue Mar 27 11:47:10 2012 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 27 Mar 2012 12:47:10 -0400 Subject: Muni Fiber In-Reply-To: <4F71C891.6020102@meetinghouse.net> References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> <4F71C891.6020102@meetinghouse.net> Message-ID: On Mar 27, 2012, at 10:02 AM, Miles Fidelman wrote: >> 2015 - First communities coming online, 100M to the home (probably Gigabit >> line rate, but throttled). > In most cases I've seen, the 100m fiber hardware is more expensive than the 1G, or the same price. The challenge here is getting the fiber there. One can use an inexpensive media converter that takes a SFP for $20-25 (RJ45 <-> SFP). Two and bi-di optics run around $220 (10km). Further distance (20/40/80km optics) increase the cost some, but not significantly. Some CPE hardware can be had for as low as sub-$200 (indoor unit). You may spend more for the pedestal than the hardware on the end. I would like to see part of any road reconstruction projects the requirement to install conduit or other fiber optic cabling. This would cause most areas to organically receive this upgrade along the way. I'm not actually opposed to the current incumbent having access to it or realizing the lower cost in conjunction with another project. What I do take issue with is winter time construction of cabling that is not fiber, even if part of service restoration. Extending the reach at that time can only provide value long-term. I'm not seeing the incumbents making those decisions. - Jared From bicknell at ufp.org Tue Mar 27 11:54:57 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 27 Mar 2012 09:54:57 -0700 Subject: Muni Fiber In-Reply-To: References: <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> <4F71C891.6020102@meetinghouse.net> Message-ID: <20120327165457.GA93376@ussenterprise.ufp.org> In a message written on Tue, Mar 27, 2012 at 12:47:10PM -0400, Jared Mauch wrote: > I would like to see part of any road reconstruction projects the requirement to install conduit or other fiber optic cabling. This would cause most areas to organically receive this upgrade along the way. I'm not actually opposed to the current incumbent having access to it or realizing the lower cost in conjunction with another project. What I do take issue with is winter time construction of cabling that is not fiber, even if part of service restoration. Extending the reach at that time can only provide value long-term. I'm not seeing the incumbents making those decisions. I could get behind road construction, at least in urban/surburan areas. For rural I think pole attachment is likely better all around. That said, what I'm more baffled about is that FTTH is not standard in greenfield housing developments. Even in FIOS territory many developers install copper (as the developer installs it, not Verizon). I've seen at least one story of Verizon retrofitting with FIOS a neighborhood that hasn't been finished yet, and ripping out copper that was never used in the first place! Updating building codes and requirements is a slow process, so now is the time to start. FTTH when digging for water, power, gas lines, cable, and phone is dirt cheap. -- 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 a.harrowell at gmail.com Tue Mar 27 11:55:54 2012 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Tue, 27 Mar 2012 17:55:54 +0100 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> Message-ID: On Tue, Mar 27, 2012 at 1:45 AM, William Herrin wrote: > On Mon, Mar 26, 2012 at 8:04 PM, Jacob Broussard > wrote: > > Who knows what technology will be like in 5-10 years? That's the whole > > point of what he was trying to say. Maybe wireless carriers will use > > visible wavelength lasers to recievers on top of customer's houses for > all > > we know. 10 years is a LONG time for tech, and anything can happen. > > Regarding lasers. I agree that modulating a laser beam to carry information is a great idea. Perhaps, though, we could direct the beam down some sort of optical pipe or waveguide to spare ourselves the refractive losses and keep the pigeons and rain and whatnot out of the Fresnel zone. We might call it an "optical wire" or "optical fibre" or something. no, it'll never catch on... Hi Jacob, > > The scientists doing the basic research now know. It's referred to as > the "technology pipeline." When someone says, "that's in the pipeline" > they mean that the basic science has been discovered to make something > possible and now engineers are in the process of figuring out how to > make it _viable_. The pipeline tends to be 5 to 10 years long, so > basic science researchers are making the discoveries *now* which will > be reflected in deployed technologies 10 years from now. > I recall an Agilent Technologies presentation from a couple of years back that demonstrated that historically, the great majority of incremental capacity on cellular networks was accounted for by cell subdivision. Better air interfaces help, more spectrum helps, but as the maximum system throughput is roughly defined by (spectral efficiency * spectrum)* number of cells (assuming an even traffic distribution and no intercell interference or re-use overhead, for the sake of a finger exercise), nothing beats more cells. As a result, the Wireless Pony will only save you if you can find a 10GigE Backhaul Pony to service the extra cells. After a certain degree of density, you'd need almost as much fibre (and more to the point, trench mileage) to service a couple of small cells per street as you would to *pass the houses in the street with fibre*. One of the great things FTTH gets you is a really awesome backhaul network for us cell heads. One of the reasons we were able to roll out 3G in the first place was that DSL got deployed and you could provision on two or a dozen DSL lines for a cell site. You can't have wireless without backhaul (barring implausible discoveries in fundamental mesh network theory). Most wireless capacity comes from cell subdivision. Subdivision demands more backhaul. > There is *nothing* promising in the pipeline for wireless tech that > has any real chance of leading to a wide scale replacement for fiber > optic cable. *Nothing.* Which means that in 10 years, wireless will be > better, faster and cheaper but it won't have made significant inroads > replacing fiber to the home and business. > > 20 years is a long time. 10 years, not so much. Even for the long > times, we can find the future by examining the past. The duration of > use of the predecessor technology (twisted pair) was about 50 years > ubiquitously deployed to homes. From that we can make an educated > guess about the current one (fiber). Fiber to the home started about > 10 years ago leaving about 40 more before something better might > replace it. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From bill at herrin.us Tue Mar 27 13:47:55 2012 From: bill at herrin.us (William Herrin) Date: Tue, 27 Mar 2012 14:47:55 -0400 Subject: Muni Fiber In-Reply-To: <20120327165457.GA93376@ussenterprise.ufp.org> References: <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> <4F71C891.6020102@meetinghouse.net> <20120327165457.GA93376@ussenterprise.ufp.org> Message-ID: On Tue, Mar 27, 2012 at 12:54 PM, Leo Bicknell wrote: > That said, what I'm more baffled about is that FTTH is not standard > in greenfield housing developments. ?Even in FIOS territory many > developers install copper (as the developer installs it, not Verizon). > I've seen at least one story of Verizon retrofitting with FIOS a > neighborhood that hasn't been finished yet, and ripping out copper > that was never used in the first place! Hi Leo, You don't need $20,000 worth of equipment per installer to install twisted pair cable, nor special training nor sophisticated and time consuming testing and validation. That's a pretty good reason not to install fiber in greenfield construction. If you were clever, you'd install microduct during greenfield construction from each residence to a community telecom hut. That's about as easy to do as installing twisted pair. Then the communications provider blows in fiber strands at need, a cheap and fast process compared to trenching cable. For those not in the know, microduct is a bundle of flexible airtight plastic tubes, each a few millimeters in diameter. Once installed through all its twists and turns, you blow compressed air down the tube and "jet" a bundle of 1 to 12 fibers from one end to the other. Decades later, remove obsolete fiber the same way and jet new. Unfortunately, few general contractors even know that microduct exists and to the best of my knowledge there are no standard termination kits for establishing a residential microduct network. Maybe that's a product idea for when construction picks back up. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Brent.Roberts at progressive-solutions.com Tue Mar 27 16:21:51 2012 From: Brent.Roberts at progressive-solutions.com (Roberts, Brent) Date: Tue, 27 Mar 2012 21:21:51 +0000 Subject: FW: Force10 E Series at the edge? In-Reply-To: <011a01cd0c5f$737a1720$5a6e4560$@wirezsound.com> References: <011a01cd0c5f$737a1720$5a6e4560$@wirezsound.com> Message-ID: <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp> Is anyone running an E300 Series Chassis at the internet edge with multiple Full BGP feeds? 95th percent would be about 300 meg of traffic. BGP session count would be between 2 and 4 Peers. 6k internal Prefix count as it stands right now. Alternative are welcome. Thought about the ASR1006 but I need some local switching as well. Full requirements include Full internet Peering over GigE Links. Fully Redundant Power Redundant "Supervisor/Route Processor" Would prefer a Small Chassis unit. (under 10u) Would also prefer a single unit as opposed to a two smaller units. ________________________________ This email and any attached files may contain confidential and/or privileged material and is intended solely for the use of the person to whom it is addressed. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete it and all attachments from your computer. Progressive Solutions is not liable for any errors or omissions in the content or transmission of this email. From james at freedomnet.co.nz Tue Mar 27 16:32:20 2012 From: james at freedomnet.co.nz (james jones) Date: Tue, 27 Mar 2012 17:32:20 -0400 Subject: FW: Force10 E Series at the edge? In-Reply-To: <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp> References: <011a01cd0c5f$737a1720$5a6e4560$@wirezsound.com> <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp> Message-ID: Have you look at Juniper's MX stuff. On Tue, Mar 27, 2012 at 5:21 PM, Roberts, Brent < Brent.Roberts at progressive-solutions.com> wrote: > Is anyone running an E300 Series Chassis at the internet edge with > multiple Full BGP feeds? 95th percent would be about 300 meg of traffic. > BGP session count would be between 2 and 4 Peers. > 6k internal Prefix count as it stands right now. Alternative are welcome. > Thought about the ASR1006 but I need some local switching as well. > > Full requirements include > Full internet Peering over GigE Links. > Fully Redundant Power > Redundant "Supervisor/Route Processor" > Would prefer a Small Chassis unit. (under 10u) > Would also prefer a single unit as opposed to a two smaller units. > > > ________________________________ > > This email and any attached files may contain confidential and/or > privileged material and is intended solely for the use of the person to > whom it is addressed. Any review, retransmission, dissemination or other > use of or taking of any action in reliance upon this information by persons > or entities other than the intended recipient is prohibited. If you > received this in error, please contact the sender immediately and delete it > and all attachments from your computer. Progressive Solutions is not liable > for any errors or omissions in the content or transmission of this email. > From jrhett at netconsonance.com Tue Mar 27 17:00:22 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 27 Mar 2012 15:00:22 -0700 Subject: Force10 E Series at the edge? In-Reply-To: <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp> References: <011a01cd0c5f$737a1720$5a6e4560$@wirezsound.com> <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp> Message-ID: <3A27C8B5-FA98-49EF-B896-371616C12F77@netconsonance.com> I was very happy with the E300 as a data center core switch handling multiple full feeds (around 15) with about 10x the traffic you are talking about. The only problem I had was that Force10 didn't have a useful (basically forklift) upgrade to get more IPv4 prefixes, and the more I talked to them and the more I showed them the graphs demonstrating what we'd need for prefix space assuming even the most conservative assumptions at depletion, the more I realized they really Did Not Get It. In fact, their brand new architecture recently announced had only 500k prefixes allowed, at a time that the Juniper MX platform handled 2million easily. So I would be fine using Force10 again, given the following changes: 1. Large limits on IP prefixes allowed 2. Reallocation of useless memory from stupid things like MAC tables to prefixes (data centers have very few MACs, very many prefixes) 3. Command line logging The units worked great at failover, never had any problems gracefully failing over from one RP to another, but if you have to cold boot them for any reason it takes like 5 minutes :( On Mar 27, 2012, at 2:21 PM, Roberts, Brent wrote: > Is anyone running an E300 Series Chassis at the internet edge with multiple Full BGP feeds? 95th percent would be about 300 meg of traffic. BGP session count would be between 2 and 4 Peers. > 6k internal Prefix count as it stands right now. Alternative are welcome. Thought about the ASR1006 but I need some local switching as well. > > Full requirements include > Full internet Peering over GigE Links. > Fully Redundant Power > Redundant "Supervisor/Route Processor" > Would prefer a Small Chassis unit. (under 10u) > Would also prefer a single unit as opposed to a two smaller units. > > > ________________________________ > > This email and any attached files may contain confidential and/or privileged material and is intended solely for the use of the person to whom it is addressed. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete it and all attachments from your computer. Progressive Solutions is not liable for any errors or omissions in the content or transmission of this email. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From leo.vegoda at icann.org Fri Mar 23 12:27:04 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 23 Mar 2012 10:27:04 -0700 Subject: Three blocks of AS Numbers allocated to the RIPE NCC Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34184ABD4B60C5@EXVPMBX100-1.exc.icann.org> Hi, The IANA AS Numbers registry has been updated to reflect the allocation of three blocks to the RIPE NCC in March 2012. 59392-60415 Assigned by RIPE NCC 2011-03-21 60416-61439 Assigned by RIPE NCC 2011-03-21 198656-199679 Assigned by RIPE NCC 2011-03-21 You can find the registry at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.txt Regards, Leo Vegoda ICANN From tom at dyn.com Tue Mar 27 22:59:11 2012 From: tom at dyn.com (Tom Daly) Date: Tue, 27 Mar 2012 23:59:11 -0400 (EDT) Subject: Force10 E Series at the edge? In-Reply-To: <3A27C8B5-FA98-49EF-B896-371616C12F77@netconsonance.com> Message-ID: <1294080510.1249622.1332907151003.JavaMail.root@zmail-01.mht.dyndns.com> Brent, Your options include, for smaller boxes: - Brocade CER series, but make sure you the -RT versions due to RAM (haven't tried, though) - Juniper MX (MX80 is working well for us) - Cisco ASR1006 (heard a lot about BGP price issues) But for 300mb/sec, what not OpenBSD + Quagga? Tom ----- Original Message ----- > I was very happy with the E300 as a data center core switch handling > multiple full feeds (around 15) with about 10x the traffic you are > talking about. The only problem I had was that Force10 didn't have > a useful (basically forklift) upgrade to get more IPv4 prefixes, and > the more I talked to them and the more I showed them the graphs > demonstrating what we'd need for prefix space assuming even the most > conservative assumptions at depletion, the more I realized they > really Did Not Get It. In fact, their brand new architecture > recently announced had only 500k prefixes allowed, at a time that > the Juniper MX platform handled 2million easily. > > So I would be fine using Force10 again, given the following changes: > 1. Large limits on IP prefixes allowed > 2. Reallocation of useless memory from stupid things like MAC tables > to prefixes (data centers have very few MACs, very many prefixes) > 3. Command line logging > > The units worked great at failover, never had any problems gracefully > failing over from one RP to another, but if you have to cold boot > them for any reason it takes like 5 minutes :( > > On Mar 27, 2012, at 2:21 PM, Roberts, Brent wrote: > > Is anyone running an E300 Series Chassis at the internet edge with > > multiple Full BGP feeds? 95th percent would be about 300 meg of > > traffic. BGP session count would be between 2 and 4 Peers. > > 6k internal Prefix count as it stands right now. Alternative are > > welcome. Thought about the ASR1006 but I need some local switching > > as well. > > > > Full requirements include > > Full internet Peering over GigE Links. > > Fully Redundant Power > > Redundant "Supervisor/Route Processor" > > Would prefer a Small Chassis unit. (under 10u) > > Would also prefer a single unit as opposed to a two smaller units. > > > > > > ________________________________ > > > > This email and any attached files may contain confidential and/or > > privileged material and is intended solely for the use of the > > person to whom it is addressed. Any review, retransmission, > > dissemination or other use of or taking of any action in reliance > > upon this information by persons or entities other than the > > intended recipient is prohibited. If you received this in error, > > please contact the sender immediately and delete it and all > > attachments from your computer. Progressive Solutions is not > > liable for any errors or omissions in the content or transmission > > of this email. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > From randy_94108 at yahoo.com Tue Mar 27 23:34:04 2012 From: randy_94108 at yahoo.com (Randy) Date: Tue, 27 Mar 2012 21:34:04 -0700 (PDT) Subject: Force10 E Series at the edge? In-Reply-To: <1294080510.1249622.1332907151003.JavaMail.root@zmail-01.mht.dyndns.com> Message-ID: <1332909245.18195.YahooMailClassic@web181118.mail.ne1.yahoo.com> --- On Tue, 3/27/12, Tom Daly wrote: > From: Tom Daly > Subject: Re: Force10 E Series at the edge? > To: "Brent Roberts" > Cc: "NANOG" > Date: Tuesday, March 27, 2012, 8:59 PM > Brent, > Your options include, for smaller boxes: > > - Brocade CER series, but make sure you the -RT versions due > to RAM (haven't tried, though) > - Juniper MX (MX80 is working well for us) > - Cisco ASR1006 (heard a lot about BGP price issues) > > But for 300mb/sec, what not OpenBSD + Quagga? > > Tom > > > > ----- Original Message ----- > > I was very happy with the E300 as a data center core > switch handling > > multiple full feeds (around 15) with about 10x the > traffic you are > > talking about.? The only problem I had was that > Force10 didn't have > > a useful (basically forklift) upgrade to get more IPv4 > prefixes, and > > the more I talked to them and the more I showed them > the graphs > > demonstrating what we'd need for prefix space assuming > even the most > > conservative assumptions at depletion, the more I > realized they > > really Did Not Get It.? In fact, their brand new > architecture > > recently announced had only 500k prefixes allowed, at a > time that > > the Juniper MX platform handled 2million easily. > > > > So I would be fine using Force10 again, given the > following changes: > > ??? 1. Large limits on IP prefixes > allowed > > ??? 2. Reallocation of useless memory > from stupid things like MAC tables > > ??? to prefixes (data centers have very > few MACs, very many prefixes) > > ??? 3. Command line logging > > > > The units worked great at failover, never had any > problems gracefully > > failing over from one RP to another, but if you have to > cold boot > > them for any reason it takes like 5 minutes :( > > > > On Mar 27, 2012, at 2:21 PM, Roberts, Brent wrote: > > > Is anyone running an E300 Series Chassis at the > internet edge with > > > multiple Full BGP feeds? 95th percent would be > about 300 meg of > > > traffic. BGP session count would be between 2 and > 4 Peers. > > > 6k internal Prefix count as it stands right now. > Alternative are > > > welcome. Thought about the ASR1006 but I need some > local switching > > > as well. > > > > > > Full requirements include > > > Full internet Peering over GigE Links. > > > Fully Redundant Power > > > Redundant "Supervisor/Route Processor" > > > Would prefer a Small Chassis unit. (under 10u) > > > Would also prefer a single unit as opposed to a > two smaller units. > > > I can't speak for forece10 which is DELL now. As Joe mentioned, the biggest problem is "their-support" of 680k prefixes with the QUAD-CAM linecards. DUAL-CAM line cards do 512K in theory. Regular ones don't work because thay support 320K prefifex and "die" around 300K They have other idiotic-implementations(when to set/NOT set ospf forwarding-address) buggy vrrp implemtation but I am told "it will be fixed in the next release of FTOS. So, NO! the 300i, 600 or 120 are good a good fit as edge/core layer devices. On a sepatare note.....their S50 switches; I have found to be "great" as long as your l2 environment doesn't require Rapid-PVST. They do PVST but 802.1W is a single instance. ./Randy From frnkblk at iname.com Tue Mar 27 23:45:26 2012 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 27 Mar 2012 23:45:26 -0500 Subject: Muni Fiber In-Reply-To: <12434755.8395.1332791927186.JavaMail.root@benjamin.baylink.com> References: <12434755.8395.1332791927186.JavaMail.root@benjamin.baylink.com> Message-ID: <034201cd0c9d$980733a0$c8159ae0$@iname.com> I don't think a muni can prevent the ILEC from installing fiber in their RoW.... Frank -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Monday, March 26, 2012 2:59 PM To: NANOG Subject: Re: Muni Fiber ----- Original Message ----- > From: "Ray Soucy" > On Mon, Mar 26, 2012 at 3:46 PM, Jay Ashworth wrote: > > > It'll never be done though. Too much to lose by creating a > > > topology which allows you to unbundle the tail. > > > > A municipality hasn't much to lose; they can declare a monopoly. > > > > Which was rather precisely the point. > True, but it's the one monopoly where you get a vote. > I'm not sure it's fair to call a municipality a monopoly ... but > that's just me. I wasn't clear (again; I have to work harder on that -- it made sense to *me* :-)... A municipality can declare a monopoly on the installation of fiber within its jurisdictional bounds, and *require* anyone who wants to connect its residents to use its fiber; it *owns* (or has easements on) all the spaces necessary to do subterranean fiber (and I believe it leases such easements to power utilities to erect their poles, and may therefore have control over that as well, though I'd have to research that point. Clearly, I think that's a feature, not a but (if you've been following the thread)... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From cgucker at onesc.net Wed Mar 28 00:06:51 2012 From: cgucker at onesc.net (Charles Gucker) Date: Wed, 28 Mar 2012 01:06:51 -0400 Subject: Muni Fiber In-Reply-To: <034201cd0c9d$980733a0$c8159ae0$@iname.com> References: <12434755.8395.1332791927186.JavaMail.root@benjamin.baylink.com> <034201cd0c9d$980733a0$c8159ae0$@iname.com> Message-ID: On Wed, Mar 28, 2012 at 12:45 AM, Frank Bulk wrote: > I don't think a muni can prevent the ILEC from installing fiber in their RoW.... First off, IANAL, Secondly, I've had a reasonable amount of experience with Village and Municipal Law. In short, the statement above is incorrect, in so much that the RoW is not that of the ILEC, but rather the ILEC's ability to use the Muni's RoW. So, if the Municipality wanted to prevent the ILEC, or any company with RoW use rights, they certainly can. Unfortunately, a lot of the terms of the arrangement between the Municipalities and Telco's were written back in the 20's and 30's. So, the "restriction" would have to be put into terms of that agreement. But in the end, it's up to the Municipality to set the guidelines (as with any local law) within the borders of their Municipality. charles From me at anuragbhatia.com Wed Mar 28 03:45:16 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 28 Mar 2012 14:15:16 +0530 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> Message-ID: Hi Nice discussion. Just a small question here - how much backhaul at present 2G, 3G and LTE based towers have? Just curious to hear an average number. I agree it would be a significant difference from busy street in New York to less crowded area say in Michigan but what sort of bandwidth telcos provision per tower? On fiber - I can imagine virtually unlimited bandwidth with incremental cost of optical instruments but how much to wireless backhaul based sites? Do they put Gigabit microwave everywhere? If not then say 100Mbps? If so then how end users on Verizon LTE people individual users get 10Mbps and so on? Is that operated at high contention? Thanks! (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Mar 27, 2012 10:26 PM, "Alexander Harrowell" wrote: > On Tue, Mar 27, 2012 at 1:45 AM, William Herrin wrote: > > > On Mon, Mar 26, 2012 at 8:04 PM, Jacob Broussard > > wrote: > > > Who knows what technology will be like in 5-10 years? That's the whole > > > point of what he was trying to say. Maybe wireless carriers will use > > > visible wavelength lasers to recievers on top of customer's houses for > > all > > > we know. 10 years is a LONG time for tech, and anything can happen. > > > > > Regarding lasers. I agree that modulating a laser beam to carry information > is a great idea. Perhaps, though, we could direct the beam down some sort > of optical pipe or waveguide to spare ourselves the refractive losses and > keep the pigeons and rain and whatnot out of the Fresnel zone. We might > call it an "optical wire" or "optical fibre" or something. no, it'll never > catch on... > > Hi Jacob, > > > > The scientists doing the basic research now know. It's referred to as > > the "technology pipeline." When someone says, "that's in the pipeline" > > they mean that the basic science has been discovered to make something > > possible and now engineers are in the process of figuring out how to > > make it _viable_. The pipeline tends to be 5 to 10 years long, so > > basic science researchers are making the discoveries *now* which will > > be reflected in deployed technologies 10 years from now. > > > > > I recall an Agilent Technologies presentation from a couple of years back > that demonstrated that historically, the great majority of incremental > capacity on cellular networks was accounted for by cell subdivision. Better > air interfaces help, more spectrum helps, but as the maximum system > throughput is roughly defined by (spectral efficiency * spectrum)* number > of cells (assuming an even traffic distribution and no intercell > interference or re-use overhead, for the sake of a finger exercise), > nothing beats more cells. > > > As a result, the Wireless Pony will only save you if you can find a 10GigE > Backhaul Pony to service the extra cells. After a certain degree of > density, you'd need almost as much fibre (and more to the point, trench > mileage) to service a couple of small cells per street as you would to > *pass the houses in the street with fibre*. > > > One of the great things FTTH gets you is a really awesome backhaul network > for us cell heads. One of the reasons we were able to roll out 3G in the > first place was that DSL got deployed and you could provision on two or a > dozen DSL lines for a cell site. > > > You can't have wireless without backhaul (barring implausible discoveries > in fundamental mesh network theory). Most wireless capacity comes from cell > subdivision. Subdivision demands more backhaul. > > > > There is *nothing* promising in the pipeline for wireless tech that > > has any real chance of leading to a wide scale replacement for fiber > > optic cable. *Nothing.* Which means that in 10 years, wireless will be > > better, faster and cheaper but it won't have made significant inroads > > replacing fiber to the home and business. > > > > 20 years is a long time. 10 years, not so much. Even for the long > > times, we can find the future by examining the past. The duration of > > use of the predecessor technology (twisted pair) was about 50 years > > ubiquitously deployed to homes. From that we can make an educated > > guess about the current one (fiber). Fiber to the home started about > > 10 years ago leaving about 40 more before something better might > > replace it. > > > > Regards, > > Bill Herrin > > > > > > > > -- > > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > > 3005 Crane Dr. ...................... Web: > > Falls Church, VA 22042-3004 > > > > > From fkittred at gwi.net Wed Mar 28 06:56:08 2012 From: fkittred at gwi.net (Fletcher Kittredge) Date: Wed, 28 Mar 2012 07:56:08 -0400 Subject: Muni Fiber In-Reply-To: References: <12434755.8395.1332791927186.JavaMail.root@benjamin.baylink.com> <034201cd0c9d$980733a0$c8159ae0$@iname.com> Message-ID: Charles; Wouldn't Federal and State laws preempt Municipal law in this area? I agree YANAL. regards, Fletcher On Wed, Mar 28, 2012 at 1:06 AM, Charles Gucker wrote: > On Wed, Mar 28, 2012 at 12:45 AM, Frank Bulk wrote: > > I don't think a muni can prevent the ILEC from installing fiber in their > RoW.... > > First off, IANAL, Secondly, I've had a reasonable amount of experience > with Village and Municipal Law. In short, the statement above is > incorrect, in so much that the RoW is not that of the ILEC, but rather > the ILEC's ability to use the Muni's RoW. So, if the Municipality > wanted to prevent the ILEC, or any company with RoW use rights, they > certainly can. Unfortunately, a lot of the terms of the > arrangement between the Municipalities and Telco's were written back > in the 20's and 30's. So, the "restriction" would have to be put > into terms of that agreement. > > But in the end, it's up to the Municipality to set the guidelines (as > with any local law) within the borders of their Municipality. > > charles > > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From carlosm3011 at gmail.com Wed Mar 28 07:17:37 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 28 Mar 2012 09:17:37 -0300 Subject: RPKI support from router verndors Message-ID: <4F730161.1030608@gmail.com> Hello all, I was wondering when can we actually expect RPKI / origin validation support from router vendors. I know where Cisco and Juniper stand, in fact, I have been testing both implementations. So, I would like to know if some one has heard anything from: - Huawei - Alcatel - Others ? regards Carlos From mfidelman at meetinghouse.net Wed Mar 28 08:25:04 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 28 Mar 2012 09:25:04 -0400 Subject: Muni Fiber In-Reply-To: References: <12434755.8395.1332791927186.JavaMail.root@benjamin.baylink.com> <034201cd0c9d$980733a0$c8159ae0$@iname.com> Message-ID: <4F731130.3080300@meetinghouse.net> Charles Gucker wrote: > On Wed, Mar 28, 2012 at 12:45 AM, Frank Bulk wrote: >> I don't think a muni can prevent the ILEC from installing fiber in their RoW.... > First off, IANAL, Secondly, I've had a reasonable amount of experience > with Village and Municipal Law. In short, the statement above is > incorrect, in so much that the RoW is not that of the ILEC, but rather > the ILEC's ability to use the Muni's RoW. So, if the Municipality > wanted to prevent the ILEC, or any company with RoW use rights, they > certainly can. Unfortunately, a lot of the terms of the > arrangement between the Municipalities and Telco's were written back > in the 20's and 30's. So, the "restriction" would have to be put > into terms of that agreement. > > But in the end, it's up to the Municipality to set the guidelines (as > with any local law) within the borders of their Municipality. (Talking US only...) Guess you weren't around when the Telecom Act hit... "you mean anybody who wants to can dig up our streets to lay cable???!!!!" And today's cable franchising exercises have become almost a joke - given the restrictions implied by Federal and State laws. Re. terms that were "written in the 20s and 30s"... where it gets really interesting are places like Texas, where there are perpetual ROW grants that predate statehood, and can not be rewritten or renegotiated. Also some interesting legacies from ROW grants associated with building the transcontinental railroads (e.g., the City of Abilene, TX has to pay the Southern Pacific Railroad, or its successor, to run fiber along underpasses where their tracks bisect the City). -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bill at herrin.us Wed Mar 28 09:15:33 2012 From: bill at herrin.us (William Herrin) Date: Wed, 28 Mar 2012 10:15:33 -0400 Subject: Muni Fiber In-Reply-To: References: <12434755.8395.1332791927186.JavaMail.root@benjamin.baylink.com> <034201cd0c9d$980733a0$c8159ae0$@iname.com> Message-ID: On Wed, Mar 28, 2012 at 7:56 AM, Fletcher Kittredge wrote: > Wouldn't Federal and State laws preempt Municipal law in this area? Hi Fletcher, State laws yes. State legislatures tend to narrowly define what laws a municipality is allowed to independently enact. And they tend to be very open to the proposition that standards for utility construction should be uniform across the state. Federal, maybe. The FCC has overstepped its authority and been overruled by the courts many times. And municipal laws can be carefully enough constructed that preemption would unambiguously exceed federal authority. Even if preempted, a state or municipality can make it make it *very* uncomfortable for a communications provider who doesn't want to play ball. Consider, for example, DC's repaving requirements: if you dig up the street, you're required to repave the whole street all the way from the nearest intersections. Completely repave, not just cold-patch. That's pretty expensive. Unless they waive the requirement on a case by case basis. Where the basis has a habit of being whether or not your digging is in line with a government policy objective. This is one reason FIOS deployments lag in DC. Verizon doesn't want to deploy conduit down every street lest they be compelled to open it to competitors and the DC government won't waive the repaving requirements for direct burial fiber. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mfidelman at meetinghouse.net Wed Mar 28 09:36:42 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 28 Mar 2012 10:36:42 -0400 Subject: Muni Fiber In-Reply-To: References: <12434755.8395.1332791927186.JavaMail.root@benjamin.baylink.com> <034201cd0c9d$980733a0$c8159ae0$@iname.com> Message-ID: <4F7321FA.6080903@meetinghouse.net> William Herrin wrote: >> >> Even if preempted, a state or municipality can make it make it *very* >> uncomfortable for a communications provider who doesn't want to play >> ball. Consider, for example, DC's repaving requirements: if you dig up >> the street, you're required to repave the whole street all the way >> from the nearest intersections. Completely repave, not just >> cold-patch. That's pretty expensive. Unless they waive the requirement >> on a case by case basis. Where the basis has a habit of being whether >> or not your digging is in line with a government policy objective. >> >> This is one reason FIOS deployments lag in DC. Verizon doesn't want to >> deploy conduit down every street lest they be compelled to open it to >> competitors and the DC government won't waive the repaving >> requirements for direct burial fiber. Flip side of this - a street cut, on average, take a year off the life of a street. Street patches tend to lead to potholes, ice dams, and so forth (and from there to lots of car repairs). Doing things in the street disrupts traffic - you don't want it to happen too often. (Things you learn consulting to local governments.) It's not a matter of "making things uncomfortable for communications providers" - it's a matter of getting them to pay the full cost of digging, rather than passing it off to others. It's been my observation that MOST municipalities let providers do whatever they want, don't do anything to coordinate right-of-way work (even by their own water departments), don't have the budget to repair or repave roads all that often, and hence have absolutely horrid roads - particularly in areas where water infiltration and freezing is an issue. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From bjornliu at gmail.com Wed Mar 28 09:44:47 2012 From: bjornliu at gmail.com (Bingyang LIU) Date: Wed, 28 Mar 2012 16:44:47 +0200 Subject: BCP38 Deployment Message-ID: Hi all, I'm Bingyang Liu, a ph.d student in Tsinghua University. My thesis topic is on "source address validation". Although BCP38 was proposed more than ten years ago, IP spoofing still remains an attack vector [MIT-Spoofer] [ARBOR-Annual-Report] [Presentation on NANOG Meeting] [Discussion in NANOG ML]. I did a lot investigation, but still have no idea why so many ISPs haven't deploy BCP38. I enumerate three reasons I found, and I'd like your comments very much. 1. Stub ASes: They rely on their providers to filter, so they won't deploy BCP38 on their own. 2. Low tier transit ASes: They are most likely to deploy BCP38 on the interfaces towards their customers. 3. Large or tier1 ASes: Their peers and customers are also large. So uRPF may have false positive and ACLs are too large to manage. I also asked some ISP guys in IETF today, they all agreed that IP spoofing is an issue, but they may haven't deployed it. One key issue, I think, is about incentive. i.e. you can filter, but you'll still receive spoofing from providers and peers who haven't enforced BCP38. best Bingyang -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby From patrick at ianai.net Wed Mar 28 10:00:39 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 28 Mar 2012 11:00:39 -0400 Subject: BCP38 Deployment In-Reply-To: References: Message-ID: On Mar 28, 2012, at 10:44 , Bingyang LIU wrote: > I'm Bingyang Liu, a ph.d student in Tsinghua University. My thesis topic is > on "source address validation". > > Although BCP38 was proposed more than ten years ago, IP spoofing still > remains an attack vector [MIT-Spoofer] [ARBOR-Annual-Report] [Presentation > on NANOG Meeting] [Discussion in NANOG ML]. > > I did a lot investigation, but still have no idea why so many ISPs haven't > deploy BCP38. I enumerate three reasons I found, and I'd like your comments > very much. > > 1. Stub ASes: They rely on their providers to filter, so they won't deploy > BCP38 on their own. > 2. Low tier transit ASes: They are most likely to deploy BCP38 on the > interfaces towards their customers. > 3. Large or tier1 ASes: Their peers and customers are also large. So uRPF > may have false positive and ACLs are too large to manage. > > I also asked some ISP guys in IETF today, they all agreed that IP spoofing > is an issue, but they may haven't deployed it. One key issue, I think, is > about incentive. i.e. you can filter, but you'll still receive spoofing > from providers and peers who haven't enforced BCP38. While those reasons are somewhat valid, they are not the main reasons. #1) Money. Whenever someone asks "why...?", the answer is usually "money". It costs money - CapEx if your equipment doesn't support RPF, and OpEx even if it does. Plus opportunity cost if your customers don't like it or you screw up, as those customers will find someone who doesn't filter and move. #2) Laziness. When the question is "why have [you|they] not...?", the second most common answer is laziness. Some call it "inertia", but reality is people are busy, lazy, etc. Please note the complete lack of smilies or other indication I am kidding or being sarcastic. There is also ignorance, stupidity, malice (yes, some people actually attack others or sell to those who do), etc. -- TTFN, patrick From owen at delong.com Wed Mar 28 10:06:03 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 28 Mar 2012 09:06:03 -0600 Subject: Force10 E Series at the edge? In-Reply-To: <1332909245.18195.YahooMailClassic@web181118.mail.ne1.yahoo.com> References: <1332909245.18195.YahooMailClassic@web181118.mail.ne1.yahoo.com> Message-ID: <33EE6163-2E72-4497-87C3-CFAFEABB3427@delong.com> > I can't speak for forece10 which is DELL now. > As Joe mentioned, the biggest problem is "their-support" of 680k prefixes with the QUAD-CAM linecards. DUAL-CAM line cards do 512K in theory. Regular ones don't work because thay support 320K prefifex and "die" around 300K > If memory serves, it's worse than that. Those numbers can only be achieved if you turn off IPv6 altogether IIRC. Owen From bicknell at ufp.org Wed Mar 28 10:13:35 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 28 Mar 2012 08:13:35 -0700 Subject: BCP38 Deployment In-Reply-To: References: Message-ID: <20120328151335.GA40955@ussenterprise.ufp.org> In a message written on Wed, Mar 28, 2012 at 11:00:39AM -0400, Patrick W. Gilmore wrote: > #1) Money. > Whenever someone asks "why...?", the answer is usually "money". It costs money - CapEx if your equipment doesn't support RPF, and OpEx even if it does. Plus opportunity cost if your customers don't like it or you screw up, as those customers will find someone who doesn't filter and move. > > #2) Laziness. > When the question is "why have [you|they] not...?", the second most common answer is laziness. Some call it "inertia", but reality is people are busy, lazy, etc. While Patrick is spot on, there is a third issue which is related to money and laziness, but also has some unique aspects. BCP38 makes the assumption that the ISP does some "configuration" to insure only properly sourced packets enter the network. That may have been true when BCP38 was written, but no longer accurately reflects how networks are built and operated. To get source address validation widely deployed it needs to be baked into consumer CPE. The requirement needs to be a "default on" in the DOCSYS specs, for instance. Residential gateways need to come from the factory with unicast RPF turned on. BCP38 needs to be applied at the OEM level in equipment maufacturing, not at the operational level with ISP's. There are, simply, too many variations in CPE devices to expect ISP's to _configure_ them. Even when the configuration is "standardized" (like DOCSYS) ISP's have to think really hard about the operational impact of turning on a feature; and one buggy implementationc can scuttle an idea network wide. Which really comes back to Patrick's point #2. If the people who care about this want to see a positive change they need to stop badgering ISP's to implement BCP38 and start badgering Linksys/Netgear/D-Link/Motorola/Apple/Touchstone/SMC/Westtel to make unicast RPF a default part of their gateway implementation. More importantly, they need to get them to brand it as a _feature_, protect your computer from being used by hackers, our router insures they won't use up all of your data cap! Then it will be something they can sell, and thus something they will implement. As long as folks keep beating on (consumer) ISPs to implement BCP38, nothing will happen. -- 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 jra at baylink.com Wed Mar 28 10:25:58 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 28 Mar 2012 11:25:58 -0400 (EDT) Subject: Muni Fiber In-Reply-To: <034201cd0c9d$980733a0$c8159ae0$@iname.com> Message-ID: <14105472.8761.1332948358405.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Frank Bulk" > I don't think a muni can prevent the ILEC from installing fiber in > their RoW.... "Their": pronoun without a referent. The municipality's right of way? I should think they would be able to; the property, or the easement, is theirs, not any utility's. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From mfidelman at meetinghouse.net Wed Mar 28 10:29:24 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 28 Mar 2012 11:29:24 -0400 Subject: Muni Fiber In-Reply-To: <14105472.8761.1332948358405.JavaMail.root@benjamin.baylink.com> References: <14105472.8761.1332948358405.JavaMail.root@benjamin.baylink.com> Message-ID: <4F732E54.2000008@meetinghouse.net> Jay Ashworth wrote: > ----- Original Message ----- >> From: "Frank Bulk" >> I don't think a muni can prevent the ILEC from installing fiber in >> their RoW.... > "Their": pronoun without a referent. The municipality's right of way? > > I should think they would be able to; the property, or the easement, is > theirs, not any utility's. > Think again. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From gbonser at seven.com Wed Mar 28 10:34:38 2012 From: gbonser at seven.com (George Bonser) Date: Wed, 28 Mar 2012 15:34:38 +0000 Subject: Force10 E Series at the edge? In-Reply-To: <1294080510.1249622.1332907151003.JavaMail.root@zmail-01.mht.dyndns.com> References: <3A27C8B5-FA98-49EF-B896-371616C12F77@netconsonance.com> <1294080510.1249622.1332907151003.JavaMail.root@zmail-01.mht.dyndns.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D73C5C@RWC-MBX1.corp.seven.com> > -----Original Message----- > From: Tom Daly > Sent: Tuesday, March 27, 2012 8:59 PM > To: Brent Roberts > Cc: NANOG > Subject: Re: Force10 E Series at the edge? > > Brent, > Your options include, for smaller boxes: > > - Brocade CER series, but make sure you the -RT versions due to RAM > (haven't tried, though) > - Juniper MX (MX80 is working well for us) > - Cisco ASR1006 (heard a lot about BGP price issues) > > But for 300mb/sec, what not OpenBSD + Quagga? > > Tom I have been using a pair of CER (but not the -RT) at one location for a while now and so far have been flawless. These particular units aren't taking full tables so don't need the -RT but I wouldn't have any trouble using them. The -RT are basically a 1U XMR. From drc at virtualized.org Wed Mar 28 10:45:12 2012 From: drc at virtualized.org (David Conrad) Date: Wed, 28 Mar 2012 08:45:12 -0700 Subject: BCP38 Deployment In-Reply-To: <20120328151335.GA40955@ussenterprise.ufp.org> References: <20120328151335.GA40955@ussenterprise.ufp.org> Message-ID: Leo, On Mar 28, 2012, at 8:13 AM, Leo Bicknell wrote: >> #1) Money. >> #2) Laziness. > While Patrick is spot on, there is a third issue which is related > to money and laziness, but also has some unique aspects. > > BCP38 makes the assumption that the ISP does some "configuration" > to insure only properly sourced packets enter the network. That > may have been true when BCP38 was written, but no longer accurately > reflects how networks are built and operated. An interesting assertion. I haven't looked at how end-user networks are built recently. I had assumed there continue to be customer aggregation points within ISP infrastructure in which BCP38-type filtering could occur. You're saying this is no longer the case? What has replaced it? > BCP38 needs > to be applied at the OEM level in equipment maufacturing, not at > the operational level with ISP's. I don't believe this is either/or. I agree that BCP38 features should be turned on by default in CPE, however I believe it really needs to be enforced at the ISP level. > As long as folks keep beating on (consumer) ISPs to implement BCP38, nothing will happen. Optimist. Actually, given the uptick in spoofing-based DoS attacks, the ease in which such attacks can be generated, recent high profile targets of said attacks, and the full-on money pumping freakout about anything with "cyber-" tacked on the front, I suspect a likely outcome will be proposals for legislation forcing ISPs to do something like BCP38. Regards, -drc From branto at networking-architecture.com Wed Mar 28 10:46:32 2012 From: branto at networking-architecture.com (Brant Ian Stevens) Date: Wed, 28 Mar 2012 11:46:32 -0400 Subject: Force10 E Series at the edge? In-Reply-To: <4F733142.1010109@argentiumsolutions.com> References: <3A27C8B5-FA98-49EF-B896-371616C12F77@netconsonance.com> <1294080510.1249622.1332907151003.JavaMail.root@zmail-01.mht.dyndns.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D73C5C@RWC-MBX1.corp.seven.com> <4F733142.1010109@argentiumsolutions.com> Message-ID: <4F733258.3010107@networking-architecture.com> > Brant Ian Stevens > March 28, 2012 11:41 AM > The CER is the perfect box for this application, save for the > redundant processors. The MLXe will work great if you want a small > form factor and redundant processors. > > -Brant > George Bonser > March 28, 2012 11:34 AM > > > I have been using a pair of CER (but not the -RT) at one location for > a while now and so far have been flawless. These particular units > aren't taking full tables so don't need the -RT but I wouldn't have > any trouble using them. The -RT are basically a 1U XMR. > > Tom Daly > March 27, 2012 11:59 PM > Brent, > Your options include, for smaller boxes: > > - Brocade CER series, but make sure you the -RT versions due to RAM > (haven't tried, though) > - Juniper MX (MX80 is working well for us) > - Cisco ASR1006 (heard a lot about BGP price issues) > > But for 300mb/sec, what not OpenBSD + Quagga? > > Tom > > > > ----- Original Message ----- > > Jo Rhett > March 27, 2012 6:00 PM > I was very happy with the E300 as a data center core switch handling > multiple full feeds (around 15) with about 10x the traffic you are > talking about. The only problem I had was that Force10 didn't have a > useful (basically forklift) upgrade to get more IPv4 prefixes, and the > more I talked to them and the more I showed them the graphs > demonstrating what we'd need for prefix space assuming even the most > conservative assumptions at depletion, the more I realized they really > Did Not Get It. In fact, their brand new architecture recently > announced had only 500k prefixes allowed, at a time that the Juniper > MX platform handled 2million easily. > > So I would be fine using Force10 again, given the following changes: > 1. Large limits on IP prefixes allowed > 2. Reallocation of useless memory from stupid things like MAC tables > to prefixes (data centers have very few MACs, very many prefixes) > 3. Command line logging > > The units worked great at failover, never had any problems gracefully > failing over from one RP to another, but if you have to cold boot them > for any reason it takes like 5 minutes :( > From bjornliu at gmail.com Wed Mar 28 11:10:12 2012 From: bjornliu at gmail.com (Bingyang LIU) Date: Wed, 28 Mar 2012 18:10:12 +0200 Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> Message-ID: Hi David, Leo, Patrick and all, Considering the reasons you raised, do you think the following two things can happen? 1. Give BCP38 the only practical anti-spoofing technique, can an ISP well protect its customers by implementing BCP38? I don't think so, because I think BCP38 is accurate near the source but inaccurate near the destination, i.e. if its customer is the target of spoofing attack, its capability to filter is relatively low. 2. Even if ineffective near the destination, is an ISP willing to deploy it if it becomes easy to adopt and risk-free (no false positive)? Sorry for my stupid and naive questions. best Bingyang On Wed, Mar 28, 2012 at 5:45 PM, David Conrad wrote: > Leo, > > On Mar 28, 2012, at 8:13 AM, Leo Bicknell wrote: > >> #1) Money. > >> #2) Laziness. > > > While Patrick is spot on, there is a third issue which is related > > to money and laziness, but also has some unique aspects. > > > > BCP38 makes the assumption that the ISP does some "configuration" > > to insure only properly sourced packets enter the network. That > > may have been true when BCP38 was written, but no longer accurately > > reflects how networks are built and operated. > > An interesting assertion. I haven't looked at how end-user networks are > built recently. I had assumed there continue to be customer aggregation > points within ISP infrastructure in which BCP38-type filtering could occur. > You're saying this is no longer the case? What has replaced it? > > > BCP38 needs > > > to be applied at the OEM level in equipment maufacturing, not at > > the operational level with ISP's. > > I don't believe this is either/or. I agree that BCP38 features should be > turned on by default in CPE, however I believe it really needs to be > enforced at the ISP level. > > > As long as folks keep beating on (consumer) ISPs to implement BCP38, > nothing will happen. > > > Optimist. > > Actually, given the uptick in spoofing-based DoS attacks, the ease in > which such attacks can be generated, recent high profile targets of said > attacks, and the full-on money pumping freakout about anything with > "cyber-" tacked on the front, I suspect a likely outcome will be proposals > for legislation forcing ISPs to do something like BCP38. > > Regards, > -drc > > > -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby From bicknell at ufp.org Wed Mar 28 11:16:10 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 28 Mar 2012 09:16:10 -0700 Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> Message-ID: <20120328161610.GA43005@ussenterprise.ufp.org> In a message written on Wed, Mar 28, 2012 at 08:45:12AM -0700, David Conrad wrote: > An interesting assertion. I haven't looked at how end-user networks are built recently. I had assumed there continue to be customer aggregation points within ISP infrastructure in which BCP38-type filtering could occur. You're saying this is no longer the case? What has replaced it? Well, RFC3704 for one has updated the methods and tactics since BCP38 was written. Remember BCP38 was before even "unicast RPF" as we know it existed. Some relevant points from 3704: 3. Clarifying the Applicability of Ingress Filtering What may not be readily apparent is that ingress filtering is not applied only at the "last-mile" interface between the ISP and the end user. It's perfectly fine, and recommended, to also perform ingress filtering at the edges of ISPs where appropriate, at the routers connecting LANs to an enterprise network, etc. -- this increases the defense in depth. 5. Security Considerations [snip] The closer to the actual source ingress filtering is performed, the more effective it is. One could wish that the first hop router would ensure that traffic being sourced from its neighboring end system was correctly addressed; a router further away can only ensure that it is possible that there is such a system within the indicated prefix. Therefore, ingress filtering should be done at multiple levels, with different level of granularity I'm not saying ISP's can't or couldn't do it, what I am saying, and RFC 3704 is repeating, is that it is cheaper/easier/faster and more reliable to do it as close to the edge as possible. "The edge" is not the edge of the ISP network, it is the edge of the entire network, that is the /last router in the topology/. Today that last router is owned and operated by the customer in most cases. So if a provider drops off a modem with your service that also does WiFi and the customer simply uses it, the provider is 100% responsible for doing BCP 38, in my estimation. But as soon as the consumer buys a routing device they become 100% on the hook for now operating the last mile, and it is that device where the primary filtering should take place. ISP's may still filter, for a defense in depth, but they are no longer the edge of the network and as such their responsibility is greatly diminished in my view. BCP38 was written when a point to point handoff to a single customer was standard, and that's easy to filter. Today a shared medium (like a cable modem network) is common and more importantly connects to more routers (home gateways), rathern than PC's. That's a funamental change since BCP38 was written. I'll also point out that operating systems fill a role here as well. Many OS's won't let you spoof a layer 2 MAC address (try to write a packet with a raw interface and it overwrites the source address) but are happy to let an application send a packet with source layer 3 address that is forged! Sure, malware could always hack the OS too, but it raises the bar. The community should demand that all OS's default to not allowing L3 sources that aren't configured on the box from leaving that box. -- 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 rps at maine.edu Wed Mar 28 11:27:03 2012 From: rps at maine.edu (Ray Soucy) Date: Wed, 28 Mar 2012 12:27:03 -0400 Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> Message-ID: While I'm a big fan of RFP, it does require that operators be "good citizens" for it to be effective. Like most of the Internet, it's built on a "web" of trust. On Wed, Mar 28, 2012 at 12:10 PM, Bingyang LIU wrote: > Hi David, Leo, Patrick and all, > > Considering the reasons you raised, do you think the following two things > can happen? > > 1. Give BCP38 the only practical anti-spoofing technique, can an ISP well > protect its customers by implementing BCP38? I don't think so, because I > think BCP38 is accurate near the source but inaccurate near the > destination, i.e. if its customer is the target of spoofing attack, its > capability to filter is relatively low. > > 2. Even if ineffective near the destination, is an ISP willing to deploy it > if it becomes easy to adopt and risk-free (no false positive)? > > Sorry for my stupid and naive questions. > > best > Bingyang > > On Wed, Mar 28, 2012 at 5:45 PM, David Conrad wrote: > >> Leo, >> >> On Mar 28, 2012, at 8:13 AM, Leo Bicknell wrote: >> >> #1) Money. >> >> #2) Laziness. >> >> > While Patrick is spot on, there is a third issue which is related >> > to money and laziness, but also has some unique aspects. >> > >> > BCP38 makes the assumption that the ISP does some "configuration" >> > to insure only properly sourced packets enter the network. ?That >> > may have been true when BCP38 was written, but no longer accurately >> > reflects how networks are built and operated. >> >> An interesting assertion. ?I haven't looked at how end-user networks are >> built recently. ?I had assumed there continue to be customer aggregation >> points within ISP infrastructure in which BCP38-type filtering could occur. >> ?You're saying this is no longer the case? ?What has replaced it? >> >> > BCP38 needs >> >> > to be applied at the OEM level in equipment maufacturing, not at >> > the operational level with ISP's. >> >> I don't believe this is either/or. ?I agree that BCP38 features should be >> turned on by default in CPE, however I believe it really needs to be >> enforced at the ISP level. >> >> > As long as folks keep beating on (consumer) ISPs to implement BCP38, >> nothing will happen. >> >> >> Optimist. >> >> Actually, given the uptick in spoofing-based DoS attacks, the ease in >> which such attacks can be generated, recent high profile targets of said >> attacks, and the full-on money pumping freakout about anything with >> "cyber-" tacked on the front, I suspect a likely outcome will be proposals >> for legislation forcing ISPs to do something like BCP38. >> >> Regards, >> -drc >> >> >> > > > -- > Bingyang Liu > Network Architecture Lab, Network Center,Tsinghua Univ. > Beijing, China > Home Page: http://netarchlab.tsinghua.edu.cn/~liuby -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From psirt at cisco.com Wed Mar 28 11:20:57 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 28 Mar 2012 12:20:57 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Smart Install Denial of Service Vulnerability Message-ID: <201203281220068.cisco-sa-20120328-smartinstall@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco IOS Software Smart Install Denial of Service Vulnerability Advisory ID: cisco-sa-20120328-smartinstall Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software contains a vulnerability in the Smart Install feature that could allow an unauthenticated, remote attacker to cause a reload of an affected device if the Smart Install feature is enabled. The vulnerability is triggered when an affected device processes a malformed Smart Install message on TCP port 4786. Cisco has released free software updates that address this vulnerability. There are no workarounds to mitigate this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-smartinstall Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar12.html Affected Products ================= Vulnerable Products +------------------ Devices configured as a Smart Install client or director are affected by this vulnerability. To display Smart Install information, use the show vstack config privileged EXEC command on the Smart Install director or client. The outputs of show commands are different when entered on the director or on the client. The following is the output of show vstack config in a Cisco Catalyst Switch configured as a Smart Install client: switch#show vstack config Role: Client Vstack Director IP address: 10.1.1.163 The following is the output of show vstack config in a Cisco Catalyst Switch configured as a Smart Install director: Director# show vstack config Role: Director Vstack Director IP address: 10.1.1.163 Vstack Mode: Basic Vstack default management vlan: 1 Vstack management Vlans: none Vstack Config file: tftp://10.1.1.100/default-config.txt Vstack Image file: tftp://10.1.1.100/c3750e-universalk9-tar.122- Join Window Details: Window: Open (default) Operation Mode: auto (default) Vstack Backup Details: Mode: On (default) Repository: flash:/vstack (default) The Smart Install Feature is enabled by default. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.0(1)M1 with an installed image name of C3900-UNIVERSALK9-M: Router> show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS and NX-OS Software Reference Guide" at: http://www.cisco.com/web/about/security/intelligence/ios-ref.html Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS XR Software is not affected by this vulnerability. Cisco IOS XE Software is not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Smart Install is a plug-and-play configuration and image-management feature that provides zero-touch deployment for new LAN Ethernet switches. This feature allows, for example, new LAN switches to be deployed at new locations without any configuration. A vulnerability exists in the Smart Install feature of Cisco IOS Software that could allow an unauthenticated, remote attacker to cause a reload of an affected device. Smart Install uses a Cisco proprietary protocol that runs over TCP port 4786. To exploit this vulnerability, an attacker needs to establish a TCP session on port 4786 of an affected device that has the Smart Install feature enabled, and then send a malformed Smart Install message. This vulnerability is documented in Cisco bug ID CSCtt16051 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2012-0385. Vulnerability Scoring Details ============================= Cisco has scored the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this security advisory is in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps organizations determine the urgency and priority of a response. Cisco has provided a base and temporal score. Customers can also compute environmental scores that help determine the impact of the vulnerability in their own networks. Cisco has provided additional information regarding CVSS at the following link: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to compute the environmental impact for individual networks at the following link: http://intellishield.cisco.com/security/alertmanager/cvss * Cisco IOS Software Smart Install Denial of Service Vulnerability CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability that is described in this advisory may cause a reload of an affected device. Repeated exploitation could result in a sustained denial of service condition. Software Versions and Fixes =========================== When considering software upgrades, also consult: http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Cisco IOS Software +----------------- Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release column. The First Fixed Release for All Advisories in the March 2012 Bundled Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. The Cisco IOS Software Checker allows customers to search for Cisco Security Advisories that address specific Cisco IOS Software releases. This tool is available on the Cisco Security Intelligence Operations (SIO) portal at: http://tools.cisco.com/security/center/selectIOSVersion.x +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |----------+--------------------------------------------------------| | Affected | | First Fixed Release for All | |12.0-Based| First Fixed Release |Advisories in the March 2012 Cisco| | Releases | | IOS Software Security Advisory | | | | Bundled Publication | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for All | |12.2-Based| First Fixed Release |Advisories in the March 2012 Cisco| | Releases | | IOS Software Security Advisory | | | | Bundled Publication | |----------+---------------------+----------------------------------| |12.2 |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2B |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2BC |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2BW |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2BX |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SB | |----------+---------------------+----------------------------------| |12.2BY |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2BZ |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2CX |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2CY |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2CZ |Not vulnerable |Vulnerable; First fixed in Release| | | |12.0S | |----------+---------------------+----------------------------------| |12.2DA |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2DD |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2DX |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2EU |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2EW |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2EWA |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | |Vulnerable; First | | | |fixed in Release | | |12.2EX |15.0SE |Vulnerable; First fixed in Release| | |Releases up to and |15.0SE | | |including 12.2(46)EX | | | |are not vulnerable. | | |----------+---------------------+----------------------------------| | |Vulnerable; migrate | | | |to any release in | | |12.2EY |15.1EY |12.2(52)EY4 | | |Releases up to and | | | |including 12.2(52)EY4| | | |are not vulnerable. | | |----------+---------------------+----------------------------------| | |Vulnerable; First | | | |fixed in Release | | |12.2EZ |15.0SE |Vulnerable; First fixed in Release| | |Releases up to and |15.0SE | | |including 12.2(53)EZ | | | |are not vulnerable. | | |----------+---------------------+----------------------------------| |12.2FX |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0SE | |----------+---------------------+----------------------------------| |12.2FY |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0SE | |----------+---------------------+----------------------------------| |12.2FZ |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0SE | |----------+---------------------+----------------------------------| |12.2IRA |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| |12.2IRB |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| |12.2IRC |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| |12.2IRD |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| |12.2IRE |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| |12.2IRF |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2IRG |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2IRH |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2IXA |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2IXB |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2IXC |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2IXD |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2IXE |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2IXF |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2IXG |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2IXH |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| |12.2JA |Not vulnerable |Not vulnerable | |----------+---------------------+----------------------------------| |12.2JK |Not vulnerable |Not vulnerable | |----------+---------------------+----------------------------------| |12.2MB |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2MC |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2MRA |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2MRB |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Releases prior to 12.2(30)S are | |12.2S |Not vulnerable |vulnerable; Releases 12.2(30)S and| | | |later are not vulnerable. First | | | |fixed in Release 12.0S | |----------+---------------------+----------------------------------| |12.2SB |Not vulnerable |12.2(33)SB12 | |----------+---------------------+----------------------------------| |12.2SBC |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| |12.2SCA |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SCE | |----------+---------------------+----------------------------------| |12.2SCB |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SCE | |----------+---------------------+----------------------------------| |12.2SCC |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SCE | |----------+---------------------+----------------------------------| |12.2SCD |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SCE | |----------+---------------------+----------------------------------| |12.2SCE |Not vulnerable |12.2(33)SCE6 | |----------+---------------------+----------------------------------| |12.2SCF |Not vulnerable |12.2(33)SCF2 | |----------+---------------------+----------------------------------| |12.2SE |12.2(55)SE5 | | | | |12.2(55)SE5 * | |----------+---------------------+----------------------------------| |12.2SEA |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0SE | |----------+---------------------+----------------------------------| |12.2SEB |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0SE | |----------+---------------------+----------------------------------| |12.2SEC |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0SE | |----------+---------------------+----------------------------------| |12.2SED |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0SE | |----------+---------------------+----------------------------------| |12.2SEE |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0SE | |----------+---------------------+----------------------------------| |12.2SEF |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0SE | |----------+---------------------+----------------------------------| |12.2SEG |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0SE | |----------+---------------------+----------------------------------| |12.2SG |Not vulnerable |12.2(53)SG7; Available on | | | |07-MAY-12 | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SGA |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| |12.2SL |Not vulnerable |Not vulnerable | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SM |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SO |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SQ |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| |12.2SRA |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| |12.2SRB |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| |12.2SRC |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| |12.2SRD |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| |12.2SRE |Not vulnerable |12.2(33)SRE6 | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2STE |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| |12.2SU |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2SV |Not vulnerable |Releases up to and including 12.2 | | | |(18)SV2 are not vulnerable. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SVA |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SVC |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SVD |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SVE |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| |12.2SW |Not vulnerable |Vulnerable; First fixed in Release| | | |12.4T | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SX |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SXA |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SXB |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SXD |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SXE |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SXF |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2SXH |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| |12.2SXI |Not vulnerable |12.2(33)SXI9 | |----------+---------------------+----------------------------------| |12.2SXJ |Not vulnerable |12.2(33)SXJ2 | |----------+---------------------+----------------------------------| |12.2SY |Not vulnerable |12.2(50)SY2; Available on | | | |11-JUN-12 | |----------+---------------------+----------------------------------| |12.2SZ |Not vulnerable |Vulnerable; First fixed in Release| | | |12.0S | |----------+---------------------+----------------------------------| |12.2T |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2TPC |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| |12.2XA |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XB |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XC |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XD |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XE |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XF |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XG |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XH |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XI |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XJ |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XK |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XL |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XM |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| | |Please see Cisco |Please see Cisco IOS-XE Software | |12.2XNA |IOS-XE Software |Availability | | |Availability | | |----------+---------------------+----------------------------------| | |Please see Cisco |Please see Cisco IOS-XE Software | |12.2XNB |IOS-XE Software |Availability | | |Availability | | |----------+---------------------+----------------------------------| | |Please see Cisco |Please see Cisco IOS-XE Software | |12.2XNC |IOS-XE Software |Availability | | |Availability | | |----------+---------------------+----------------------------------| | |Please see Cisco |Please see Cisco IOS-XE Software | |12.2XND |IOS-XE Software |Availability | | |Availability | | |----------+---------------------+----------------------------------| | |Please see Cisco |Please see Cisco IOS-XE Software | |12.2XNE |IOS-XE Software |Availability | | |Availability | | |----------+---------------------+----------------------------------| | |Please see Cisco |Please see Cisco IOS-XE Software | |12.2XNF |IOS-XE Software |Availability | | |Availability | | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2XO |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| |12.2XQ |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| | | |Releases prior to 12.2(15)XR are | |12.2XR |Not vulnerable |vulnerable; Releases 12.2(15)XR | | | |and later are not vulnerable. | | | |First fixed in Release 15.0M | |----------+---------------------+----------------------------------| |12.2XS |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XT |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XU |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XV |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2XW |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2YA |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2YC |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2YD |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2YE |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2YK |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2YO |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; First fixed in Release| |12.2YP |Not vulnerable |15.0M | | | |Releases up to and including 12.2 | | | |(8)YP are not vulnerable. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2YT |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2YW |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2YX |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2YY |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2YZ |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2ZA |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2ZB |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2ZC |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2ZD |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| |12.2ZE |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| |12.2ZH |Not vulnerable |Vulnerable; First fixed in Release| | | |15.0M | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2ZJ |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2ZP |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2ZU |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| |12.2ZX |Not vulnerable |Vulnerable; First fixed in Release| | | |12.2SRE | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2ZY |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |12.2ZYA |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | Affected | | First Fixed Release for All | |12.3-Based| First Fixed Release |Advisories in the March 2012 Cisco| | Releases | | IOS Software Security Advisory | | | | Bundled Publication | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for All | |12.4-Based| First Fixed Release |Advisories in the March 2012 Cisco| | Releases | | IOS Software Security Advisory | | | | Bundled Publication | |-------------------------------------------------------------------| | There are no affected 12.4 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for All | |15.0-Based| First Fixed Release |Advisories in the March 2012 Cisco| | Releases | | IOS Software Security Advisory | | | | Bundled Publication | |----------+---------------------+----------------------------------| |15.0M |Not vulnerable |15.0(1)M8 | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |15.0MR |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |15.0MRA |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | |Not vulnerable | | | |Cisco IOS XE devices:|15.0(1)S5 | |15.0S |Please see Cisco IOS |Cisco IOS XE devices: Please see | | |XE Software |Cisco IOS XE Software Availability| | |Availability | | |----------+---------------------+----------------------------------| |15.0SA |Not vulnerable |Not vulnerable | |----------+---------------------+----------------------------------| |15.0SE |15.0(1)SE1 |15.0(1)SE1 | |----------+---------------------+----------------------------------| | |Not vulnerable | | | |Cisco IOS XE devices:|15.0(2)SG2 | |15.0SG |Please see Cisco IOS |Cisco IOS XE devices: Please see | | |XE Software |Cisco IOS XE Software Availability| | |Availability | | |----------+---------------------+----------------------------------| |15.0SY |Not vulnerable |15.0(1)SY1 | |----------+---------------------+----------------------------------| |15.0XA |Not vulnerable |Vulnerable; First fixed in Release| | | |15.1T | |----------+---------------------+----------------------------------| | |Cisco IOS XE devices:| | |15.0XO |Please see Cisco |Cisco IOS XE devices: Please see | | |IOS-XE Software |Cisco IOS-XE Software Availability| | |Availability | | |----------+---------------------+----------------------------------| | Affected | | First Fixed Release for All | |15.1-Based| First Fixed Release |Advisories in the March 2012 Cisco| | Releases | | IOS Software Security Advisory | | | | Bundled Publication | |----------+---------------------+----------------------------------| |15.1EY |Not vulnerable |15.1(2)EY2 | |----------+---------------------+----------------------------------| |15.1GC |Not vulnerable |15.1(2)GC2 | |----------+---------------------+----------------------------------| |15.1M |15.1(4)M4; Available |15.1(4)M4; Available on 30-MAR-12 | | |on 30-MAR-12 | | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |15.1MR |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| | |Not vulnerable | | | |Cisco IOS XE devices:|15.1(3)S2 | |15.1S |Please see Cisco IOS |Cisco IOS XE devices: Please see | | |XE Software |Cisco IOS XE Software Availability| | |Availability | | |----------+---------------------+----------------------------------| | |Not vulnerable | | | |Cisco IOS XE devices:|Not vulnerable | |15.1SG |Please see Cisco IOS |Cisco IOS XE devices: Please see | | |XE Software |Cisco IOS XE Software Availability| | |Availability | | |----------+---------------------+----------------------------------| | | |Vulnerable; contact your support | |15.1SNG |Not vulnerable |organization per the instructions | | | |in Obtaining Fixed Software | | | |section of this advisory. | |----------+---------------------+----------------------------------| |15.1SNH |Not vulnerable |Not vulnerable | |----------+---------------------+----------------------------------| |15.1T |15.1(3)T3 |15.1(3)T3 | |----------+---------------------+----------------------------------| |15.1XB |Not vulnerable |Vulnerable; First fixed in Release| | | |15.1T | |----------+---------------------+----------------------------------| | Affected | | First Fixed Release for All | |15.2-Based| First Fixed Release |Advisories in the March 2012 Cisco| | Releases | | IOS Software Security Advisory | | | | Bundled Publication | |----------+---------------------+----------------------------------| |15.2GC |15.2(1)GC2 |15.2(1)GC2 | |----------+---------------------+----------------------------------| | |Not vulnerable |15.2(1)S1 | | |Cisco IOS XE devices:| | |15.2S |Please see Cisco IOS |Cisco IOS XE devices: Please see | | |XE Software |Cisco IOS XE Software Availability| | |Availability | | |----------+---------------------+----------------------------------| | |15.2(1)T2 |15.2(1)T2 | |15.2T |15.2(2)T1 |15.2(2)T1 | | |15.2(3)T; Available |15.2(3)T; Available on 30-MAR-12 | | |on 30-MAR-12 | | +-------------------------------------------------------------------+ * Cisco Catalyst 3550 Series Switches support the Internet Key Exchange (IKE) feature and are vulnerable to Cisco bug ID CSCts38429 when the devices are running Layer 3 images; however, this product reached the End of Software Maintenance milestone. Cisco 3550 Series SMI Switches that are running Layer 2 images do not support IKE and are not vulnerable. No other Cisco devices that run 12.2SE-based software are vulnerable. Cisco IOS XE Software +-------------------- Cisco IOS XE Software is not affected by the vulnerability disclosed in this advisory. Cisco IOS XR Software +-------------------- Cisco IOS XR Software is not affected by any of the vulnerabilities disclosed in the March 2012 Cisco IOS Software Security Advisory Bundled Publication. Workarounds =========== There are no workarounds available to mitigate this vulnerability other than disabling the Smart Install feature. To disable the Smart Install feature use the global configuration command no vstack. Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link: http://tools.cisco.com/security/center/content/CiscoAppliedMitigationBulletin/cisco-amb-20120328-smartinstall Obtaining Fixed Software ======================== Cisco has released free software updates that address the vulnerability described in this advisory. Prior to deploying software, customers are advised to consult their maintenance providers or check the software for feature set compatibility and known issues that are specific to their environments. Customers may only install and expect support for feature sets they have purchased. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as set forth at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, upgrades should be obtained through the Software Center on Cisco.com at: http://www.cisco.com Customers Using Third-Party Support Organizations +------------------------------------------------ Customers with Cisco products that are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers, should contact that organization for assistance with the appropriate course of action. The effectiveness of any workaround or fix depends on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Because of the variety of affected products and releases, customers should consult their service providers or support organizations to ensure that any applied workaround or fix is the most appropriate in the intended network before it is deployed. Customers Without Service Contracts +---------------------------------- Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC): * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade. Customers without service contracts should request free upgrades through the TAC. Refer to Cisco Worldwide Contacts at: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, instructions, and e-mail addresses for support in various languages. Exploitation and Public Announcements ===================================== The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory. This issue was reported to Cisco by customers who discovered it during the course of security audits. Status of This Notice: Final +--------------------------- THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco Security Intelligence Operations at the following link http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-smartinstall Additionally, a text version of this advisory is clear signed with the Cisco PSIRT PGP key and circulated among the following e-mail addresses: * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk Future updates of this advisory, if any, will reside on Cisco.com but may not be announced on mailing lists. Users can monitor this advisory's URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2012-March-28 | public | | | | release. | +---------------------------------------+ Cisco Security Procedures ========================= Complete information about reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco is available on Cisco.com at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This web page includes instructions for press inquiries regarding Cisco Security Advisories. All Cisco Security Advisories are available at: http://www.cisco.com/go/psirt +-------------------------------------------------------------------- Copyright 2010-2012 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (SunOS) iFcDBQFPcSThQXnnBKKRMNARCOH4AP9Wgc8t/hVLf4NZrWSE6Y64edlgu+lg7MB6 h5OtNEQTgAD/Ux8fxWyhS8HGYK17bT294K2OMuymiytT5sN/T2u/ZY8= =6eFE -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 28 11:20:57 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 28 Mar 2012 12:20:57 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Reverse SSH Denial of Service Vulnerability Message-ID: <201203281220068.cisco-sa-20120328-ssh@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco IOS Software Reverse SSH Denial of Service Vulnerability Advisory ID: cisco-sa-20120328-ssh Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= The Secure Shell (SSH) server implementation in Cisco IOS Software and Cisco IOS XE Software contains a denial of service (DoS) vulnerability in the SSH version 2 (SSHv2) feature. An unauthenticated, remote attacker could exploit this vulnerability by attempting a reverse SSH login with a crafted username. Successful exploitation of this vulnerability could allow an attacker to create a DoS condition by causing the device to reload. Repeated exploits could create a sustained DoS condition. The SSH server in Cisco IOS Software and Cisco IOS XE Software is an optional service, but its use is highly recommended as a security best practice for the management of Cisco IOS devices. Devices that are not configured to accept SSHv2 connections are not affected by this vulnerability. Cisco has released free software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-ssh Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar12.html Affected Products ================= Vulnerable Products +------------------ Cisco devices that are running affected Cisco IOS Software or Cisco IOS XE Software versions are vulnerable when they have the SSH server enabled and allow SSHv2 logins. Only SSHv2 is affected. To determine if SSH is enabled, use the show ip ssh command. Router#show ip ssh SSH Enabled - version 2.0 Authentication timeout: 120 secs; Authentication retries: 3 The previous output shows that SSH is enabled on this device and that the SSH protocol major version that is being supported is 2.0. Possible values for the SSH protocol versions that are reported by Cisco IOS are: * 1.5: only SSH protocol version 1 is enabled * 1.99: SSH protocol version 2 with SSH protocol version 1 compatibility enabled * 2.0: only SSH protocol version 2 is enabled The SSH server is not available in all IOS images. If the show ip ssh command is not available, the device is not vulnerable. Devices that do not support SSHv2 are not vulnerable. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.0(1)M1 with an installed image name of C3900-UNIVERSALK9-M: Router> show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS and NX-OS Software Reference Guide" at: http://www.cisco.com/web/about/security/intelligence/ios-ref.html Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS-XR is not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Secure Shell (SSH) is a protocol which provides a secure remote access connection to network devices. The SSH server implementation in Cisco IOS Software and Cisco IOS XE Software contains a DoS vulnerability in the SSH version 2 (SSHv2) feature that could allow an unauthenticated remote attacker to cause a device to reload. An attacker could exploit this vulnerability by attempting a reverse SSH login with a crafted username. Successful exploitation of this vulnerability could allow an attacker to create a DoS condition by causing the device to reload. Repeated exploits could create a sustained DoS condition. The SSH server in Cisco IOS Software and Cisco IOS XE Software is an optional service, but its use is highly recommended as a security best practice for management of Cisco IOS devices. SSH can be configured as part of the AutoSecure feature in the initial configuration of IOS devices, AutoSecure run after initial configuration, or manually. SSH is enabled any time RSA keys are generated such as when an http secure-server or trust points for digital certificates are configured. Devices that are not configured to accept SSHv2 connections are not affected by this vulnerability. A complete TCP three-way handshake is required to exploit this vulnerability. Reverse SSH traffic uses TCP port 22 by default. This vulnerability has been documented in Cisco Bug ID CSCtr49064 and has been assigned the Common Vulnerabilities and Exposures (CVE) ID CVE-2012-0386. Vulnerability Scoring Details ============================= Cisco has scored the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this security advisory is in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps organizations determine the urgency and priority of a response. Cisco has provided a base and temporal score. Customers can also compute environmental scores that help determine the impact of the vulnerability in their own networks. Cisco has provided additional information regarding CVSS at the following link: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to compute the environmental impact for individual networks at the following link: http://intellishield.cisco.com/security/alertmanager/cvss * CSCtr49064 - Cisco IOS Software Reverse SSH Denial of Service CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability could allow an unauthenticated, remote attacker to create a DoS condition by causing the device to reload. Repeated exploits could create a sustained DoS condition. Software Versions and Fixes =========================== When considering software upgrades, customers are advised to consult the Cisco Security Advisories and Responses archive at: http://www.cisco.com/go/psirt and review subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should ensure that the devices to be upgraded contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers. Cisco IOS Software +----------------- Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release column. The First Fixed Release for All Advisories in the March 2012 Bundled Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. The Cisco IOS Software Checker allows customers to search for Cisco Security Advisories that address specific Cisco IOS Software releases. This tool is available on the Cisco Security Intelligence Operations (SIO) portal at: http://tools.cisco.com/security/center/selectIOSVersion.x +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |----------+--------------------------------------------------------| | Affected | |First Fixed Release for All | |12.0-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | |First Fixed Release for All | |12.2-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |----------+---------------------------+----------------------------| |12.2 |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2B |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2BC |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2BW |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2BX |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SB | |----------+---------------------------+----------------------------| |12.2BY |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2BZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2CX |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2CY |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2CZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.0S | |----------+---------------------------+----------------------------| |12.2DA |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2DD |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2DX |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2EU |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2EW |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2EWA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | |Vulnerable; First fixed in | | | |Release 15.0SE |Vulnerable; First fixed in | |12.2EX |Releases up to and |Release 15.0SE | | |including 12.2(55)EX3 are | | | |not vulnerable. | | |----------+---------------------------+----------------------------| |12.2EY |12.2(58)EY2 |12.2(52)EY4 | |----------+---------------------------+----------------------------| |12.2EZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+---------------------------+----------------------------| |12.2FX |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+---------------------------+----------------------------| |12.2FY |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+---------------------------+----------------------------| |12.2FZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+---------------------------+----------------------------| |12.2IRA |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| |12.2IRB |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| |12.2IRC |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| |12.2IRD |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| |12.2IRE |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| |12.2IRF |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2IRG |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2IRH |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2IXA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2IXB |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2IXC |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2IXD |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2IXE |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2IXF |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2IXG |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2IXH |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.2JA |Not vulnerable |Not vulnerable | |----------+---------------------------+----------------------------| |12.2JK |Not vulnerable |Not vulnerable | |----------+---------------------------+----------------------------| |12.2MB |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2MC |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2MRA |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2MRB |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Releases prior to 12.2(30)S | | | |are vulnerable; Releases | |12.2S |Not vulnerable |12.2(30)S and later are not | | | |vulnerable. First fixed in | | | |Release 12.0S | |----------+---------------------------+----------------------------| |12.2SB |Not vulnerable |12.2(33)SB12 | |----------+---------------------------+----------------------------| |12.2SBC |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| |12.2SCA |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SCE | |----------+---------------------------+----------------------------| |12.2SCB |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SCE | |----------+---------------------------+----------------------------| |12.2SCC |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SCE | |----------+---------------------------+----------------------------| |12.2SCD |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SCE | |----------+---------------------------+----------------------------| |12.2SCE |Not vulnerable |12.2(33)SCE6 | |----------+---------------------------+----------------------------| |12.2SCF |Not vulnerable |12.2(33)SCF2 | |----------+---------------------------+----------------------------| | |Vulnerable; First fixed in | | | |Release 15.0SE | | |12.2SE |Releases up to and |12.2(55)SE5 * | | |including 12.2(58)SE1 are | | | |not vulnerable. | | |----------+---------------------------+----------------------------| |12.2SEA |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+---------------------------+----------------------------| |12.2SEB |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+---------------------------+----------------------------| |12.2SEC |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+---------------------------+----------------------------| |12.2SED |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+---------------------------+----------------------------| |12.2SEE |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+---------------------------+----------------------------| |12.2SEF |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+---------------------------+----------------------------| |12.2SEG |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+---------------------------+----------------------------| |12.2SG |Not vulnerable |12.2(53)SG7; Available on | | | |07-MAY-12 | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SGA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.2SL |Not vulnerable |Not vulnerable | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SM |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SO |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SQ |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.2SRA |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| |12.2SRB |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| |12.2SRC |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| |12.2SRD |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| |12.2SRE |Not vulnerable |12.2(33)SRE6 | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2STE |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.2SU |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| | | |Releases up to and including| |12.2SV |Not vulnerable |12.2(18)SV2 are not | | | |vulnerable. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SVA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SVC |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SVD |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SVE |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.2SW |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4T | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SX |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SXA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SXB |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SXD |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SXE |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SXF |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2SXH |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.2SXI |Not vulnerable |12.2(33)SXI9 | |----------+---------------------------+----------------------------| |12.2SXJ |Not vulnerable |12.2(33)SXJ2 | |----------+---------------------------+----------------------------| |12.2SY |Not vulnerable |12.2(50)SY2; Available on | | | |11-JUN-12 | |----------+---------------------------+----------------------------| |12.2SZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.0S | |----------+---------------------------+----------------------------| |12.2T |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2TPC |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.2XA |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XB |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XC |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XD |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XE |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XF |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XG |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XH |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XI |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XJ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XK |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XL |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XM |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XNA |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+---------------------------+----------------------------| |12.2XNB |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+---------------------------+----------------------------| |12.2XNC |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+---------------------------+----------------------------| |12.2XND |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+---------------------------+----------------------------| |12.2XNE |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+---------------------------+----------------------------| |12.2XNF |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2XO |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.2XQ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| | | |Releases prior to 12.2(15)XR| | | |are vulnerable; Releases | |12.2XR |Not vulnerable |12.2(15)XR and later are not| | | |vulnerable. First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XS |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XT |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XU |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XV |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2XW |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2YA |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2YC |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2YD |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2YE |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2YK |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2YO |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; First fixed in | | | |Release 15.0M | |12.2YP |Not vulnerable |Releases up to and including| | | |12.2(8)YP are not | | | |vulnerable. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2YT |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2YW |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2YX |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2YY |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2YZ |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2ZA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2ZB |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2ZC |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2ZD |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.2ZE |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.2ZH |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2ZJ |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2ZP |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2ZU |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.2ZX |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2ZY |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.2ZYA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | Affected | |First Fixed Release for All | |12.3-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | |First Fixed Release for All | |12.4-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |----------+---------------------------+----------------------------| | |Releases 12.4(13d) and |Vulnerable; First fixed in | |12.4 |prior are not vulnerable; |Release 15.0M | | |first fixed in 12.4(25f) | | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |12.4GC |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| |12.4JA |12.4(23c)JA4 |12.4(23c)JA4 | | |12.4(25e)JA |12.4(25e)JA | |----------+---------------------------+----------------------------| |12.4JAX |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4JA |Release 12.4JA | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |12.4JDA |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |12.4JDC |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |12.4JDD |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |12.4JDE |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |12.4JHA |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |12.4JHB |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |12.4JHC |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4JK |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4JL |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | |Vulnerable; First fixed in | | | |Release 12.4JA |Vulnerable; First fixed in | |12.4JX |Releases up to and |Release 12.4JA | | |including 12.4(3g)JX2 are | | | |not vulnerable. | | |----------+---------------------------+----------------------------| |12.4JY |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4JA |Release 12.4JA | |----------+---------------------------+----------------------------| |12.4JZ |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4JA |Release 12.4JA | |----------+---------------------------+----------------------------| |12.4MD |12.4(22)MD3; Available on |12.4(22)MD3; Available on | | |30-MAR-12 |30-MAR-12 | |----------+---------------------------+----------------------------| |12.4MDA |12.4(24)MDA11 |12.4(24)MDA11 | |----------+---------------------------+----------------------------| |12.4MDB |12.4(24)MDB5a |12.4(24)MDB5a | |----------+---------------------------+----------------------------| |12.4MDC |Not vulnerable |Not vulnerable | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | |Releases up to and |support organization per the| |12.4MR |including 12.4(16)MR1 are |instructions in Obtaining | | |not vulnerable. |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |12.4MRA |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| |12.4MRB |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+---------------------------+----------------------------| |12.4SW |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| | |12.4(15)T16 |12.4(15)T17 | |12.4T |12.4(24)T6 |12.4(24)T7 | | | | | |----------+---------------------------+----------------------------| |12.4XA |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.4XB |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4T | |----------+---------------------------+----------------------------| |12.4XC |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.4XD |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.4XE |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.4XF |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.4XG |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.4XJ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.4XK |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4XL |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.4XM |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4XN |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4XP |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.4XQ |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+---------------------------+----------------------------| |12.4XR |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 12.4T | |----------+---------------------------+----------------------------| |12.4XT |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4XV |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| |12.4XW |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.4XY |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+---------------------------+----------------------------| |12.4XZ |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+---------------------------+----------------------------| |12.4YA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |12.4YB |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |12.4YD |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| |12.4YE |12.4(24)YE3d |12.4(24)YE3d | |----------+---------------------------+----------------------------| |12.4YG |12.4(24)YG4 |12.4(24)YG4 | |----------+---------------------------+----------------------------| | Affected | |First Fixed Release for All | |15.0-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |----------+---------------------------+----------------------------| |15.0M |15.0(1)M7 |15.0(1)M8 | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |15.0MR |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |15.0MRA |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| | |15.0(1)S5 |15.0(1)S5 | |15.0S |Cisco IOS XE devices: |Cisco IOS XE devices: Please| | |Please see Cisco IOS XE |see Cisco IOS XE Software | | |Software Availability |Availability | |----------+---------------------------+----------------------------| |15.0SA |Not vulnerable |Not vulnerable | |----------+---------------------------+----------------------------| | |15.0(1)SE1 | | |15.0SE |15.0(2)SE; Available on |15.0(1)SE1 | | |06-AUG-12 | | |----------+---------------------------+----------------------------| | |Not vulnerable |15.0(2)SG2 | |15.0SG |Cisco IOS XE devices: |Cisco IOS XE devices: Please| | |Please see Cisco IOS-XE |see Cisco IOS-XE Software | | |Software Availability |Availability | |----------+---------------------------+----------------------------| |15.0SY |Not vulnerable |15.0(1)SY1 | |----------+---------------------------+----------------------------| |15.0XA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.1T |Release 15.1T | |----------+---------------------------+----------------------------| | |Cisco IOS XE devices: |Cisco IOS XE devices: Please| |15.0XO |Please see Cisco IOS-XE |see Cisco IOS-XE Software | | |Software Availability |Availability | |----------+---------------------------+----------------------------| | Affected | |First Fixed Release for All | |15.1-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |----------+---------------------------+----------------------------| |15.1EY |15.1(2)EY1a |15.1(2)EY2 | |----------+---------------------------+----------------------------| |15.1GC |15.1(2)GC2 |15.1(2)GC2 | |----------+---------------------------+----------------------------| |15.1M |15.1(4)M2 |15.1(4)M4; Available on | | | |30-MAR-12 | |----------+---------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |15.1MR |15.1(1)MR3 |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+---------------------------+----------------------------| | |15.1(3)S2 |15.1(3)S2 | |15.1S |Cisco IOS XE devices: |Cisco IOS XE devices: Please| | |Please see Cisco IOS XE |see Cisco IOS XE Software | | |Software Availability |Availability | |----------+---------------------------+----------------------------| | |Not vulnerable |Not vulnerable | |15.1SG |Cisco IOS XE devices: |Cisco IOS XE devices: Please| | |Please see Cisco IOS XE |see Cisco IOS XE Software | | |Software Availability |Availability | |----------+---------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per |support organization per the| |15.1SNG |the instructions in |instructions in Obtaining | | |Obtaining Fixed Software |Fixed Software section of | | |section of this advisory. |this advisory. | |----------+---------------------------+----------------------------| |15.1SNH |Not vulnerable |Not vulnerable | |----------+---------------------------+----------------------------| | |15.1(1)T4 | | |15.1T |15.1(2)T5; Available on |15.1(3)T3 | | |27-APR-12 | | | |15.1(3)T3 | | |----------+---------------------------+----------------------------| |15.1XB |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.1T |Release 15.1T | |----------+---------------------------+----------------------------| | Affected | |First Fixed Release for All | |15.2-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |----------+---------------------------+----------------------------| |15.2GC |15.2(1)GC1 |15.2(1)GC2 | |----------+---------------------------+----------------------------| | |Not vulnerable |15.2(1)S1 | | |Cisco IOS XE devices: |Cisco IOS XE devices: Please| |15.2S |Please see Cisco IOS XE |see Cisco IOS XE Software | | |Software Availability |Availability | | | | | |----------+---------------------------+----------------------------| | |15.2(1)T2 |15.2(1)T2 | |15.2T |15.2(2)T |15.2(2)T1 | | |15.2(2)T1 |15.2(3)T; Available on | | | |30-MAR-12 | +-------------------------------------------------------------------+ * Cisco Catalyst 3550 Series Switches support the Internet Key Exchange (IKE) feature and are vulnerable to Cisco bug ID CSCts38429 when the devices are running Layer 3 images; however, this product reached the End of Software Maintenance milestone. Cisco 3550 Series SMI Switches that are running Layer 2 images do not support IKE and are not vulnerable. No other Cisco devices that run 12.2SE-based software are vulnerable. Cisco IOS XE Software +-------------------- Cisco IOS XE Software is affected by the vulnerability that is disclosed in this document. +---------------------------------------+ | | | First Fixed | | | | Release for | | | | All | | Cisco | | Advisories | | IOS XE | First Fixed | in the March | | Software | Release | 2012 Cisco | | Release | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |----------+-------------+--------------| | | | Vulnerable; | | 2.1.x | Not | migrate to | | | vulnerable | 3.4.2S or | | | | later. | |----------+-------------+--------------| | | | Vulnerable; | | 2.2.x | Not | migrate to | | | vulnerable | 3.4.2S or | | | | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 2.3.x | migrate to | migrate to | | | 3.4.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 2.4.x | migrate to | migrate to | | | 3.4.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 2.5.x | migrate to | migrate to | | | 3.4.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 2.6.x | migrate to | migrate to | | | 3.4.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 3.1.xS | migrate to | migrate to | | | 3.4.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | | | Vulnerable; | | 3.2.xSG | Not | migrate to | | | Vulnerable | 3.2.2SG or | | | | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 3.2.xS | migrate to | migrate to | | | 3.4.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | 3.2.xSG | Not | 3.2.2SG | | | Vulnerable | | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 3.3.xS | migrate to | migrate to | | | 3.4.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | 3.3.xSG | Not | Not | | | Vulnerable | Vulnerable | |----------+-------------+--------------| | 3.4.xS | 3.4.2S | 3.4.2S | |----------+-------------+--------------| | 3.5.xS | Not | 3.5.1S | | | vulnerable | | |----------+-------------+--------------| | 3.6.xS | Not | Not | | | vulnerable | vulnerable | +---------------------------------------+ For a mapping of Cisco IOS XE Software releases to Cisco IOS Software releases, refer to Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and Cisco IOS XE 3SG Release Notes. Cisco IOS XR Software +-------------------- Cisco IOS XR Software is not affected by any of the vulnerabilities disclosed in the March 2012 Cisco IOS Software Security Advisory Bundled Publication. Workarounds =========== If disabling the IOS SSH Server is not feasible, the following workarounds may be useful to some customers in their environments. SSH version 1 +------------ This vulnerability only affects SSHv2, so it can be temporarily mitigated by applying the ip ssh version 1 global configuration command until a software update can be completed. Customers should be aware of the limitations and vulnerabilities of SSH version 1 protocol before applying this workaround. vty Access Class +--------------- It is possible to limit the exposure of the Cisco device by applying a vty access class to allow only known, trusted hosts to connect to the device via SSH. For more information on restricting traffic to a vty, please consult: http://www.cisco.com/en/US/docs/ios/12_2/ipaddr/command/reference/1rfip1.html#wp1017389 The following example permits access to the vty lines from the 192.168.1.0/24 netblock and the single IP address 172.16.1.2 while denying access from anywhere else: Router(config)# access-list 1 permit 192.168.1.0 0.0.0.255 Router(config)# access-list 1 permit host 172.16.1.2 Router(config)# line vty 0 4 Router(config-line)# access-class 1 in Different Cisco platforms support a different amount of terminal lines. Check your device's configuration to determine the correct number of terminal lines for your platform. Infrastructure Access Control Lists +---------------------------------- Although it is often difficult to block traffic transiting your network, it is possible to identify traffic that should never be allowed to target your infrastructure devices and block that traffic at the border of your network. Infrastructure access control lists (iACLs) are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The ACL example shown below should be included as part of the deployed infrastructure access-list, which will protect all devices with IP addresses in the infrastructure IP address range. A sample access list for devices running Cisco IOS is below: !--- Permit SSH services from trusted hosts destined !--- to infrastructure addresses. access-list 150 permit tcp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK eq 22 !--- Deny SSH packets from all other sources destined to infrastructure addresses. access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES MASK eq 22 !--- Permit all other traffic to transit the device. access-list 150 permit IP any any interface serial 2/0 ip access-group 150 in The white paper titled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper is located at: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Control Plane Policing +--------------------- The Control Plane Policing (CoPP) feature may be used to mitigate these vulnerabilities. In the following example, only SSH traffic from trusted hosts with receive destination IP addresses is permitted to reach the route processor (RP). Note: Dropping traffic from unknown or untrusted IP addresses may affect hosts with dynamically assigned IP addresses from connecting to the Cisco IOS device. access-list 152 deny tcp TRUSTED_ADDRESSES MASK any eq 22 access-list 152 permit tcp any any eq 22 ! class-map match-all COPP-KNOWN-UNDESIRABLE match access-group 152 ! ! policy-map COPP-INPUT-POLICY class COPP-KNOWN-UNDESIRABLE drop ! control-plane service-policy input COPP-INPUT-POLICY In the above CoPP example, the ACL entries that match the exploit packets with the permit action result in these packets being discarded by the policy-map drop function, while packets that match the deny action are not affected by the policy-map drop function. Additional information on the configuration and use of the CoPP feature can be found at the following URL: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html Obtaining Fixed Software ======================== Cisco has released free software updates that address the vulnerability described in this advisory. Prior to deploying software, customers are advised to consult their maintenance providers or check the software for feature set compatibility and known issues that are specific to their environments. Customers may only install and expect support for feature sets they have purchased. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as set forth at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, upgrades should be obtained through the Software Center on Cisco.com at: http://www.cisco.com Customers Using Third-Party Support Organizations +------------------------------------------------ Customers with Cisco products that are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers, should contact that organization for assistance with the appropriate course of action. The effectiveness of any workaround or fix depends on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Because of the variety of affected products and releases, customers should consult their service providers or support organizations to ensure that any applied workaround or fix is the most appropriate in the intended network before it is deployed. Customers Without Service Contracts +---------------------------------- Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC): * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade. Customers without service contracts should request free upgrades through the TAC. Refer to Cisco Worldwide Contacts at: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, instructions, and e-mail addresses for support in various languages. Exploitation and Public Announcements ===================================== The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory. This vulnerability was reported to Cisco by a customer. Status of This Notice: Final +--------------------------- THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco Security Intelligence Operations at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-ssh Additionally, a text version of this advisory is clear signed with the Cisco PSIRT PGP key and circulated among the following e-mail addresses: * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk Future updates of this advisory, if any, will reside on Cisco.com but may not be announced on mailing lists. Users can monitor this advisory's URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2012-March-28 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information about reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco is available on Cisco.com at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This web page includes instructions for press inquiries regarding Cisco Security Advisories. All Cisco Security Advisories are available at: http://www.cisco.com/go/psirt +-------------------------------------------------------------------- Copyright 2010-2012 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAk9zNG4ACgkQQXnnBKKRMNA2VAD/eHjS4OiLcpv5x5OOjIvHSWuC kJ7DDF+wNTvEJQWX44cA/25zYBDJKshRjHuMIzTALkM0ML4n3PNHiDMaQbphXteJ =jhc2 -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 28 11:20:57 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 28 Mar 2012 12:20:57 -0400 Subject: Cisco Security Advisory: Cisco IOS Internet Key Exchange Vulnerability Message-ID: <201203281220068.cisco-sa-20120328-ike@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco IOS Internet Key Exchange Vulnerability Advisory ID: cisco-sa-20120328-ike Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) +-------------------------------------------------------------------- Summary ======= The Cisco IOS Software Internet Key Exchange (IKE) feature contains a denial of service (DoS) vulnerability. Cisco has released free software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-ike Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar12.html Affected Products ================= Vulnerable Products +------------------ Cisco devices that are running Cisco IOS Software are vulnerable when they are configured to use IKE version 1 (IKEv1). A number of features use IKEv1, including different Virtual Private Networks (VPN) such as: * LAN-to-LAN VPN * Remote access VPN (excluding SSLVPN) * Dynamic Multipoint VPN (DMVPN) * Group Domain of Interpretation (GDOI) There are two methods to determine if a device is configured for IKE: * Determine if IKE ports are open on a running device * Determine if IKE features are included in the device configuration Determine if IKE Ports are Open on a Running Device +-------------------------------------------------- The preferred method to determine if a device has been configured for IKE is to issue the "show ip sockets" or "show udp" exec command. If the device has UDP port 500, UDP port 4500, UDP port 848, or UDP port 4848 open, it is processing IKE packets. In the following example, the device is processing IKE packets in UDP port 500 and UDP port 4500, using either IPv4 or IPv6: router# show udp Proto Remote Port Local Port In Out Stat TTY OutputIF 17 --listen-- 192.168.130.21 500 0 0 1001011 0 17(v6) --listen-- UNKNOWN 500 0 0 1020011 0 17 --listen-- 192.168.130.21 4500 0 0 1001011 0 17(v6) --listen-- UNKNOWN 4500 0 0 1020011 0 !--- Output truncated router# Determine if IKE Features are included in the Device Configuration +----------------------------------------------------------------- To determine if a Cisco IOS device configuration is vulnerable, the administrator needs to establish whether there is at least one configured feature that uses IKE. This can be achieved by using the "show run | include crypto map|tunnel protection ipsec|crypto gdoi" enable mode command. If the output of this command contains either crypto map, tunnel protection ipsec, or, crypto gdoi then the device contains an IKE configuration. The following example shows a device that has been configured for IKE: router# show run | include crypto map|tunnel protection ipsec|crypto gdoi crypto map CM 100 ipsec-isakmp crypto map CM router# Determine the Cisco IOS Software Release +--------------------------------------- To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.0(1)M1 with an installed image name of C3900-UNIVERSALK9-M: Router> show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS and NX-OS Software Reference Guide" at: http://www.cisco.com/web/about/security/intelligence/ios-ref.html Products Confirmed Not Vulnerable +-------------------------------- Cisco ASA 5500 Series Adaptive Security Appliance is not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= The IKE protocol is used in the Internet Protocol Security (IPsec) protocol suite to negotiate cryptographic attributes that will be used to encrypt or authenticate the communication session. These attributes include cryptographic algorithm, mode, and shared keys. The end result of IKE is a shared session secret that will be used to derive cryptographic keys. Cisco IOS Software supports IKE for IPv4 and IPv6 communications. IKE communication can use any of the following UDP ports: * UDP port 500 * UDP port 4500, NAT Traversal (NAT-T) * UDP port 848, Group Domain of Interpretation (GDOI) * UDP port 4848, GDOI NAT-T The IKEv1 feature of Cisco IOS Software contains a vulnerability that could allow an unauthenticated, remote attacker to cause a reload of an affected device. An attacker could exploit this vulnerability using either IPv4 or IPv6 on any of the listed UDP ports. Spoofing of packets that could exploit this vulnerability is limited because the attacker needs to either receive or have access to the initial response from the vulnerable device. This vulnerability is documented in Cisco bug ID CSCts38429 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2012-0381. Vulnerability Scoring Details ============================= Cisco has scored the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this security advisory is in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps organizations determine the urgency and priority of a response. Cisco has provided a base and temporal score. Customers can also compute environmental scores that help determine the impact of the vulnerability in their own networks. Cisco has provided additional information regarding CVSS at the following link: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to compute the environmental impact for individual networks at the following link: http://intellishield.cisco.com/security/alertmanager/cvss * CSCts38429 ("Cisco IOS Software IKE DoS vulnerability") CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may cause the vulnerable device to reload. Software Versions and Fixes =========================== Cisco IOS Software +----------------- Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release column. The First Fixed Release for All Advisories in the March 2012 Bundled Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. The Cisco IOS Software Checker allows customers to search for Cisco Security Advisories that address specific Cisco IOS Software releases. This tool is available on the Cisco Security Intelligence Operations (SIO) portal at: http://tools.cisco.com/security/center/selectIOSVersion.x +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |----------+--------------------------------------------------------| | | |First Fixed Release for All| | Affected | | Advisories in the March | |12.0-Based| First Fixed Release | 2012 Cisco IOS Software | | Releases | | Security Advisory Bundled | | | | Publication | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | | |First Fixed Release for All| | Affected | | Advisories in the March | |12.2-Based| First Fixed Release | 2012 Cisco IOS Software | | Releases | | Security Advisory Bundled | | | | Publication | |----------+----------------------------+---------------------------| |12.2 |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; First fixed in | | | |Release 15.0M |Vulnerable; First fixed in | |12.2B |Releases up to and including|Release 15.0M | | |12.2(2)B7 are not | | | |vulnerable. | | |----------+----------------------------+---------------------------| | |Vulnerable; First fixed in | | | |Release 15.0M |Vulnerable; First fixed in | |12.2BC |Releases up to and including|Release 15.0M | | |12.2(4)BC1b are not | | | |vulnerable. | | |----------+----------------------------+---------------------------| |12.2BW |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; First fixed in | | | |Release 12.2SRE |Vulnerable; First fixed in | |12.2BX |Releases up to and including|Release 12.2SB | | |12.2(2)BX1 are not | | | |vulnerable. | | |----------+----------------------------+---------------------------| | |Vulnerable; First fixed in | | | |Release 15.0M |Vulnerable; First fixed in | |12.2BY |Releases up to and including|Release 15.0M | | |12.2(2)BY3 are not | | | |vulnerable. | | |----------+----------------------------+---------------------------| | |Vulnerable; First fixed in | | | |Release 15.0M |Vulnerable; First fixed in | |12.2BZ |Releases up to and including|Release 15.0M | | |12.2(4)BZ2 are not | | | |vulnerable. | | |----------+----------------------------+---------------------------| |12.2CX |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2CY |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2CZ |Vulnerable; migrate to any |Vulnerable; First fixed in | | |release in 12.0S |Release 12.0S | |----------+----------------------------+---------------------------| |12.2DA |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| |12.2DD |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2DX |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2EU |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2EW |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2EWA |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| |12.2EX |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2EY |Not vulnerable |12.2(52)EY4 | |----------+----------------------------+---------------------------| |12.2EZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2FX |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2FY |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2FZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2IRA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SRD |Release 12.2SRE | |----------+----------------------------+---------------------------| |12.2IRB |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SRD |Release 12.2SRE | |----------+----------------------------+---------------------------| |12.2IRC |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SRD |Release 12.2SRE | |----------+----------------------------+---------------------------| |12.2IRD |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SRD |Release 12.2SRE | |----------+----------------------------+---------------------------| |12.2IRE |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SRD |Release 12.2SRE | |----------+----------------------------+---------------------------| |12.2IRF |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SRD |Release 12.2SRE | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2IRG |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2IRH |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2IXA |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2IXB |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2IXC |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2IXD |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2IXE |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2IXF |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2IXG |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2IXH |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.2JA |Not vulnerable |Not vulnerable | |----------+----------------------------+---------------------------| |12.2JK |Not vulnerable |Not vulnerable | |----------+----------------------------+---------------------------| |12.2MB |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| |12.2MC |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| |12.2MRA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SRD |Release 12.2SRE | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2MRB |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Note: Releases prior to 12.2|Releases prior to 12.2(30)S| | |(25)S1 are vulnerable; |are vulnerable; Releases | |12.2S |Releases 12.2(25)S1 and |12.2(30)S and later are not| | |later are not vulnerable. |vulnerable. First fixed in | | | |Release 12.0S | |----------+----------------------------+---------------------------| | |Only releases 12.2(33)SB1 | | |12.2SB |through 12.2(33)SB4 are |12.2(33)SB12 | | |vulnerable. | | |----------+----------------------------+---------------------------| |12.2SBC |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+----------------------------+---------------------------| |12.2SCA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SCE |Release 12.2SCE | |----------+----------------------------+---------------------------| |12.2SCB |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SCE |Release 12.2SCE | |----------+----------------------------+---------------------------| |12.2SCC |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SCE |Release 12.2SCE | |----------+----------------------------+---------------------------| |12.2SCD |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SCE |Release 12.2SCE | |----------+----------------------------+---------------------------| |12.2SCE |12.2(33)SCE6 |12.2(33)SCE6 | |----------+----------------------------+---------------------------| |12.2SCF |12.2(33)SCF2 |12.2(33)SCF2 | |----------+----------------------------+---------------------------| |12.2SE |Not vulnerable* | | | | |12.2(55)SE5 * | |----------+----------------------------+---------------------------| |12.2SEA |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2SEB |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2SEC |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2SED |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2SEE |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2SEF |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2SEG |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0SE | |----------+----------------------------+---------------------------| |12.2SG |Not vulnerable |12.2(53)SG7; Available on | | | |07-MAY-12 | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2SGA |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| |12.2SL |Not vulnerable |Not vulnerable | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2SM |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2SO |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2SQ |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| |12.2SRA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SRD |Release 12.2SRE | |----------+----------------------------+---------------------------| |12.2SRB |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SRD |Release 12.2SRE | |----------+----------------------------+---------------------------| |12.2SRC |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SRD |Release 12.2SRE | |----------+----------------------------+---------------------------| |12.2SRD |12.2(33)SRD8 |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+----------------------------+---------------------------| |12.2SRE |12.2(33)SRE6 |12.2(33)SRE6 | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2STE |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| |12.2SU |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | | |Releases up to and | |12.2SV |Not vulnerable |including 12.2(18)SV2 are | | | |not vulnerable. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2SVA |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2SVC |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2SVD |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2SVE |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | |Releases up to and including| | | |12.2(21)SW1 are not | | |12.2SW |vulnerable. |Vulnerable; First fixed in | | |Releases 12.2(25)SW10 and |Release 12.4T | | |later are not vulnerable. | | | |First fixed in Release 12.4T| | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2SX |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2SXA |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2SXB |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2SXD |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2SXE |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2SXF |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2SXH |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.2SXI |12.2(33)SXI9 |12.2(33)SXI9 | |----------+----------------------------+---------------------------| |12.2SXJ |12.2(33)SXJ2 |12.2(33)SXJ2 | |----------+----------------------------+---------------------------| |12.2SY |12.2(50)SY2; Available on |12.2(50)SY2; Available on | | |11-JUN-12 |11-JUN-12 | |----------+----------------------------+---------------------------| |12.2SZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.0S | |----------+----------------------------+---------------------------| |12.2T |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2TPC |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.2XA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XB |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XC |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XD |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XE |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XF |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XG |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XH |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XI |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XJ |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XK |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XL |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XM |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XNA |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+----------------------------+---------------------------| |12.2XNB |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+----------------------------+---------------------------| |12.2XNC |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+----------------------------+---------------------------| |12.2XND |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+----------------------------+---------------------------| |12.2XNE |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+----------------------------+---------------------------| |12.2XNF |Please see Cisco IOS-XE |Please see Cisco IOS-XE | | |Software Availability |Software Availability | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2XO |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| |12.2XQ |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | | |Releases prior to 12.2(15) | | | |XR are vulnerable; Releases| |12.2XR |Not vulnerable |12.2(15)XR and later are | | | |not vulnerable. First fixed| | | |in Release 15.0M | |----------+----------------------------+---------------------------| |12.2XS |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XT |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XU |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XV |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2XW |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2YA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2YC |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2YD |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2YE |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2YK |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2YO |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; First fixed in | | | |Release 15.0M | |12.2YP |Not vulnerable |Releases up to and | | | |including 12.2(8)YP are not| | | |vulnerable. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2YT |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2YW |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2YX |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2YY |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2YZ |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2ZA |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | |Releases up to and including|support organization per | |12.2ZB |12.2(8)ZB are not |the instructions in | | |vulnerable. |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2ZC |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2ZD |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.2ZE |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.2ZH |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2ZJ |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.2ZP |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2ZU |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.2ZX |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.2SRE | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2ZY |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.2ZYA |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | | |First Fixed Release for All| | Affected | | Advisories in the March | |12.3-Based| First Fixed Release | 2012 Cisco IOS Software | | Releases | | Security Advisory Bundled | | | | Publication | |----------+----------------------------+---------------------------| |12.3 |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.3B |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.3BC |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SCE |Release 12.2SCE | |----------+----------------------------+---------------------------| |12.3BW |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| |12.3JA |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4JA | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.3JEA |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.3JEB |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.3JEC |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.3JED |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Releases up to and including| | | |12.3(2)JK3 are not | | |12.3JK |vulnerable. |Vulnerable; First fixed in | | |Releases 12.3(8)JK1 and |Release 15.0M | | |later are not vulnerable. | | | |First fixed in Release 15.0M| | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.3JL |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| |12.3JX |Not vulnerable |Not vulnerable | |----------+----------------------------+---------------------------| |12.3T |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.3TPC |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.3VA |Not vulnerable |Not vulnerable | |----------+----------------------------+---------------------------| |12.3XA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.3XB |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.3XC |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.3XD |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.3XE |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.3XF |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.3XG |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.3XI |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.2SRE |Release 12.2SRE | |----------+----------------------------+---------------------------| |12.3XJ |Vulnerable; migrate to any |Vulnerable; First fixed in | | |release in 12.4XN |Release 15.0M | |----------+----------------------------+---------------------------| |12.3XK |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.3XL |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.3XQ |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.3XR |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; First fixed in | | | |Release 12.4T |Vulnerable; First fixed in | |12.3XU |Releases up to and including|Release 12.4T | | |12.3(8)XU1 are not | | | |vulnerable. | | |----------+----------------------------+---------------------------| |12.3XW |Vulnerable; migrate to any |Vulnerable; First fixed in | | |release in 12.4XN |Release 15.0M | |----------+----------------------------+---------------------------| |12.3XX |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| |12.3XY |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| |12.3XZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YD |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YF |Vulnerable; migrate to any |Vulnerable; First fixed in | | |release in 12.4XN |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YG |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YI |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YJ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YK |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YM |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YQ |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YS |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YT |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YU |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.3YX |Vulnerable; migrate to any |Vulnerable; First fixed in | | |release in 12.4XN |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.3YZ |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.3ZA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| | | |First Fixed Release for All| | Affected | | Advisories in the March | |12.4-Based| First Fixed Release | 2012 Cisco IOS Software | | Releases | | Security Advisory Bundled | | | | Publication | |----------+----------------------------+---------------------------| |12.4 |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.0M |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.4GC |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.4JA |Not vulnerable |12.4(23c)JA4 | | | |12.4(25e)JA | |----------+----------------------------+---------------------------| |12.4JAX |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4JA | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.4JDA |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.4JDC |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.4JDD |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.4JDE |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.4JHA |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.4JHB |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.4JHC |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.4JK |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.4JL |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| |12.4JX |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4JA | |----------+----------------------------+---------------------------| |12.4JY |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4JA | |----------+----------------------------+---------------------------| |12.4JZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4JA | |----------+----------------------------+---------------------------| |12.4MD |12.4(22)MD3; Available on |12.4(22)MD3; Available on | | |30-MAR-12 |30-MAR-12 | |----------+----------------------------+---------------------------| |12.4MDA |12.4(24)MDA11 |12.4(24)MDA11 | |----------+----------------------------+---------------------------| |12.4MDB |12.4(24)MDB5a |12.4(24)MDB5a | |----------+----------------------------+---------------------------| |12.4MDC |Not vulnerable |Not vulnerable | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | |Releases up to and including|support organization per | |12.4MR |12.4(9)MR are not |the instructions in | | |vulnerable. |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.4MRA |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.4MRB |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.4SW |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| | |12.4(15)T17 |12.4(15)T17 | |12.4T |12.4(24)T7 |12.4(24)T7 | | | | | |----------+----------------------------+---------------------------| |12.4XA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| | |Releases prior to 12.4(2) | | | |XB12 are vulnerable; |Vulnerable; First fixed in | |12.4XB |Releases 12.4(2)XB12 and |Release 12.4T | | |later are not vulnerable. | | | |First fixed in Release 12.4T| | |----------+----------------------------+---------------------------| |12.4XC |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.4XD |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.4XE |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.4XF |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.4XG |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| |12.4XJ |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.4XK |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.4XL |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| |12.4XM |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+----------------------------+---------------------------| | | |Vulnerable; contact your | | | |support organization per | |12.4XN |Not vulnerable |the instructions in | | | |Obtaining Fixed Software | | | |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.4XP |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.4XQ |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.4XR |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 12.4T | |----------+----------------------------+---------------------------| |12.4XT |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.4XV |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.4XW |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.4XY |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.4XZ |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| |12.4YA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 12.4T |Release 15.0M | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.4YB |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |12.4YD |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |12.4YE |12.4(24)YE3d |12.4(24)YE3d | |----------+----------------------------+---------------------------| |12.4YG |12.4(24)YG4 |12.4(24)YG4 | |----------+----------------------------+---------------------------| | | |First Fixed Release for All| | Affected | | Advisories in the March | |15.0-Based| First Fixed Release | 2012 Cisco IOS Software | | Releases | | Security Advisory Bundled | | | | Publication | |----------+----------------------------+---------------------------| |15.0M |15.0(1)M8 |15.0(1)M8 | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |15.0MR |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |15.0MRA |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |15.0(1)S5 |15.0(1)S5 | |15.0S |Cisco IOS XE devices: Please|Cisco IOS XE devices: | | |see Cisco IOS XE Software |Please see Cisco IOS XE | | |Availability |Software Availability | |----------+----------------------------+---------------------------| |15.0SA |Not vulnerable |Not vulnerable | |----------+----------------------------+---------------------------| |15.0SE |Not vulnerable |15.0(1)SE1 | |----------+----------------------------+---------------------------| | |Not vulnerable |15.0(2)SG2 | |15.0SG |Cisco IOS XE devices: Please|Cisco IOS XE devices: | | |see Cisco IOS XE Software |Please see Cisco IOS XE | | |Availability |Software Availability | |----------+----------------------------+---------------------------| |15.0SY |15.0(1)SY1 |15.0(1)SY1 | |----------+----------------------------+---------------------------| |15.0XA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.1T |Release 15.1T | |----------+----------------------------+---------------------------| | |Cisco IOS XE devices: Please|Cisco IOS XE devices: | |15.0XO |see Cisco IOS-XE Software |Please see Cisco IOS-XE | | |Availability |Software Availability | |----------+----------------------------+---------------------------| | | |First Fixed Release for All| | Affected | | Advisories in the March | |15.1-Based| First Fixed Release | 2012 Cisco IOS Software | | Releases | | Security Advisory Bundled | | | | Publication | |----------+----------------------------+---------------------------| |15.1EY |Not vulnerable |15.1(2)EY2 | |----------+----------------------------+---------------------------| |15.1GC |15.1(2)GC2 |15.1(2)GC2 | |----------+----------------------------+---------------------------| |15.1M |15.1(4)M3 |15.1(4)M4; Available on | | | |30-MAR-12 | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |15.1MR |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| | |15.1(3)S2 |15.1(3)S2 | |15.1S |Cisco IOS XE devices: Please|Cisco IOS XE devices: | | |see Cisco IOS XE Software |Please see Cisco IOS XE | | |Availability |Software Availability | |----------+----------------------------+---------------------------| | |Not vulnerable |Not vulnerable | |15.1SG |Cisco IOS XE devices: Please|Cisco IOS XE devices: | | |see Cisco IOS XE Software |Please see Cisco IOS XE | | |Availability |Software Availability | |----------+----------------------------+---------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per | |15.1SNG |instructions in Obtaining |the instructions in | | |Fixed Software section of |Obtaining Fixed Software | | |this advisory. |section of this advisory. | |----------+----------------------------+---------------------------| |15.1SNH |Not vulnerable |Not vulnerable | |----------+----------------------------+---------------------------| | |15.1(1)T5; Available on | | | |18-MAY-12 | | |15.1T |15.1(2)T5; Available on |15.1(3)T3 | | |27-APR-12 | | | |15.1(3)T3 | | |----------+----------------------------+---------------------------| |15.1XB |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.1T |Release 15.1T | |----------+----------------------------+---------------------------| | | |First Fixed Release for All| | Affected | | Advisories in the March | |15.2-Based| First Fixed Release | 2012 Cisco IOS Software | | Releases | | Security Advisory Bundled | | | | Publication | |----------+----------------------------+---------------------------| |15.2GC |15.2(1)GC2 |15.2(1)GC2 | |----------+----------------------------+---------------------------| | |15.2(1)S1 |15.2(1)S1 | | | | | |15.2S |Cisco IOS XE devices: Please|Cisco IOS XE devices: | | |see Cisco IOS XE Software |Please see Cisco IOS XE | | |Availability |Software Availability | |----------+----------------------------+---------------------------| | |15.2(1)T2 |15.2(1)T2 | |15.2T |15.2(2)T1 |15.2(2)T1 | | |15.2(3)T; Available on |15.2(3)T; Available on | | |30-MAR-12 |30-MAR-12 | +-------------------------------------------------------------------+ * Cisco Catalyst 3550 Series Switches support the Internet Key Exchange (IKE) feature and are vulnerable to Cisco bug ID CSCts38429 when the devices are running Layer 3 images; however, this product reached the End of Software Maintenance milestone. Cisco 3550 Series SMI Switches that are running Layer 2 images do not support IKE and are not vulnerable. No other Cisco devices that run 12.2SE-based software are vulnerable. Cisco IOS XE Software +-------------------- +------------------------------------------------------------+ | Cisco IOS | | First Fixed Release for All | | XE | First Fixed | Advisories in the March 2012 | | Software | Release | Cisco IOS Software Security | | Release | | Advisory Bundled Publication | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.1.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.2S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.2.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.2S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.3.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.2S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.4.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.2S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.5.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.2S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.6.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.2S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 3.1.xS | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.2S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | 3.1.xSG | Not | Vulnerable; migrate to 3.2.2SG | | | vulnerable | or later. | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 3.2.xS | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.2S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | 3.2.xSG | 3.2.2SG | 3.2.2SG | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 3.3.xS | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.2S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | 3.3.xSG | Not | Not Vulnerable | | | Vulnerable | | |-----------+--------------+---------------------------------| | 3.4.xS | 3.4.2S | 3.4.2S | |-----------+--------------+---------------------------------| | 3.5.xS | 3.5.1S | 3.5.1S | |-----------+--------------+---------------------------------| | 3.6.xS | Not | Not vulnerable | | | vulnerable | | +------------------------------------------------------------+ For a mapping of Cisco IOS XE Software releases to Cisco IOS Software releases, refer to Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and Cisco IOS XE 3SG Release Notes. Cisco IOS XR Software +-------------------- Cisco IOS XR Software is not affected by any of the vulnerabilities disclosed in the March 2012 Cisco IOS Software Security Advisory Bundled Publication. Workarounds =========== There are no workarounds for this vulnerability. Obtaining Fixed Software ======================== Cisco has released free software updates that address the vulnerability described in this advisory. Prior to deploying software, customers are advised to consult their maintenance providers or check the software for feature set compatibility and known issues that are specific to their environments. Customers may only install and expect support for feature sets they have purchased. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as set forth at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, upgrades should be obtained through the Software Center on Cisco.com at http://www.cisco.com. Customers Using Third-Party Support Organizations +------------------------------------------------ Customers with Cisco products that are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers, should contact that organization for assistance with the appropriate course of action. The effectiveness of any workaround or fix depends on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Because of the variety of affected products and releases, customers should consult their service providers or support organizations to ensure that any applied workaround or fix is the most appropriate in the intended network before it is deployed. Customers Without Service Contracts +---------------------------------- Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC): * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade. Customers without service contracts should request free upgrades through the TAC. Refer to Cisco Worldwide Contacts at http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, instructions, and e-mail addresses for support in various languages. Exploitation and Public Announcements ===================================== The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory. This vulnerability was found during internal Cisco testing. Status of This Notice: Final ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco Security Intelligence Operations at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-ike Additionally, a text version of this advisory is clear signed with the Cisco PSIRT PGP key and circulated among the following e-mail addresses: * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk Future updates of this advisory, if any, will reside on Cisco.com but may not be announced on mailing lists. Users can monitor this advisory's URL for any updates. Revision History ================ +------------------------------------------------------------+ | Revision 1.0 | 2012-March-28 | Initial public release. | +------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information about reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco is available on Cisco.com at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This web page includes instructions for press inquiries regarding Cisco Security Advisories. All Cisco Security Advisories are available at http://www.cisco.com/go/psirt. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EAREIAAYFAk9xNMgACgkQQXnnBKKRMND8jwD6AzE8IxsF7PzqGh9w75+OhEQ7 z3dm7J1xzgPKLxtI7R8A/1AXDWCmSXsfNHJjhTPmMeZ5kxiA+9AfvxkWJLWxDMZ2 =sT/L -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 28 11:20:57 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 28 Mar 2012 12:20:57 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Zone-Based Firewall Vulnerabilities Message-ID: <201203281220068.cisco-sa-20120328-zbfw@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco IOS Software Zone-Based Firewall Vulnerabilities Advisory ID: cisco-sa-20120328-zbfw Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software contains four vulnerabilities related to Cisco IOS Zone-Based Firewall features. These vulnerabilities are as follows: * Memory Leak Associated with Crafted IP Packets * Memory Leak in HTTP Inspection * Memory Leak in H.323 Inspection * Memory Leak in SIP Inspection Workarounds that mitigate these vulnerabilities are not available. Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-zbfw Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar12.html Affected Products ================= Vulnerable Products +------------------ Cisco IOS devices running vulnerable versions of Cisco IOS Software are affected by four vulnerabilities in the Cisco IOS Zone-Based Firewall. The vulnerabilities are independent of each other. Details to confirm affected configurations are provided below. To determine whether a device is configured with Zone-Based Firewall, log in to the device and issue the show zone security command-line interface (CLI) command. If the output shows a member interface under a zone name, the device is vulnerable. The following example shows a device with Zone-Based Firewall rules configured on both GigabitEthernet0/0 and GigabitEthernet0/1: Router#show zone security zone self Description: System defined zone zone inside Description: *** Inside Network *** Member Interfaces: GigabitEthernet0/0 zone outside Description: *** Outside Network *** Member Interfaces: GigabitEthernet0/1 Router# The following sections provide more details on the specific features containing the vulnerabilities. Memory Leak Associated with Crafted IP Packets +--------------------------------------------- There is no specific configuration necessary for a device to be vulnerable to the memory leak associated with crafted IP packets. If the Zone-Based Firewall is configured, the device is vulnerable. Memory Leak in HTTP Inspection +----------------------------- For the device to be vulnerable to the memory leak associated with HTTP inspection, the Zone-Based Firewall must be configured to perform HTTP inspection with the Zone-Based Firewall. To determine whether a device is configured for HTTP inspection, enter the command show policy-map type inspect zone-pair | include Match: protocol http. The following example shows a vulnerable device configured with Cisco IOS Zone-Based Policy Firewall HTTP inspection: Router#show policy-map type inspect zone-pair | include Match: protocol http Match: protocol http Memory Leak in H.323 Inspection +------------------------------ For a device to be vulnerable to the memory leak associated with H.323 inspection, the Zone-Based Firewall must be configured to perform H.323 inspection. To determine if a device is configured for H.323 inspection enter the command show policy-map type inspect zone-pair | include Match: protocol h323. If the output contains "Match: protocol h323" the device is vulnerable. The following example shows a vulnerable device configured with Cisco IOS Zone-Based Policy Firewall H.323 inspection: Router# show policy-map type inspect zone-pair | include Match: protocol h323 Match: protocol h323 Memory Leak in SIP Inspection +---------------------------- The device is vulnerable if the configuration has either a Layer 4 or Layer 7 Session Initiation Protocol (SIP) application-specific policy configured, and the policy is applied to any firewall zone. To determine whether a device is configured for SIP inspection enter the command show policy-map type inspect zone-pair | include Match: protocol sip. If the output contains "Match: protocol sip" the device is vulnerable. The following example shows a vulnerable device configured with Cisco IOS Zone-Based Policy Firewall SIP inspection: Router# show policy-map type inspect zone-pair | include Match: protocol sip Match: protocol sip To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.0(1)M1 with an installed image name of C3900-UNIVERSALK9-M: Router> show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS and NX-OS Software Reference Guide" at http://www.cisco.com/web/about/security/ intelligence/ios-ref.html. Products Confirmed Not Vulnerable +-------------------------------- The following products are confirmed not vulnerable: * Cisco PIX 500 Series Firewall * Cisco ASA 5500 Series Adaptive Security Appliance * Firewall Services Module (FWSM) for Catalyst 6500 Series Switches and 7600 Series Routers * Virtual Firewall (VFW) application on the multiservice blade (MSB) on the Cisco XR 12000 Series Router * Cisco ACE Application Control Engine Module * Cisco IOS devices configured with legacy Cisco IOS Firewall support * Cisco IOS XR Software * Cisco IOS XE Software * Cisco Catalyst 6500 Series ASA Services Module * Context-Based Access Control (CBAC) No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= Firewalls are networking devices that control access to the network assets of an organization. Firewalls are often positioned at the entrance points of networks. Cisco IOS Software provides a set of security features that allow the configuration of a firewall policy to match an organization's requirements. The vulnerabilities described in this advisory affect the Zone-Based Firewall feature. The Zone-Based Policy Firewall (also known as Zone-Policy Firewall or ZFW) updates the firewall configuration from the older interface-based model to a more flexible, more easily understood zone-based model. Interfaces are assigned to zones, and inspection policy is applied to traffic moving between the zones. Inter-zone policies offer considerable flexibility and granularity, so different inspection policies can be applied to multiple host groups connected to the same router interface. More information on the Zone-Based Firewall is available at: http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a008060f6dd.html Memory Leak Associated with Crafted IP Packets +--------------------------------------------- A vulnerability exists in the Zone-Based Firewall implementation in Cisco IOS Software that could allow a remote attacker to cause an affected device to reload or to trigger memory leaks that may result in system instabilities. These vulnerabilities are triggered when the device that is running Cisco IOS Software processes crafted IP packets. Only traffic destined to an IP address configured on the device can trigger the vulnerability; transit traffic is not an exploit vector. This vulnerability is documented in Cisco bug ID CSCto89536 and has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2012-1310. Memory Leak in HTTP Inspection +--------------------------------------------- The HTTP Inspection Engine feature allows users to configure their Cisco IOS Firewall to detect and filter HTTP connections-such as tunneling over port 80, unauthorized request methods, and non-HTTP compliant file transfers-that are not authorized within the scope of the security policy configuration. A vulnerability exists in the implementation of the Cisco IOS Software HTTP inspection feature that could allow a remote attacker to cause an affected device to reload or to trigger memory leaks that may result in system instabilities. This vulnerability is triggered when the device that is running Cisco IOS Software processes certain HTTP messages. Transit HTTP traffic is an exploit vector. This vulnerability is documented in Cisco bug ID CSCtq36153 and has been assigned CVE ID CVE-2012-0387. More information on HTTP inspection is available at: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gt_fwapc.html Memory Leak in H.323 Inspection +--------------------------------------------- H.323 is the ITU standard for real-time multimedia communications and conferencing over packet-based (IP) networks. A vulnerability exists in the implementation of the Cisco IOS Software H.323 inspection feature that could allow a remote attacker to cause an affected device to reload or to trigger memory leaks that may result in system instabilities. This vulnerability is triggered when the device that is running Cisco IOS Software processes malformed H.323 messages. Transit H.323 traffic is an exploit vector. This vulnerability is documented in Cisco bug ID CSCtq45553 and has been assigned the CVE ID CVE-2012-0388. More information on H.323 inspection is available at: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_zbf/configuration/15-2mt/fw-h323-v3v4-sup.html Memory Leak in SIP Inspection +--------------------------------------------- SIP is a popular signaling protocol that is used to manage voice and video calls across IP networks, such as the Internet. SIP is responsible for handling all aspects of call setup and termination. Voice and video are the most popular types of sessions that SIP handles, but the protocol has the flexibility to accommodate other applications that require call setup and termination. SIP call signaling can use UDP (port 5060), TCP (port 5060), or Transport Layer Security (TLS; TCP port 5061) as the underlying transport protocol. A vulnerability exists in the implementation of the Cisco IOS SIP inspection feature that could allow a remote attacker to cause an affected device to reload or to trigger memory leaks that may result in system instabilities. This vulnerability is triggered when the device that is running Cisco IOS Software processes crafted SIP messages. Transit SIP traffic is an exploit vector. This vulnerability is documented in Cisco bug ID CSCti46171 and has been assigned CVE ID CVE-2012-1315. More information on SIP inspection is available at: http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_sip_alg_aic.html Memory Leak Detection +--------------------------------------------- Detected memory leaks can be viewed using the command show memory debug leaks chunks in privileged EXEC mode, as shown in the following example: Router# show memory debug leaks chunks Adding blocks for GD... I/O memory Address Size Alloc_pc PID Alloc-Proc Name Chunk Elements: AllocPC Address Size Parent Name Processor memory Address Size Alloc_pc PID Alloc-Proc Name 4733113C 188 419CB164 129 IP Input FW h225 tpkt The previous example shows a memory leak in the process FW h225 tpkt. The show memory debug leaks command was introduced in Cisco IOS Software versions 12.3(8)T1 and 12.2(25)S. Caution: All show memory debug commands must be used on customer networks only to diagnose the router for memory leaks when memory depletion is observed. These commands may cause high CPU utilization and may cause time-sensitive protocols to flap. These commands are recommended to be used in maintenance windows. Vulnerability Scoring Details ============================= Cisco has scored the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this security advisory is in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps organizations determine the urgency and priority of a response. Cisco has provided a base and temporal score. Customers can also compute environmental scores that help determine the impact of the vulnerability in their own networks. Cisco has provided additional information regarding CVSS at the following link: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to compute the environmental impact for individual networks at the following link: http://intellishield.cisco.com/security/alertmanager/cvss * Memory Leak associated with crafted IP packets CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed * Memory Leak in HTTP inspection CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed * Memory Leak in H.323 inspection CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed * Memory Leak in SIP Inspection CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of these vulnerabilities may result in a reload of the affected device. Repeated exploit attempts may result in a sustained denial of service (DoS) attack. Software Versions and Fixes =========================== When considering software upgrades, customers are advised to consult the Cisco Security Advisories and Responses archive at: http://www.cisco.com/go/psirt and review subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should ensure that the devices to be upgraded contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers. Cisco IOS Software +----------------- Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release column. The First Fixed Release for All Advisories in the March 2012 Bundled Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. The Cisco IOS Software Checker allows customers to search for Cisco Security Advisories that address specific Cisco IOS Software releases. This tool is available on the Cisco Security Intelligence Operations (SIO) portal at: http://tools.cisco.com/security/center/selectIOSVersion.x +------------------------------------------+ | Major | Availability of | | Release | Repaired Releases | |------------+-----------------------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 12.0-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------------------------------------| | There are no affected 12.0 based | | releases | |------------------------------------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 12.2-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------------------------------------| | There are no affected 12.2 based | | releases | |------------------------------------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 12.3-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------------------------------------| | There are no affected 12.3 based | | releases | |------------------------------------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 12.4-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------+--------------+--------------| | | | Vulnerable; | | 12.4 | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4GC | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | 12.4JA | Not | 12.4(23c)JA4 | | | vulnerable | 12.4(25e)JA | |------------+--------------+--------------| | | | Vulnerable; | | 12.4JAX | Not | First fixed | | | vulnerable | in Release | | | | 12.4JA | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4JDA | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4JDC | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4JDD | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4JDE | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4JHA | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4JHB | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4JHC | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4JK | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4JL | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | 12.4JX | Not | First fixed | | | vulnerable | in Release | | | | 12.4JA | |------------+--------------+--------------| | | | Vulnerable; | | 12.4JY | Not | First fixed | | | vulnerable | in Release | | | | 12.4JA | |------------+--------------+--------------| | | | Vulnerable; | | 12.4JZ | Not | First fixed | | | vulnerable | in Release | | | | 12.4JA | |------------+--------------+--------------| | | 12.4(22)MD3; | 12.4(22)MD3; | | 12.4MD | Available on | Available on | | | 30-MAR-12 | 30-MAR-12 | |------------+--------------+--------------| | 12.4MDA | 12.4(24) | 12.4(24) | | | MDA11 | MDA11 | |------------+--------------+--------------| | 12.4MDB | 12.4(24) | 12.4(24) | | | MDB5a | MDB5a | |------------+--------------+--------------| | 12.4MDC | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | Releases up | organization | | | to and | per the | | 12.4MR | including | instructions | | | 12.4(19)MR3 | in Obtaining | | | are not | Fixed | | | vulnerable. | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4MRA | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4MRB | First fixed | First fixed | | | in Release | in Release | | | 15.0M | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.4SW | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | 12.4(24)T7 | | | | | | | | Releases up | 12.4(15)T17 | | 12.4T | to and | 12.4(24)T7 | | | including | | | | 12.4(15)T17 | | | | are not | | | | vulnerable. | | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XA | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XB | Not | First fixed | | | vulnerable | in Release | | | | 12.4T | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XC | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XD | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XE | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XF | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XG | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XJ | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XK | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4XL | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XM | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4XN | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4XP | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XQ | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | Vulnerable; | | | | First fixed | | | | in Release | | | | 12.4T | Vulnerable; | | 12.4XR | Releases up | First fixed | | | to and | in Release | | | including | 12.4T | | | 12.4(15)XR10 | | | | are not | | | | vulnerable. | | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XT | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.4XV | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XW | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.4XY | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XZ | First fixed | First fixed | | | in Release | in Release | | | 15.0M | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4YA | First fixed | First fixed | | | in Release | in Release | | | 15.0M | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4YB | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4YD | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | 12.4YE | 12.4(24)YE3d | 12.4(24)YE3d | |------------+--------------+--------------| | 12.4YG | 12.4(24)YG4 | 12.4(24)YG4 | |------------+--------------+--------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 15.0-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------+--------------+--------------| | 15.0M | 15.0(1)M8 | 15.0(1)M8 | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 15.0MR | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 15.0MRA | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | 15.0(1)S5 | | | | Cisco IOS XE | | | Not | devices: | | 15.0S | vulnerable | Please see | | | | Cisco IOS XE | | | | Software | | | | Availability | |------------+--------------+--------------| | 15.0SA | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | 15.0SE | Not | 15.0(1)SE1 | | | vulnerable | | |------------+--------------+--------------| | | | 15.0(2)SG2 | | | | Cisco IOS XE | | | Not | devices: | | 15.0SG | vulnerable | Please see | | | | Cisco IOS XE | | | | Software | | | | Availability | |------------+--------------+--------------| | 15.0SY | Not | 15.0(1)SY1 | | | vulnerable | | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 15.0XA | First fixed | First fixed | | | in Release | in Release | | | 15.1T | 15.1T | |------------+--------------+--------------| | | | Vulnerable; | | | | First fixed | | | | in Release | | | | 15.0SG Cisco | | 15.0XO | Not | IOS XE | | | vulnerable | devices: | | | | Please see | | | | Cisco IOS XE | | | | Software | | | | Availability | |------------+--------------+--------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 15.1-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------+--------------+--------------| | 15.1EY | Not | 15.1(2)EY2 | | | vulnerable | | |------------+--------------+--------------| | 15.1GC | 15.1(2)GC2 | 15.1(2)GC2 | |------------+--------------+--------------| | | 15.1(4)M3 | 15.1(4)M4; | | 15.1M | | Available on | | | | 30-MAR-12 | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 15.1MR | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | 15.1(3)S2 | | | | Cisco IOS XE | | | Not | devices: | | 15.1S | vulnerable | Please see | | | | Cisco IOS XE | | | | Software | | | | Availability | |------------+--------------+--------------| | 15.1SG | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 15.1SNG | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | 15.1SNH | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | 15.1T | 15.1(3)T3 | 15.1(3)T3 | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 15.1XB | First fixed | First fixed | | | in Release | in Release | | | 15.1T | 15.1T | |------------+--------------+--------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 15.2-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------+--------------+--------------| | 15.2GC | 15.2(1)GC2 | 15.2(1)GC2 | |------------+--------------+--------------| | | | 15.2(1)S1 | | | | Cisco IOS XE | | | | devices: | | 15.2S | Not | Please see | | | vulnerable | Cisco IOS XE | | | | Software | | | | Availability | | | | | |------------+--------------+--------------| | | | 15.2(1)T2 | | | 15.2(1)T2 | 15.2(2)T1 | | 15.2T | 15.2(2)T | 15.2(3)T; | | | 15.2(2)T1 | Available on | | | | 30-MAR-12 | +------------------------------------------+ * Cisco Catalyst 3550 Series Switches support the Internet Key Exchange (IKE) feature and are vulnerable to Cisco bug ID CSCts38429 when the devices are running Layer 3 images; however, this product reached the End of Software Maintenance milestone. Cisco 3550 Series SMI Switches that are running Layer 2 images do not support IKE and are not vulnerable. No other Cisco devices that run 12.2SE-based software are vulnerable. Cisco IOS XE Software +-------------------- Cisco IOS XE Software is not affected by the vulnerabilities that are disclosed in this document. For a mapping of Cisco IOS XE Software releases to Cisco IOS Software releases, refer to Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and Cisco IOS XE 3SG Release Notes. Cisco IOS XR Software +-------------------- Cisco IOS XR Software is not affected by any of the vulnerabilities disclosed in the March 2012 Cisco IOS Software Security Advisory Bundled Publication. Workarounds =========== There are no workarounds that mitigate the vulnerabilities described in this advisory. Obtaining Fixed Software ======================== Cisco has released free software updates that address the vulnerabilities described in this advisory. Prior to deploying software, customers are advised to consult their maintenance providers or check the software for feature set compatibility and known issues that are specific to their environments. Customers may only install and expect support for feature sets they have purchased. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as set forth at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, upgrades should be obtained through the Software Center on Cisco.com at: http://www.cisco.com Customers Using Third-Party Support Organizations +------------------------------------------------ Customers with Cisco products that are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers, should contact that organization for assistance with the appropriate course of action. The effectiveness of any workaround or fix depends on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Because of the variety of affected products and releases, customers should consult their service providers or support organizations to ensure that any applied workaround or fix is the most appropriate in the intended network before it is deployed. Customers Without Service Contracts +---------------------------------- Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC): * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade. Customers without service contracts should request free upgrades through the TAC. Refer to Cisco Worldwide Contacts at: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, instructions, and e-mail addresses for support in various languages. Exploitation and Public Announcements ===================================== The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerabilities that are described in this advisory. These vulnerabilities were discovered by Cisco during normal internal security testing. Status of This Notice: Final THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco Security Intelligence Operations at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-zbfw Additionally, a text version of this advisory is clear signed with the Cisco PSIRT PGP key and circulated among the following e-mail addresses: * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk Future updates of this advisory, if any, will reside on Cisco.com but may not be announced on mailing lists. Users can monitor this advisory's URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2012-March-28 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information about reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco is available on Cisco.com at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This web page includes instructions for press inquiries regarding Cisco Security Advisories. All Cisco Security Advisories are available at: http://www.cisco.com/go/psirt +-------------------------------------------------------------------- Copyright 2010-2012 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (SunOS) iFcDBQFPcSUMQXnnBKKRMNARCA3iAP48lwmrPR8E6Wi6CVHpEpqoDUnfuHJA/e4E tz+jl1voLwD+NNC2Y5SFONTzfed+n4Ib3cxVLPAwafgVDlr+HhITJgc= =Na2V -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 28 11:20:57 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 28 Mar 2012 12:20:57 -0400 Subject: Cisco Security Advisory: Multiple Vulnerabilities in Cisco IOS Software Traffic Optimization Features Message-ID: <201203281220068.cisco-sa-20120328-mace@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Multiple Vulnerabilities in Cisco IOS Software Traffic Optimization Features Advisory ID: cisco-sa-20120328-mace Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) +-------------------------------------------------------------------- Summary ======= Cisco IOS Software contains a denial of service (DoS) vulnerability in the Wide Area Application Services (WAAS) Express feature that could allow an unauthenticated, remote attacker to cause the router to leak memory or to reload. Cisco IOS Software also contains a DoS vulnerability in the Measurement, Aggregation, and Correlation Engine (MACE) feature that could allow an unauthenticated, remote attacker to cause the router to reload. An attacker could exploit these vulnerabilities by sending transit traffic through a router configured with WAAS Express or MACE. Successful exploitation of these vulnerabilities could allow an unauthenticated, remote attacker to cause the router to leak memory or to reload. Repeated exploits could allow a sustained DoS condition. Cisco has released free software updates that address these vulnerabilities. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-mace Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/ Cisco_ERP_mar12.html Affected Products ================= Vulnerable Products +------------------ Cisco devices that are running Cisco IOS Software are vulnerable when they are configured with the "mace enable" or "waas enable" interface configuration commands on one or more interfaces. Additional configuration is required for WAAS Express or MACE to be configured; more details follow. Note: Cisco IOS Software is vulnerable only when configured for WAAS Express or MACE. Cisco IOS Software configured for WAAS, not WAAS Express, is not vulnerable. For more information on WAAS Express, see http://www.cisco.com/en/US/products/ps11211/index.html. For more information about MACE, see http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps11709/ps11671/guide_c07-664643.html. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.0(1)M1 with an installed image name of C3900-UNIVERSALK9-M: Router> show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS and NX-OS Software Reference Guide" at http://www.cisco.com/web/about/security/intelligence/ios-ref.html. Products Confirmed Not Vulnerable +-------------------------------- No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The Cisco Wide Area Application Services (WAAS) Express feature allows optimization of the WAN bandwidth required to access centrally located applications. WAAS Express allows the traffic to be optimized by a Cisco Integrated Services Router (ISR G2), with no other devices required. The Cisco Measurement, Aggregation, and Correlation Engine (MACE) is a Cisco IOS feature that is used for measurement and analysis of network traffic. The feature may be used with WAAS Express to give details of optimized traffic or used by itself to help measure application performance. Cisco IOS Software contains a DoS vulnerability in the WAAS Express feature that could allow an unauthenticated, remote attacker to cause the router to leak memory or to reload. This vulnerability is documented in Cisco bug ID CSCtt45381 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2012-1314. Cisco IOS Software contains a DoS vulnerability in the MACE feature that could allow an unauthenticated, remote attacker to cause the router to reload. This vulnerability is documented in Cisco bug IDs CSCtq64987 and CSCtu57226 and has been assigned CVE ID CVE-2012-1312. An attacker could exploit these vulnerabilities by sending transit traffic through a router configured with WAAS Express or MACE. Successful exploitation of these vulnerabilities could allow an unauthenticated, remote attacker to cause the router to leak memory or to reload. Repeated exploits could allow a sustained DoS condition. A configuration similar to one or more of the following configuration excerpts will exist if WAAS Express or MACE is configured on the router. The following example shows a partial WAAS Express configuration: parameter-map type waas waas_global tfo optimize full class-map type waas match-any HTTP match tcp destination port 80 class-map type waas match-any NNTP match tcp destination port 119 ... policy-map type waas waas_global class HTTP optimize tfo dre lz application Web class NNTP optimize tfo dre lz application Email-and-Messaging ... interface waas enable The following example shows a partial MACE configuration with WAAS Express already configured as shown in the preceding excerpt: flow record type mace my-flow-record collect art all flow exporter my-flow-exporter export-protocol netflow-v9 destination 10.101.200.1 flow monitor type mace my-flow-monitor record my-flow-record exporter my-flow-exporter mace monitor waas all my-flow-monitor interface mace enable The following example shows a partial MACE configuration without WAAS Express: flow record type mace mace-flow-record collect datalink mac source address input collect ipv4 dscp collect interface input collect interface output collect application name collect waas all flow exporter flow-exporter1 destination 10.101.200.1 source output-features transport udp 32001 flow monitor type mace mace-flow-monitor1 record mace-flow-record exporter flow-exporter1 class-map type waas match-any HTTP match tcp destination port 80 match tcp destination port 8080 ... policy-map type mace mace_global class HTTP flow monitor mace-flow-monitor1 ... interface mace enable Vulnerability Scoring Details ============================= Cisco has scored the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this security advisory is in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps organizations determine the urgency and priority of a response. Cisco has provided a base and temporal score. Customers can also compute environmental scores that help determine the impact of the vulnerability in their own networks. Cisco has provided additional information regarding CVSS at the following link: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to compute the environmental impact for individual networks at the following link: http://intellishield.cisco.com/security/alertmanager/cvss * CSCtt45381 CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed * CSCtq64987 and CSCtu57226 CVSS Base Score - 7.1 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 5.9 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of these vulnerabilities could allow an unauthenticated, remote attacker to cause the router to leak memory or to reload. Repeated exploits could allow a sustained DoS condition. Software Versions and Fixes =========================== When considering software upgrades, customers are advised to consult the Cisco Security Advisories and Responses archive at http://www.cisco.com/go/psirt and review subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should ensure that the devices to be upgraded contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers. Cisco IOS Software +----------------- Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release column. The First Fixed Release for All Advisories in the March 2012 Bundled Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. The Cisco IOS Software Checker allows customers to search for Cisco Security Advisories that address specific Cisco IOS Software releases. This tool is available on the Cisco Security Intelligence Operations (SIO) portal at: http://tools.cisco.com/security/center/selectIOSVersion.x +------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |----------+-------------------------------------------------| | Affected | | First Fixed Release for All | |12.0-Based| First Fixed | Advisories in the March 2012 | | Releases | Release | Cisco IOS Software Security | | | | Advisory Bundled Publication | |------------------------------------------------------------| | There are no affected 12.0 based releases | |------------------------------------------------------------| | Affected | | First Fixed Release for All | |12.2-Based| First Fixed | Advisories in the March 2012 | | Releases | Release | Cisco IOS Software Security | | | | Advisory Bundled Publication | |------------------------------------------------------------| | There are no affected 12.2 based releases | |------------------------------------------------------------| | Affected | | First Fixed Release for All | |12.3-Based| First Fixed | Advisories in the March 2012 | | Releases | Release | Cisco IOS Software Security | | | | Advisory Bundled Publication | |------------------------------------------------------------| | There are no affected 12.3 based releases | |------------------------------------------------------------| | Affected | | First Fixed Release for All | |12.4-Based| First Fixed | Advisories in the March 2012 | | Releases | Release | Cisco IOS Software Security | | | | Advisory Bundled Publication | |------------------------------------------------------------| | There are no affected 12.4 based releases | |------------------------------------------------------------| | Affected | | First Fixed Release for All | |15.0-Based| First Fixed | Advisories in the March 2012 | | Releases | Release | Cisco IOS Software Security | | | | Advisory Bundled Publication | |------------------------------------------------------------| | There are no affected 15.0 based releases | |------------------------------------------------------------| | Affected | | First Fixed Release for All | |15.1-Based| First Fixed | Advisories in the March 2012 | | Releases | Release | Cisco IOS Software Security | | | | Advisory Bundled Publication | |----------+------------------+------------------------------| |15.1EY |Not vulnerable |15.1(2)EY2 | |----------+------------------+------------------------------| |15.1GC |Not vulnerable |15.1(2)GC2 | |----------+------------------+------------------------------| | |15.1(4)M4; |15.1(4)M4; Available on | |15.1M |Available on |30-MAR-12 | | |30-MAR-12 | | |----------+------------------+------------------------------| | | |Vulnerable; contact your | | | |support organization per the | |15.1MR |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of this| | | |advisory. | |----------+------------------+------------------------------| | |Cisco IOS XE | | | |devices: Please |Cisco IOS XE devices: Please | |15.1S |see Cisco IOS XE |see Cisco IOS XE Software | | |Software |Availability | | |Availability | | |----------+------------------+------------------------------| | |Cisco IOS XE | | | |devices: Please |Cisco IOS XE devices: Please | |15.1SG |see Cisco IOS XE |see Cisco IOS XE Software | | |Software |Availability | | |Availability | | |----------+------------------+------------------------------| | | |Vulnerable; contact your | | | |support organization per the | |15.1SNG |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of this| | | |advisory. | |----------+------------------+------------------------------| |15.1SNH |Not vulnerable |Not vulnerable | |----------+------------------+------------------------------| |15.1T |Not vulnerable |15.1(3)T3 | |----------+------------------+------------------------------| |15.1XB |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.1T | |----------+------------------+------------------------------| | Affected | | First Fixed Release for All | |15.2-Based| First Fixed | Advisories in the March 2012 | | Releases | Release | Cisco IOS Software Security | | | | Advisory Bundled Publication | |----------+------------------+------------------------------| |15.2GC |15.2(1)GC2 |15.2(1)GC2 | |----------+------------------+------------------------------| |15.2S |Not vulnerable |15.2(1)S1 | | | | | |----------+------------------+------------------------------| | |15.2(1)T2 |15.2(1)T2 | | |15.2(2)T1 |15.2(2)T1 | |15.2T |15.2(3)T; |15.2(3)T; Available on | | |Available on |30-MAR-12 | | |30-MAR-12 | | +------------------------------------------------------------+ For a mapping of Cisco IOS XE Software releases to Cisco IOS Software releases, refer to Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and Cisco IOS XE 3SG Release Notes. Cisco IOS XE Software +-------------------- Cisco IOS XE Software is not affected by the vulnerabilities that are disclosed in this document. Cisco IOS XR Software +-------------------- Cisco IOS XR Software is not affected by any of the vulnerabilities disclosed in the March 2012 Cisco IOS Software Security Advisory Bundled Publication. Workarounds =========== There are no workarounds for these vulnerabilities. There is no Applied Mitigation Bulletin (AMB) for this advisory. Obtaining Fixed Software ======================== Cisco has released free software updates that address the vulnerabilities described in this advisory. Prior to deploying software, customers are advised to consult their maintenance providers or check the software for feature set compatibility and known issues that are specific to their environments. Customers may only install and expect support for feature sets they have purchased. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as set forth at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, upgrades should be obtained through the Software Center on Cisco.com at http://www.cisco.com. Customers Using Third-Party Support Organizations +------------------------------------------------ Customers with Cisco products that are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers, should contact that organization for assistance with the appropriate course of action. The effectiveness of any workaround or fix depends on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Because of the variety of affected products and releases, customers should consult their service providers or support organizations to ensure that any applied workaround or fix is the most appropriate in the intended network before it is deployed. Customers Without Service Contracts +---------------------------------- Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC): * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade. Customers without service contracts should request free upgrades through the TAC. Refer to Cisco Worldwide Contacts at http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, instructions, and e-mail addresses for support in various languages. Exploitation and Public Announcements ===================================== The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerabilities that are described in this advisory. These vulnerabilities were initially found by Cisco during internal testing. Status of This Notice: Final ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco Security Intelligence Operations at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-mace Additionally, a text version of this advisory is clear signed with the Cisco PSIRT PGP key and circulated among the following e-mail addresses: * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk Future updates of this advisory, if any, will reside on Cisco.com but may not be announced on mailing lists. Users can monitor this advisory's URL for any updates. Revision History ================ +------------------------------------------------------------+ | Revision 1.0 | 2012-March-28 | Initial public release | +------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information about reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco is available on Cisco.com at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This web page includes instructions for press inquiries regarding Cisco Security Advisories. All Cisco Security Advisories are available at http://www.cisco.com/go/psirt. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EAREIAAYFAk9yeDQACgkQQXnnBKKRMND8JAD+LwCEQ/3I15qyaV2fGjOXnBBP oqdlu1PkfePXe5OeMaoA/iUbaiXx3glDNbmziQwcm+fVu2RAJ1HvZzyh0mjz9vOn =BPrU -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 28 11:20:57 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 28 Mar 2012 12:20:57 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerability Message-ID: <201203281220068.cisco-sa-20120328-nat@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco IOS Software Network Address Translation Vulnerability Advisory ID: cisco-sa-20120328-nat Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) +-------------------------------------------------------------------- Summary ======= The Cisco IOS Software Network Address Translation (NAT) feature contains a denial of service (DoS) vulnerability in the translation of Session Initiation Protocol (SIP) packets. The vulnerability is caused when packets in transit on the vulnerable device require translation on the SIP payload. Cisco has released free software updates that address this vulnerability. A workaround that mitigates the vulnerability is available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-nat Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar12.html Affected Products ================= Vulnerable Products +------------------ Cisco devices that are running Cisco IOS Software are vulnerable when they are configured for NAT and contain support for NAT for Session Initiation Protocol. There are two methods to determine if a device is configured for NAT: * Determine if NAT is active on a running device. * Determine if NAT commands are included in the device configuration. Determine if NAT is Active on a Running Device +--------------------------------------------- The preferred method to verify whether NAT is enabled on a Cisco IOS device is to log in to the device and issue the "show ip nat statistics" command. If NAT is active, the sections "Outside interfaces" and "Inside interfaces" will each include at least one interface. The following example shows a device on which the NAT feature is active: Router#show ip nat statistics Total translations: 2 (0 static, 2 dynamic; 0 extended) Outside interfaces: Serial0 Inside interfaces: Ethernet1 Hits: 135 Misses: 5 Expired translations: 2 Dynamic mappings: -- Inside Source access-list 1 pool mypool refcount 2 pool mypool: netmask 255.255.255.0 start 192.168.10.1 end 192.168.10.254 type generic, total addresses 14, allocated 2 (14%), misses 0 Depending on the Cisco IOS Software release, the interface lists can be in the lines following the "Outside interfaces" and "Inside interfaces". In releases that support the "section" filter on "show" commands, the administrator can determine whether NAT is active by using the "show ip nat statistics | section interfaces" command, as illustrated in the following example: Router> show ip nat statistics | section interfaces Outside interfaces: GigabitEthernet0/0 Inside interfaces: GigabitEthernet0/1 Router> Determine if NAT Commands are Included in the Device Configuration +----------------------------------------------------------------- Alternatively, to determine whether NAT has been enabled in the Cisco IOS Software configuration, either the "ip nat inside" or "ip nat outside" commands must be present in different interfaces, or in the case of the NAT Virtual Interface, the "ip nat enable" interface command will be present. Determine the Cisco IOS Software Release +--------------------------------------- To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.0(1)M1 with an installed image name of C3900-UNIVERSALK9-M: Router> show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS and NX-OS Software Reference Guide" at: http://www.cisco.com/web/about/security/intelligence/ios-ref.html Products Confirmed Not Vulnerable +-------------------------------- No other Cisco products are currently known to be affected by this vulnerability. Details ======= Cisco IOS Software NAT SIP Memory Starvation Vulnerability NAT SIP application level gateway (ALG) translation of SIP packets could cause a memory resource exhaustion condition that can lead to a DoS condition, which could cause the reload of the vulnerable device. NAT for SIP is performed on UDP port 5060 packets by default. The port is configurable using the "ip nat service sip udp port" global configuration command. This vulnerability is documented in Cisco bug ID CSCti35326 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2012-0383. Vulnerability Scoring Details ============================= Cisco has scored the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this security advisory is in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps organizations determine the urgency and priority of a response. Cisco has provided a base and temporal score. Customers can also compute environmental scores that help determine the impact of the vulnerability in their own networks. Cisco has provided additional information regarding CVSS at the following link: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to compute the environmental impact for individual networks at the following link: http://intellishield.cisco.com/security/alertmanager/cvss * CSCti35326 ("Cisco IOS Software NAT SIP Memory Starvation Vulnerability") CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability may cause incrementing use of memory that will not be released until the device is reloaded. This memory consumption could lead to a DoS condition and cause the vulnerable device to become unresponsive or reload. Software Versions and Fixes =========================== Cisco IOS Software Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release column. The First Fixed Release for All Advisories in the March 2012 Bundled Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. The Cisco IOS Software Checker allows customers to search for Cisco Security Advisories that address specific Cisco IOS Software releases. This tool is available on the Cisco Security Intelligence Operations (SIO) portal at: http://tools.cisco.com/security/center/selectIOSVersion.x +------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |----------+-------------------------------------------------| | Affected | |First Fixed Release for All | |12.0-Based|First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |------------------------------------------------------------| | There are no affected 12.0 based releases | |------------------------------------------------------------| | Affected | |First Fixed Release for All | |12.2-Based|First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |------------------------------------------------------------| | There are no affected 12.2 based releases | |------------------------------------------------------------| | Affected | |First Fixed Release for All | |12.3-Based|First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |------------------------------------------------------------| | There are no affected 12.3 based releases | |------------------------------------------------------------| | Affected | |First Fixed Release for All | |12.4-Based|First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |----------+--------------------+----------------------------| |12.4 |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| | |Releases up to and |Vulnerable; contact your | | |including 12.4(24) |support organization per the| |12.4GC |GC3a are not |instructions in Obtaining | | |vulnerable. |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| |12.4JA |Not vulnerable |12.4(23c)JA4 | | | |12.4(25e)JA | |----------+--------------------+----------------------------| |12.4JAX |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4JA | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4JDA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4JDC |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4JDD |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4JDE |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4JHA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4JHB |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4JHC |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4JK |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4JL |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| |12.4JX |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4JA | |----------+--------------------+----------------------------| |12.4JY |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4JA | |----------+--------------------+----------------------------| |12.4JZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4JA | |----------+--------------------+----------------------------| | |Only releases 12.4 |12.4(22)MD3; Available on | |12.4MD |(24)MD5 and 12.4(24)|30-MAR-12 | | |MD6 are vulnerable. | | |----------+--------------------+----------------------------| | |Releases 12.4(24) | | | |MDA5 and prior are | | |12.4MDA |not vulnerable; |12.4(24)MDA11 | | |first fixed in 12.2 | | | |(24)MDA11 | | |----------+--------------------+----------------------------| |12.4MDB |12.4(24)MDB4 |12.4(24)MDB5a | |----------+--------------------+----------------------------| |12.4MDC |Not vulnerable |Not vulnerable | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4MR |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4MRA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| |12.4MRB |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4SW |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| | |Only releases 12.4 |12.4(15)T17 | |12.4T |(24)T5 and 12.4(24) |12.4(24)T7 | | |T6 are vulnerable. | | |----------+--------------------+----------------------------| |12.4XA |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4XB |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4T | |----------+--------------------+----------------------------| |12.4XC |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4XD |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4XE |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4XF |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4XG |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4XJ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4XK |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4XL |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| |12.4XM |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4XN |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4XP |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| |12.4XQ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4XR |Not vulnerable |Vulnerable; First fixed in | | | |Release 12.4T | |----------+--------------------+----------------------------| |12.4XT |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4XV |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| |12.4XW |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4XY |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4XZ |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| |12.4YA |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.0M | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4YB |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |12.4YD |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| |12.4YE |Not vulnerable |12.4(24)YE3d | |----------+--------------------+----------------------------| |12.4YG |Not vulnerable |12.4(24)YG4 | |----------+--------------------+----------------------------| | Affected | |First Fixed Release for All | |15.0-Based|First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |----------+--------------------+----------------------------| | |Only releases 15.0 | | |15.0M |(1)M4 and 15.0(1)M5 |15.0(1)M8 | | |are vulnerable. | | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |15.0MR |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |15.0MRA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | |Not vulnerable | | | |Cisco IOS XE |15.0(1)S5 | |15.0S |devices: Please see |Cisco IOS XE devices: Please| | |Cisco IOS XE |see Cisco IOS XE Software | | |Software |Availability | | |Availability | | |----------+--------------------+----------------------------| |15.0SA |Not vulnerable |Not vulnerable | |----------+--------------------+----------------------------| |15.0SE |Not vulnerable |15.0(1)SE1 | |----------+--------------------+----------------------------| | |Not vulnerable | | | |Cisco IOS XE |15.0(2)SG2 | |15.0SG |devices: Please see |Cisco IOS XE devices: Please| | |Cisco IOS XE |see Cisco IOS XE Software | | |Software |Availability | | |Availability | | |----------+--------------------+----------------------------| |15.0SY |Not vulnerable |15.0(1)SY1 | |----------+--------------------+----------------------------| |15.0XA |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.1T | |----------+--------------------+----------------------------| | |Cisco IOS XE | | | |devices: Please see |Cisco IOS XE devices: Please| |15.0XO |Cisco IOS-XE |see Cisco IOS-XE Software | | |Software |Availability | | |Availability | | |----------+--------------------+----------------------------| | Affected | |First Fixed Release for All | |15.1-Based|First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |----------+--------------------+----------------------------| |15.1EY |Not vulnerable |15.1(2)EY2 | |----------+--------------------+----------------------------| |15.1GC |Not vulnerable |15.1(2)GC2 | |----------+--------------------+----------------------------| |15.1M |Not vulnerable |15.1(4)M4; Available on | | | |30-MAR-12 | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |15.1MR |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| | |Not vulnerable | | | |Cisco IOS XE |15.1(3)S2 | |15.1S |devices: Please see |Cisco IOS XE devices: Please| | |Cisco IOS XE |see Cisco IOS XE Software | | |Software |Availability | | |Availability | | |----------+--------------------+----------------------------| | |Not vulnerable | | | |Cisco IOS XE |Not vulnerable | |15.1SG |devices: Please see |Cisco IOS XE devices: Please| | |Cisco IOS XE |see Cisco IOS XE Software | | |Software |Availability | | |Availability | | |----------+--------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |15.1SNG |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+--------------------+----------------------------| |15.1SNH |Not vulnerable |Not vulnerable | |----------+--------------------+----------------------------| | |15.1(1)T4 | | |15.1T |15.1(2)T5; Available|15.1(3)T3 | | |on 27-APR-12 | | | |15.1(3)T | | |----------+--------------------+----------------------------| |15.1XB |Not vulnerable |Vulnerable; First fixed in | | | |Release 15.1T | |----------+--------------------+----------------------------| | Affected | |First Fixed Release for All | |15.2-Based|First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |------------------------------------------------------------| | There are no affected 15.2 based releases | +------------------------------------------------------------+ Cisco IOS XE Software +-------------------- Cisco IOS XE Software is not affected by the vulnerability that is disclosed in this document. Cisco IOS XR Software +-------------------- Cisco IOS XR Software is not affected by any of the vulnerabilities disclosed in the March 2012 Cisco IOS Software Security Advisory bundled publication. Workarounds =========== NAT for SIP Resource Exhaustion Vulnerability +-------------------------------------------- This vulnerability can be mitigated by disabling NAT SIP ALG over the UDP transport by using the "no ip nat service sip udp port 5060" global configuration command. This command can only be configured in Cisco IOS images that include the NAT ALG SIP feature. Layer 3 NAT translation will continue to be performed on SIP packets but the SIP payload will not be translated. Obtaining Fixed Software ======================== Cisco has released free software updates that address the vulnerability|vulnerabilities described in this advisory. Prior to deploying software, customers are advised to consult their maintenance providers or check the software for feature set compatibility and known issues that are specific to their environments. Customers may only install and expect support for feature sets they have purchased. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as set forth at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, upgrades should be obtained through the Software Center on Cisco.com at http://www.cisco.com. Customers Using Third-Party Support Organizations +------------------------------------------------ Customers with Cisco products that are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers, should contact that organization for assistance with the appropriate course of action. The effectiveness of any workaround or fix depends on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Because of the variety of affected products and releases, customers should consult their service providers or support organizations to ensure that any applied workaround or fix is the most appropriate in the intended network before it is deployed. Customers Without Service Contracts +---------------------------------- Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC): * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade. Customers without service contracts should request free upgrades through the TAC. Refer to Cisco Worldwide Contacts at http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, instructions, and e-mail addresses for support in various languages. Exploitation and Public Announcements ===================================== The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory. This vulnerability was found during troubleshooting of TAC service requests. Status of This Notice: Final ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco Security Intelligence Operations at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-nat Additionally, a text version of this advisory is clear signed with the Cisco PSIRT PGP key and circulated among the following e-mail addresses: * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk Future updates of this advisory, if any, will reside on Cisco.com but may not be announced on mailing lists. Users can monitor this advisory's URL for any updates. Revision History ================ +------------------------------------------------------------+ | Revision 1.0 | 2012-March-28 | Initial public release. | +------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information about reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco is available on Cisco.com at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This web page includes instructions for press inquiries regarding Cisco Security Advisories. All Cisco Security Advisories are available at http://www.cisco.com/go/psirt. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EAREIAAYFAk9xNOsACgkQQXnnBKKRMNA9ZgD8DRkOzlhN25SRskCM6aUk2u1W i09PHPREp3klD75CsG4A/2bnHzLZ6x4vSf3PzWIJWHXAPGDiZS7+JtOyp9IBbyoI =GnDB -----END PGP SIGNATURE----- From djahandarie at gmail.com Wed Mar 28 11:39:36 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Wed, 28 Mar 2012 12:39:36 -0400 Subject: BCP38 Deployment In-Reply-To: <20120328161610.GA43005@ussenterprise.ufp.org> References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> Message-ID: On Wed, Mar 28, 2012 at 12:16, Leo Bicknell wrote: > Well, RFC3704 for one has updated the methods and tactics since BCP38 > was written. ?Remember BCP38 was before even "unicast RPF" as we know it > existed. I think the concern of RFC3704/BCP84, i.e., multihoming, is the primary reason we don't see ingress filtering as much as we should. Almost any network worth its salt these days is multihomed, making strict RPF nearly impossible to pull off. Despite this, to my knowledge, Juniper is one of the only vendors that provides feasible-path RPF to deal with it. On Cisco and Brocade for example, you're stuck doing some dark voodoo magic with BGP weights & communities + strict RPF (refer to the previous money and laziness points) to accomplish something that SHOULD be basic. -- Darius Jahandarie From goemon at anime.net Wed Mar 28 11:41:37 2012 From: goemon at anime.net (goemon at anime.net) Date: Wed, 28 Mar 2012 09:41:37 -0700 (PDT) Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> Message-ID: On Wed, 28 Mar 2012, David Conrad wrote: > Actually, given the uptick in spoofing-based DoS attacks, the ease in > which such attacks can be generated, recent high profile targets of said > attacks, and the full-on money pumping freakout about anything with > "cyber-" tacked on the front, I suspect a likely outcome will be > proposals for legislation forcing ISPs to do something like BCP38. Exactly. Either do it voluntarily or it will be done for you involuntarily at the federal level and you will have nobody but yourselves to blame. The choice is yours. -Dan From drc at virtualized.org Wed Mar 28 11:50:04 2012 From: drc at virtualized.org (David Conrad) Date: Wed, 28 Mar 2012 09:50:04 -0700 Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> Message-ID: <8F095B57-ABE5-4D5E-AF0A-BFC963D58EE0@virtualized.org> On Mar 28, 2012, at 9:39 AM, Darius Jahandarie wrote: > I think the concern of RFC3704/BCP84, i.e., multihoming, is the > primary reason we don't see ingress filtering as much as we should. I would be surprised if this were true. I'd argue that today, the vast majority of devices on the Internet (and certainly the ones that are used in massive D(D)oS attacks) are found hanging off singly-homed networks. Regards, -drc From bjornliu at gmail.com Wed Mar 28 11:51:20 2012 From: bjornliu at gmail.com (Bingyang LIU) Date: Wed, 28 Mar 2012 18:51:20 +0200 Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> Message-ID: Yep, one way is to give economic penalty. But how about giving the _good_ ISPs economic reward? Say, some transit ISPs deploy anti-spoofing techniques (e.g. uRPF), but only filter those spoofing packets whose destination is the ASes having purchased their *anti-spoofing service* ? Bingyang On Wed, Mar 28, 2012 at 6:41 PM, wrote: > On Wed, 28 Mar 2012, David Conrad wrote: >> >> Actually, given the uptick in spoofing-based DoS attacks, the ease in >> which such attacks can be generated, recent high profile targets of said >> attacks, and the full-on money pumping freakout about anything with "cyber-" >> tacked on the front, I suspect a likely outcome will be proposals for >> legislation forcing ISPs to do something like BCP38. > > > Exactly. > > Either do it voluntarily or it will be done for you involuntarily at the > federal level and you will have nobody but yourselves to blame. > > The choice is yours. > > -Dan > -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby From mike at mtcc.com Wed Mar 28 11:52:49 2012 From: mike at mtcc.com (Michael Thomas) Date: Wed, 28 Mar 2012 09:52:49 -0700 Subject: BCP38 Deployment In-Reply-To: <20120328161610.GA43005@ussenterprise.ufp.org> References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> Message-ID: <4F7341E1.4000804@mtcc.com> On 03/28/2012 09:16 AM, Leo Bicknell wrote: > In a message written on Wed, Mar 28, 2012 at 08:45:12AM -0700, David Conrad wrote: >> An interesting assertion. I haven't looked at how end-user networks are built recently. I had assumed there continue to be customer aggregation points within ISP infrastructure in which BCP38-type filtering could occur. You're saying this is no longer the case? What has replaced it? > Well, RFC3704 for one has updated the methods and tactics since BCP38 > was written. Remember BCP38 was before even "unicast RPF" as we know it > existed. > > > > I'm not saying ISP's can't or couldn't do it, what I am saying, and > RFC 3704 is repeating, is that it is cheaper/easier/faster and more > reliable to do it as close to the edge as possible. "The edge" is > not the edge of the ISP network, it is the edge of the entire > network, that is the /last router in the topology/. Today that > last router is owned and operated by the customer in most cases. Yeahbut, the CPE isn't trusted. It would be _nice_ for customers to be bcp38 clueful as well, but I don't think it's _required_ for successful deployment from the ISP's standpoint. Even with a system like DOCSIS where the CPE is semi-trustworthy from a provisioning/etc standpoint, I don't think I'd _count_ on them. In any case, isn't RPF really cheap these days on edge aggregation routers? It's not like it's a new innovation or anything. > > > BCP38 was written when a point to point handoff to a single customer was > standard, and that's easy to filter. Today a shared medium (like a > cable modem network) is common and more importantly connects to more > routers (home gateways), rathern than PC's. That's a funamental change > since BCP38 was written. DOCSIS was standardized in the mid to late 90's which more or less predates bcp 38, and it has always been able to handle multiple endpoints/modem. As I recall, there were specs for cable modem nics for individual machines, but they never took off. Mike > From brunner at nic-naa.net Wed Mar 28 11:54:44 2012 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 28 Mar 2012 12:54:44 -0400 Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> Message-ID: <4F734254.7010706@nic-naa.net> On 3/28/12 11:45 AM, David Conrad wrote: > Actually, given the uptick in spoofing-based DoS attacks, the ease in which such attacks can be generated, recent high profile targets of said attacks, and the full-on money pumping freakout about anything with "cyber-" tacked on the front, I suspect a likely outcome will be proposals for legislation forcing ISPs to do something like BCP38. in a note (which didn't go anywhere in particular) i pointed out that contract may address the same issue for which legislation may be proposed, at least for "contractual closures" (sorry, a term of my own, defined below) which share the property some jurisdictions have of a finite access provider universe. i mean "contractual closure" to be the performance guarantee (or non-performance guarantee) present in a set of contracts for a particular service. think "china", after first abstracting all the negatives associated with policy as a property of a distributed, shared, public resource, or "firewalls 4 (bcp defined) good". -e From psirt at cisco.com Wed Mar 28 11:20:57 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 28 Mar 2012 12:20:57 -0400 Subject: Cisco Security Advisory: Cisco IOS Software RSVP Denial of Service Vulnerability Message-ID: <201203281220068.cisco-sa-20120328-rsvp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco IOS Software RSVP Denial of Service Vulnerability Advisory ID: cisco-sa-20120328-rsvp Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS Software and Cisco IOS XE Software contain a vulnerability in the RSVP feature when used on a device configured with VPN routing and forwarding (VRF) instances. This vulnerability could allow an unauthenticated, remote attacker to cause an interface wedge, which can lead to loss of connectivity, loss of routing protocol adjacency, and other denial of service (DoS) conditions. This vulnerability could be exploited repeatedly to cause an extended DoS condition. A workaround is available to mitigate this vulnerability. Cisco has released free software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-rsvp Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar12.html Affected Products ================= Vulnerable Products +------------------ Only devices with specific configurations are affected. Cisco devices that are running affected Cisco IOS Software or Cisco IOS XE Software versions are vulnerable when they are configured with RSVP and also have one or more VRF interfaces. A device is vulnerable if both the following criteria are met: * At least one VRF is configured without RSVP * At least one other interface (physical or virtual), not in the same VRF, is configured with RSVP Some example scenarios are as follows: * RSVP-Traffic Engineering (RSVP-TE) in Multiprotocol Label Switching (MPLS) infrastructures * Multi-VRF infrastructures * VRF-Lite infrastructures To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.0(1)M1 with an installed image name of C3900-UNIVERSALK9-M: Router> show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS and NX-OS Software Reference Guide" at: http://www.cisco.com/web/about/security/intelligence/ios-ref.html Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS-XR software is not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Cisco IOS Software and Cisco IOS XE Software contain a vulnerability in the RSVP feature when used on a device configured with VPN routing and forwarding (VRF) instances. This vulnerability could allow an unauthenticated, remote attacker to cause an interface wedge, which can lead to loss of connectivity, loss of routing protocol adjacency, and other denial of service (DoS) conditions. This vulnerability could be exploited repeatedly to cause an extended DoS condition. A device is vulnerable if it is configured with VRF and none of the interfaces in that VRF have RSVP enabled, but any other interface (physical or virtual) does have RSVP enabled. An attacker with some knowledge of the affected infrastructure could exploit this vulnerability by sending RSVP packets to vulnerable devices. Successful exploitation of the vulnerability could allow an attacker to wedge the receive queue of any RSVP ingress interface. A workaround is available to mitigate this vulnerability. In devices that meet the vulnerable configuration criteria, valid RSVP packets could trigger this vulnerability. An attacker with knowledge of the infrastructure could craft valid RSVP packets with set conditions to exploit this vulnerability. Recovery from this interface queue wedge requires a reload of the device. An interface queue wedge is a class of vulnerability in which certain packets are received and queued by a Cisco IOS router or switch but, due to a processing error, are never removed from the queue. For more information about queue wedges and a few detection mechanisms that may be used to identify a blocked interface on Cisco IOS Software (including a white paper describing how this condition can be detected using SNMP) see: http://blogs.cisco.com/security/comments/cisco_ios_queue_wedges_explained This vulnerability has been documented in Cisco bug ID CSCts80643 and has been assigned the Common Vulnerabilities and Exposures (CVE) ID CVE-2012-1311. Vulnerability Scoring Details ============================= Cisco has scored the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this security advisory is in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps organizations determine the urgency and priority of a response. Cisco has provided a base and temporal score. Customers can also compute environmental scores that help determine the impact of the vulnerability in their own networks. Cisco has provided additional information regarding CVSS at the following link: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to compute the environmental impact for individual networks at the following link: http://intellishield.cisco.com/security/alertmanager/cvss * CSCts80643 - Cisco IOS Software RSVP Denial of Service Vulnerability CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability will result in an interface queue wedge, which can lead to loss of connectivity, loss of routing protocol adjacency, and other DoS conditions. This vulnerability could be exploited repeatedly to cause an extended DoS condition. Software Versions and Fixes =========================== When considering software upgrades, customers are advised to consult the Cisco Security Advisories and Responses archive at: http://www.cisco.com/go/psirt and review subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should ensure that the devices to be upgraded contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers. Cisco IOS Software +----------------- Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release column. The First Fixed Release for All Advisories in the March 2012 Bundled Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. The Cisco IOS Software Checker allows customers to search for Cisco Security Advisories that address specific Cisco IOS Software releases. This tool is available on the Cisco Security Intelligence Operations (SIO) portal at: http://tools.cisco.com/security/center/selectIOSVersion.x +--------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |----------+---------------------------------------------------------| | Affected | |First Fixed Release for All | |12.0-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |--------------------------------------------------------------------| | There are no affected 12.0 based releases | |--------------------------------------------------------------------| | Affected | |First Fixed Release for All | |12.2-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |--------------------------------------------------------------------| | There are no affected 12.2 based releases | |--------------------------------------------------------------------| | Affected | |First Fixed Release for All | |12.3-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |--------------------------------------------------------------------| | There are no affected 12.3 based releases | |--------------------------------------------------------------------| | Affected | |First Fixed Release for All | |12.4-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |--------------------------------------------------------------------| | There are no affected 12.4 based releases | |--------------------------------------------------------------------| | Affected | |First Fixed Release for All | |15.0-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |----------+----------------------------+----------------------------| |15.0M |15.0(1)M8 |15.0(1)M8 | |----------+----------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |15.0MR |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+----------------------------+----------------------------| | | |Vulnerable; contact your | | | |support organization per the| |15.0MRA |Not vulnerable |instructions in Obtaining | | | |Fixed Software section of | | | |this advisory. | |----------+----------------------------+----------------------------| | |Not vulnerable |15.0(1)S5 | |15.0S |Cisco IOS XE devices: Please|Cisco IOS XE devices: Please| | |see Cisco IOS XE Software |see Cisco IOS XE Software | | |Availability |Availability | |----------+----------------------------+----------------------------| |15.0SA |Not vulnerable |Not vulnerable | |----------+----------------------------+----------------------------| |15.0SE |Not vulnerable |15.0(1)SE1 | |----------+----------------------------+----------------------------| | |Not vulnerable |15.0(2)SG2 | |15.0SG |Cisco IOS XE devices: Please|Cisco IOS XE devices: Please| | |see Cisco IOS XE Software |see Cisco IOS XE Software | | |Availability |Availability | |----------+----------------------------+----------------------------| |15.0SY |15.0(1)SY1 |15.0(1)SY1 | |----------+----------------------------+----------------------------| |15.0XA |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.1T |Release 15.1T | |----------+----------------------------+----------------------------| | |Cisco IOS XE devices: Please|Cisco IOS XE devices: Please| |15.0XO |see Cisco IOS XE Software |see Cisco IOS XE Software | | |Availability |Availability | |----------+----------------------------+----------------------------| | Affected | |First Fixed Release for All | |15.1-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |----------+----------------------------+----------------------------| |15.1EY |15.1(2)EY2 |15.1(2)EY2 | |----------+----------------------------+----------------------------| |15.1GC |15.1(2)GC2 |15.1(2)GC2 | |----------+----------------------------+----------------------------| |15.1M |15.1(4)M3 |15.1(4)M4; Available on | | |15.1(4)M3a |30-MAR-12 | |----------+----------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per the| |15.1MR |instructions in Obtaining |instructions in Obtaining | | |Fixed Software section of |Fixed Software section of | | |this advisory. |this advisory. | |----------+----------------------------+----------------------------| | |15.1(3)S2 |15.1(3)S2 | |15.1S |Cisco IOS XE devices: Please|Cisco IOS XE devices: Please| | |see Cisco IOS XE Software |see Cisco IOS XE Software | | |Availability |Availability | |----------+----------------------------+----------------------------| | |Not vulnerable |Not vulnerable | |15.1SG |Cisco IOS XE devices: Please|Cisco IOS XE devices: Please| | |see Cisco IOS XE Software |see Cisco IOS XE Software | | |Availability |Availability | |----------+----------------------------+----------------------------| | |Vulnerable; contact your |Vulnerable; contact your | | |support organization per the|support organization per the| |15.1SNG |instructions in Obtaining |instructions in Obtaining | | |Fixed Software section of |Fixed Software section of | | |this advisory. |this advisory. | |----------+----------------------------+----------------------------| |15.1SNH |Not vulnerable |Not vulnerable | |----------+----------------------------+----------------------------| | |15.1(1)T5; Available on | | | |18-MAY-12 | | |15.1T |15.1(2)T5; Available on |15.1(3)T3 | | |27-APR-12 | | | |15.1(3)T3 | | |----------+----------------------------+----------------------------| |15.1XB |Vulnerable; First fixed in |Vulnerable; First fixed in | | |Release 15.1T |Release 15.1T | |----------+----------------------------+----------------------------| | Affected | |First Fixed Release for All | |15.2-Based| First Fixed Release |Advisories in the March 2012| | Releases | |Cisco IOS Software Security | | | |Advisory Bundled Publication| |--------------------------------------------------------------------| | There are no affected 15.2 based releases | +--------------------------------------------------------------------+ Cisco IOS XE Software +-------------------- Cisco IOS XE Software is affected by the vulnerability that is disclosed in this document. +---------------------------------------+ | | | First Fixed | | | | Release for | | | | All | | Cisco | | Advisories | | IOS XE | First Fixed | in the March | | Software | Release | 2012 Cisco | | Release | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |----------+-------------+--------------| | | | Vulnerable; | | 2.1.x | Not | migrate to | | | vulnerable | 3.4.2S or | | | | later. | |----------+-------------+--------------| | | | Vulnerable; | | 2.2.x | Not | migrate to | | | vulnerable | 3.4.2S or | | | | later. | |----------+-------------+--------------| | | | Vulnerable; | | 2.3.x | Not | migrate to | | | vulnerable | 3.4.2S or | | | | later. | |----------+-------------+--------------| | | | Vulnerable; | | 2.4.x | Not | migrate to | | | vulnerable | 3.4.2S or | | | | later. | |----------+-------------+--------------| | | | Vulnerable; | | 2.5.x | Not | migrate to | | | vulnerable | 3.4.2S or | | | | later. | |----------+-------------+--------------| | | | Vulnerable; | | 2.6.x | Not | migrate to | | | vulnerable | 3.4.2S or | | | | later. | |----------+-------------+--------------| | | | Vulnerable; | | 3.1.xS | Not | migrate to | | | vulnerable | 3.4.2S or | | | | later. | |----------+-------------+--------------| | | | Vulnerable; | | 3.1xSG | Not | migrate to | | | vulnerable | 3.2.2SG or | | | | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 3.2.xS | migrate to | migrate to | | | 3.4.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | 3.2xSG | Not | 3.2.2SG | | | vulnerable | | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 3.3.xS | migrate to | migrate to | | | 3.4.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | 3.3.xSG | Not | Not | | | Vulnerable | Vulnerable | |----------+-------------+--------------| | 3.4.xS | 3.4.2S | 3.4.2S | |----------+-------------+--------------| | 3.5.xS | Not | 3.5.1S | | | vulnerable | | |----------+-------------+--------------| | 3.6.xS | Not | Not | | | vulnerable | vulnerable | +---------------------------------------+ For a mapping of Cisco IOS XE Software releases to Cisco IOS Software releases, refer to Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and Cisco IOS XE 3SG Release Notes. Cisco IOS XR Software +-------------------- Cisco IOS XR Software is not affected by any of the vulnerabilities disclosed in the March 2012 Cisco IOS Software Security Advisory Bundled Publication. Workarounds =========== It is possible to mitigate the vulnerability in this advisory by applying the global configuration command ip rsvp listener vrf vrf-name ip-address 0 0 announce, where the IP address is one that does not exist on the device or in the routing tables. Obtaining Fixed Software ======================== Cisco has released free software updates that address the vulnerability described in this advisory. Prior to deploying software, customers are advised to consult their maintenance providers or check the software for feature set compatibility and known issues that are specific to their environments. Customers may only install and expect support for feature sets they have purchased. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as set forth at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, upgrades should be obtained through the Software Center on Cisco.com at http://www.cisco.com Customers Using Third-Party Support Organizations +------------------------------------------------ Customers with Cisco products that are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers, should contact that organization for assistance with the appropriate course of action. The effectiveness of any workaround or fix depends on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Because of the variety of affected products and releases, customers should consult their service providers or support organizations to ensure that any applied workaround or fix is the most appropriate in the intended network before it is deployed. Customers Without Service Contracts +---------------------------------- Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC): * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade. Customers without service contracts should request free upgrades through the TAC. Refer to Cisco Worldwide Contacts at: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, instructions, and e-mail addresses for support in various languages. Exploitation and Public Announcements ===================================== The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory. This vulnerability was discovered by Cisco during internal testing. Status of This Notice: Final +--------------------------- THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on the Cisco Security Intelligence Operations portal at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-rsvp Additionally, a text version of this advisory is clear signed with the Cisco PSIRT PGP key and circulated among the following e-mail addresses: * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk Future updates of this advisory, if any, will reside on Cisco.com but may not be announced on mailing lists. Users can monitor this advisory's URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2012-March-28 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information about reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco is available on Cisco.com at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This web page includes instructions for press inquiries regarding Cisco Security Advisories. All Cisco Security Advisories are available at: http://www.cisco.com/go/psirt +-------------------------------------------------------------------- Copyright 2010-2012 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAk9zJcsACgkQQXnnBKKRMNDH1QD/fcj0Kk+JmG8NAI53aDniH5yk EfxvebH1J/HGmUcEuFAA/RMKnbZ81Zx39c2hJe7iuaeRZnglJVFbsZyIPvZZrOSU =HBKt -----END PGP SIGNATURE----- From bjornliu at gmail.com Wed Mar 28 12:05:03 2012 From: bjornliu at gmail.com (Bingyang LIU) Date: Wed, 28 Mar 2012 19:05:03 +0200 Subject: BCP38 Deployment In-Reply-To: <4F734254.7010706@nic-naa.net> References: <20120328151335.GA40955@ussenterprise.ufp.org> <4F734254.7010706@nic-naa.net> Message-ID: Yeah, "contractual closures" might be a way to force the providers to deploy BCP38. However, when the customers become the target of a spoofing attack, the provider may not be able to protect its customers, because ingress filtering (including uRPF) is inefficient when done near the destination. In other words, an ISP can deploy BCP38 or whatever, but still cannot well protect its customers from spoofing attacks from other ASes. On Wed, Mar 28, 2012 at 6:54 PM, Eric Brunner-Williams wrote: > On 3/28/12 11:45 AM, David Conrad wrote: >> Actually, given the uptick in spoofing-based DoS attacks, the ease in which such attacks can be generated, recent high profile targets of said attacks, and the full-on money pumping freakout about anything with "cyber-" tacked on the front, I suspect a likely outcome will be proposals for legislation forcing ISPs to do something like BCP38. > > in a note (which didn't go anywhere in particular) i pointed out that > contract may address the same issue for which legislation may be > proposed, at least for "contractual closures" (sorry, a term of my > own, defined below) which share the property some jurisdictions have > of a finite access provider universe. > > > i mean "contractual closure" to be the performance guarantee (or > non-performance guarantee) present in a set of contracts for a > particular service. > > think "china", after first abstracting all the negatives associated > with policy as a property of a distributed, shared, public resource, > or "firewalls 4 (bcp defined) good". > > -e > -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby From djahandarie at gmail.com Wed Mar 28 12:07:17 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Wed, 28 Mar 2012 13:07:17 -0400 Subject: BCP38 Deployment In-Reply-To: <8F095B57-ABE5-4D5E-AF0A-BFC963D58EE0@virtualized.org> References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> <8F095B57-ABE5-4D5E-AF0A-BFC963D58EE0@virtualized.org> Message-ID: On Wed, Mar 28, 2012 at 12:50, David Conrad wrote: > I would be surprised if this were true. > > I'd argue that today, the vast majority of devices on the Internet (and certainly the ones that are used in massive D(D)oS attacks) are found hanging off singly-homed networks. Yes, but RPF can be implemented in places other than the customer edge. In those places, lack of widespread, easy, and vendor-supported feasible-path uRPF is what I believe really hurts things. Granted, this is along a different line than what the OP was talking about, but in terms of answering the question of "why don't we see ingress filtering as much as we should?", I think it's a large factor. -- Darius Jahandarie From goemon at anime.net Wed Mar 28 12:11:07 2012 From: goemon at anime.net (goemon at anime.net) Date: Wed, 28 Mar 2012 10:11:07 -0700 (PDT) Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> <4F734254.7010706@nic-naa.net> Message-ID: On Wed, 28 Mar 2012, Bingyang LIU wrote: > the provider may not be able to protect its customers, because ingress > filtering (including uRPF) is inefficient when done near the > destination. In other words, an ISP can deploy BCP38 or whatever, but > still cannot well protect its customers from spoofing attacks from > other ASes. The ASes which enable spoofing need to have some penalty imposed or they will never engage in correct behavior. Something like throwing all their traffic into scavenger class. If their customers start complaining to them, maybe then they will shape up. -Dan From bjornliu at gmail.com Wed Mar 28 12:14:44 2012 From: bjornliu at gmail.com (Bingyang LIU) Date: Wed, 28 Mar 2012 19:14:44 +0200 Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> <8F095B57-ABE5-4D5E-AF0A-BFC963D58EE0@virtualized.org> Message-ID: Hi Darius, Yes, I agree that feasible RPF solves the problem in a lot of scenarios. However, in some other cases, the asymmetric routing is caused by static routing, traffic engineering, policy routing, etc., where the lengths of forward path and reverse path may differ, so feasible RPF may also fail (false positive). Bingyang On Wed, Mar 28, 2012 at 7:07 PM, Darius Jahandarie wrote: > On Wed, Mar 28, 2012 at 12:50, David Conrad wrote: >> I would be surprised if this were true. >> >> I'd argue that today, the vast majority of devices on the Internet (and certainly the ones that are used in massive D(D)oS attacks) are found hanging off singly-homed networks. > > Yes, but RPF can be implemented in places other than the customer > edge. In those places, lack of widespread, easy, and vendor-supported > feasible-path uRPF is what I believe really hurts things. > > Granted, this is along a different line than what the OP was talking > about, but in terms of answering the question of "why don't we see > ingress filtering as much as we should?", I think it's a large factor. > > -- > Darius Jahandarie > -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby From carlosm3011 at gmail.com Wed Mar 28 12:41:51 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 28 Mar 2012 14:41:51 -0300 Subject: Quad-A records in Network Solutions ? Message-ID: <4F734D5F.9030902@gmail.com> Hello all, I just received a heads-up from a friend telling me that Network Solutions is unable/unwilling to configure AAAA's for .com/.net domains. He works for a large media outlet who will be enabling IPv6 on their sites for World IPv6 Launch Day. I hope it's just a misunderstanding. If it's not, I would love to know if there is a reason for this, and if they have a timeline for supporting AAAA's. It's ok to contact me privately. regards Carlos From nanog at techmonkeys.org Wed Mar 28 12:53:35 2012 From: nanog at techmonkeys.org (Jeff Fisher) Date: Wed, 28 Mar 2012 11:53:35 -0600 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F734D5F.9030902@gmail.com> References: <4F734D5F.9030902@gmail.com> Message-ID: <4F73501F.3060602@techmonkeys.org> > I just received a heads-up from a friend telling me that Network > Solutions is unable/unwilling to configure AAAA's for .com/.net domains. > He works for a large media outlet who will be enabling IPv6 on their > sites for World IPv6 Launch Day. > > I hope it's just a misunderstanding. If it's not, I would love to know > if there is a reason for this, and if they have a timeline for > supporting AAAA's. I've had them set up in the past by e-mailing IPV6Req at networksolutions.com. From alejandroacostaalamo at gmail.com Wed Mar 28 12:57:17 2012 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Wed, 28 Mar 2012 13:27:17 -0430 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F734D5F.9030902@gmail.com> References: <4F734D5F.9030902@gmail.com> Message-ID: Hi Carlos, You are right... I just entered with my account and after I clicked "Edit DNS" there is a dialog box which says: "Advanced Users: To specify your IPv6 name server address (IPv6 glue record), e-mail us the domain name, the host name of the name server(s), and their IPv6 address(es)." See you, Alejandro, On 3/28/12, Carlos Martinez-Cagnazzo wrote: > Hello all, > > I just received a heads-up from a friend telling me that Network > Solutions is unable/unwilling to configure AAAA's for .com/.net domains. > He works for a large media outlet who will be enabling IPv6 on their > sites for World IPv6 Launch Day. > > I hope it's just a misunderstanding. If it's not, I would love to know > if there is a reason for this, and if they have a timeline for > supporting AAAA's. > > It's ok to contact me privately. > > regards > > Carlos > > From carlosm3011 at gmail.com Wed Mar 28 13:01:50 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 28 Mar 2012 15:01:50 -0300 Subject: Quad-A records in Network Solutions ? In-Reply-To: References: <4F734D5F.9030902@gmail.com> Message-ID: <4F73520E.9070600@gmail.com> Yup... I was reading the same page myself. Pretty sad. My friend just forwarded me the response from NSI Support. Incredibly lame. I'm tempted to share it here, but my good twin told me not to. I'm recommending they switch registrars. regards, Carlos On 3/28/12 2:57 PM, Alejandro Acosta wrote: > Hi Carlos, > You are right... I just entered with my account and after I clicked > "Edit DNS" there is a dialog box which says: > > "Advanced Users: > > To specify your IPv6 name server address (IPv6 glue record), e-mail us > the domain name, the host name of the name server(s), and their IPv6 > address(es)." > > > See you, > > Alejandro, > > > On 3/28/12, Carlos Martinez-Cagnazzo wrote: >> Hello all, >> >> I just received a heads-up from a friend telling me that Network >> Solutions is unable/unwilling to configure AAAA's for .com/.net domains. >> He works for a large media outlet who will be enabling IPv6 on their >> sites for World IPv6 Launch Day. >> >> I hope it's just a misunderstanding. If it's not, I would love to know >> if there is a reason for this, and if they have a timeline for >> supporting AAAA's. >> >> It's ok to contact me privately. >> >> regards >> >> Carlos >> >> From jordi.palet at consulintel.es Wed Mar 28 12:59:24 2012 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 28 Mar 2012 19:59:24 +0200 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F73501F.3060602@techmonkeys.org> Message-ID: And they need to do anyway, if they want to keep the contract: http://www.ipv6tf.org/index.php?page=news/newsroom&id=8494 Regards, Jordi -----Mensaje original----- De: Jeff Fisher Responder a: Fecha: Wed, 28 Mar 2012 11:53:35 -0600 Para: Asunto: Re: Quad-A records in Network Solutions ? >> I just received a heads-up from a friend telling me that Network >> Solutions is unable/unwilling to configure AAAA's for .com/.net domains. >> He works for a large media outlet who will be enabling IPv6 on their >> sites for World IPv6 Launch Day. >> >> I hope it's just a misunderstanding. If it's not, I would love to know >> if there is a reason for this, and if they have a timeline for >> supporting AAAA's. > >I've had them set up in the past by e-mailing >IPV6Req at networksolutions.com. > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From drew.weaver at thenap.com Wed Mar 28 13:31:07 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 28 Mar 2012 14:31:07 -0400 Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> <8F095B57-ABE5-4D5E-AF0A-BFC963D58EE0@virtualized.org> Message-ID: Also, Don't forget that transit providers currently bill their customers to carry that spoofed/DoS traffic, why would they filter it when it's $$$$ on their balance sheets? -Drew -----Original Message----- From: Bingyang LIU [mailto:bjornliu at gmail.com] Sent: Wednesday, March 28, 2012 1:15 PM To: Darius Jahandarie Cc: NANOG list Subject: Re: BCP38 Deployment Hi Darius, Yes, I agree that feasible RPF solves the problem in a lot of scenarios. However, in some other cases, the asymmetric routing is caused by static routing, traffic engineering, policy routing, etc., where the lengths of forward path and reverse path may differ, so feasible RPF may also fail (false positive). Bingyang On Wed, Mar 28, 2012 at 7:07 PM, Darius Jahandarie wrote: > On Wed, Mar 28, 2012 at 12:50, David Conrad wrote: >> I would be surprised if this were true. >> >> I'd argue that today, the vast majority of devices on the Internet (and certainly the ones that are used in massive D(D)oS attacks) are found hanging off singly-homed networks. > > Yes, but RPF can be implemented in places other than the customer > edge. In those places, lack of widespread, easy, and vendor-supported > feasible-path uRPF is what I believe really hurts things. > > Granted, this is along a different line than what the OP was talking > about, but in terms of answering the question of "why don't we see > ingress filtering as much as we should?", I think it's a large factor. > > -- > Darius Jahandarie > -- Bingyang Liu Network Architecture Lab, Network Center,Tsinghua Univ. Beijing, China Home Page: http://netarchlab.tsinghua.edu.cn/~liuby From shrdlu at deaddrop.org Wed Mar 28 13:40:27 2012 From: shrdlu at deaddrop.org (Lynda) Date: Wed, 28 Mar 2012 11:40:27 -0700 Subject: Quad-A records in Network Solutions ? In-Reply-To: References: Message-ID: <4F735B1B.4030909@deaddrop.org> On 3/28/2012 10:59 AM, JORDI PALET MARTINEZ wrote: > And they need to do anyway, if they want to keep the contract: > > http://www.ipv6tf.org/index.php?page=news/newsroom&id=8494 This really points out one of the biggest impediments to moving to IPv6. I just briefly looked at the list of registrars that are able to create glue records for any domain I might have that I wanted to exist in IPv6, and it's a very limited list. I'm currently using Pairnic, and I am happy with them, mostly, but moving to IPv6 is painful. To quote: > We don't have a customer interface for IPv6 glue records on name servers. > However, we can manually set them up if you can send us the information > for the records. That's probably okay for me, but it's really not conducive to any large scale operation. It needs to be run-of-the-mill, and not esoteric, to move it forward. -- It isn't just me. http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-left-google.aspx From carlosm3011 at gmail.com Wed Mar 28 13:47:08 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 28 Mar 2012 15:47:08 -0300 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F735B1B.4030909@deaddrop.org> References: <4F735B1B.4030909@deaddrop.org> Message-ID: <4F735CAC.2010700@gmail.com> I'm not a fan of conspiracy theories, but, c'mon. For a provisioning system, an AAAA record is just a fragging string, just like any other DNS record. How difficult to support can it be ? regards Carlos On 3/28/12 3:40 PM, Lynda wrote: > On 3/28/2012 10:59 AM, JORDI PALET MARTINEZ wrote: >> And they need to do anyway, if they want to keep the contract: >> >> http://www.ipv6tf.org/index.php?page=news/newsroom&id=8494 > > This really points out one of the biggest impediments to moving to > IPv6. I just briefly looked at the list of registrars that are able to > create glue records for any domain I might have that I wanted to exist > in IPv6, and it's a very limited list. I'm currently using Pairnic, > and I am happy with them, mostly, but moving to IPv6 is painful. > > To quote: > >> We don't have a customer interface for IPv6 glue records on name >> servers. >> However, we can manually set them up if you can send us the information >> for the records. > > That's probably okay for me, but it's really not conducive to any > large scale operation. It needs to be run-of-the-mill, and not > esoteric, to move it forward. > From joelja at bogus.com Wed Mar 28 13:48:30 2012 From: joelja at bogus.com (Joel jaeggli) Date: Wed, 28 Mar 2012 20:48:30 +0200 Subject: FW: Force10 E Series at the edge? In-Reply-To: <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp> References: <011a01cd0c5f$737a1720$5a6e4560$@wirezsound.com> <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp> Message-ID: <4F735CFE.30606@bogus.com> On 3/27/12 23:21 , Roberts, Brent wrote: > Is anyone running an E300 Series Chassis at the internet edge with multiple Full BGP feeds? 95th percent would be about 300 meg of traffic. BGP session count would be between 2 and 4 Peers. > 6k internal Prefix count as it stands right now. Alternative are welcome. Thought about the ASR1006 but I need some local switching as well. Doesn't support URPF which makes it unsuitable for RTBH and therefore customer or transit edge IMHO. I do use them and like them reasonably well for high density over-subscription 10Gb/s ports. Can get 280 2x oversubscribed 10Gb/s ports or 560 4x layer 3 out of an e1200i. > Full requirements include > Full internet Peering over GigE Links. > Fully Redundant Power > Redundant "Supervisor/Route Processor" > Would prefer a Small Chassis unit. (under 10u) > Would also prefer a single unit as opposed to a two smaller units. > > > ________________________________ > > This email and any attached files may contain confidential and/or privileged material and is intended solely for the use of the person to whom it is addressed. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete it and all attachments from your computer. Progressive Solutions is not liable for any errors or omissions in the content or transmission of this email. > From cmadams at hiwaay.net Wed Mar 28 13:51:19 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 28 Mar 2012 13:51:19 -0500 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F735B1B.4030909@deaddrop.org> References: <4F735B1B.4030909@deaddrop.org> Message-ID: <20120328185119.GB11515@hiwaay.net> Once upon a time, Lynda said: > This really points out one of the biggest impediments to moving to IPv6. > I just briefly looked at the list of registrars that are able to create > glue records for any domain I might have that I wanted to exist in IPv6, > and it's a very limited list. I'm currently using Pairnic, and I am > happy with them, mostly, but moving to IPv6 is painful. The same problem exists for DNSSEC; the number of registrars that support both IPv6 glue and DNSSEC in their standard interfaces is unfortunately small. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From drc at virtualized.org Wed Mar 28 13:55:35 2012 From: drc at virtualized.org (David Conrad) Date: Wed, 28 Mar 2012 11:55:35 -0700 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F735CAC.2010700@gmail.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> Message-ID: On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: > I'm not a fan of conspiracy theories, but, c'mon. For a provisioning > system, an AAAA record is just a fragging string, just like any other > DNS record. How difficult to support can it be ? Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. Regards, -drc From shrdlu at deaddrop.org Wed Mar 28 13:59:28 2012 From: shrdlu at deaddrop.org (Lynda) Date: Wed, 28 Mar 2012 11:59:28 -0700 Subject: Quad-A records in Network Solutions ? In-Reply-To: <20120328185119.GB11515@hiwaay.net> References: <4F735B1B.4030909@deaddrop.org> <20120328185119.GB11515@hiwaay.net> Message-ID: <4F735F90.2060502@deaddrop.org> On 3/28/2012 11:51 AM, Chris Adams wrote: > Once upon a time, Lynda said: >> This really points out one of the biggest impediments to moving to IPv6. >> I just briefly looked at the list of registrars that are able to create >> glue records for any domain I might have that I wanted to exist in IPv6, >> and it's a very limited list. I'm currently using Pairnic, and I am >> happy with them, mostly, but moving to IPv6 is painful. > The same problem exists for DNSSEC; the number of registrars that > support both IPv6 glue and DNSSEC in their standard interfaces is > unfortunately small. True story, although Pairnic makes that one easy. I just wish they'd put up an automated interface for IPv6, but I'm happy they support it, at least. My favorite place to look for support for both is here: http://www.sixxs.net/faq/dns/?faq=ipv6glue No surprise to either of us that the column for DNSSEC is filled with yellow. :-( -- It isn't just me. http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-left-google.aspx From bicknell at ufp.org Wed Mar 28 14:03:17 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 28 Mar 2012 12:03:17 -0700 Subject: BCP38 Deployment In-Reply-To: <4F7341E1.4000804@mtcc.com> References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> <4F7341E1.4000804@mtcc.com> Message-ID: <20120328190317.GA49400@ussenterprise.ufp.org> In a message written on Wed, Mar 28, 2012 at 09:52:49AM -0700, Michael Thomas wrote: > Yeahbut, the CPE isn't trusted. It would be _nice_ for customers > to be bcp38 clueful as well, but I don't think it's _required_ for > successful deployment from the ISP's standpoint. Even with a > system like DOCSIS where the CPE is semi-trustworthy from a > provisioning/etc standpoint, I don't think I'd _count_ on them. None of the routers are "trusted" if your perspective is right. It's easy to find a path like: "Tier 1 ISP" - Regional ISP - Local Provider - Subscriber - User Techologically it may look like: Tier 1 T640 core network with 10GE handoff Regional Cisco GSR network with 1GE handoff Local 1006 to Arris CMTS Subscriber Motorola Cable Modem to NetGear SOHO Gateway User Patron with Airport Express sharing a wired connection to WiFi I don't trust any of the people in that list. More interesting from a BCP38 perspective who should be doing the filtering? If you were going to write it into law/regulation, where would you require it? Maybe all of them should, but can they from a technologial perspective? There's multi-homing in that chain somewhere. Do you require it at the first single homed place? If the subscriber is using a NetGear that does both ethernet and cell card backup and is thus multi-homed does that mean the user must do it? It's not even in my list, but re-asking my previous question why don't we go a step further and require the Operating System to do unicast RPF on-box? I think given the thorny set of issues that taking a step back and saying, "rather than a perfect solution, what gets us most of the way there the cheapest, and quick" is a good question to ask. I'm going to point to the local boxes. In my example the Netgear and Airport devices are in a posion to do super-cheap unicast RPF. They have (generally) one network behind them, and one way out. They are CPU based boxes for which this check requires no hardware changes. They don't even have enough interfaces in most cases to multi-home, so the chance of it breaking is nil. And yes, while the user may control both the end PC and these devices and thus be able to turn it off and circumvent all of this, that's really not the problem. The problem is infected machines spewing crap their owners don't know about, and just having a separate device upstream that stops it will do the job. The perfect is the enemy of the good in this case. Solving this at the consumer CPE level would remove 90-95% of the problem at zero hardware cost, a very small software cost, and a very small support cost and probably make us stop talking about this issue all together. -- 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 bicknell at ufp.org Wed Mar 28 14:05:26 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 28 Mar 2012 12:05:26 -0700 Subject: Quad-A records in Network Solutions ? In-Reply-To: <20120328185119.GB11515@hiwaay.net> References: <4F735B1B.4030909@deaddrop.org> <20120328185119.GB11515@hiwaay.net> Message-ID: <20120328190526.GB49400@ussenterprise.ufp.org> In a message written on Wed, Mar 28, 2012 at 01:51:19PM -0500, Chris Adams wrote: > The same problem exists for DNSSEC; the number of registrars that > support both IPv6 glue and DNSSEC in their standard interfaces is > unfortunately small. joker.com supports both, and has a very nice web interface to do all the work. If your current provider doesn't support both you need to vote with your dollars. There are a dozen or more choices with good IPv6 and DNSSEC support. -- 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 carlosm3011 at gmail.com Wed Mar 28 14:13:53 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Wed, 28 Mar 2012 16:13:53 -0300 Subject: Quad-A records in Network Solutions ? In-Reply-To: References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> Message-ID: <4F7362F1.7000705@gmail.com> I'm not convinced. What you mention is real, but the code they need is little more than a regular expression that can be found on Google and a 20-line script for testing lames. And a couple of weeks of testing, and I think I'm exaggerating. If they don't want to offer support for it, they can just put up some disclaimer. regards, Carlos On 3/28/12 3:55 PM, David Conrad wrote: > On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: >> I'm not a fan of conspiracy theories, but, c'mon. For a provisioning >> system, an AAAA record is just a fragging string, just like any other >> DNS record. How difficult to support can it be ? > > Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. > > Regards, > -drc > > From john.yocum at fluidhosting.com Wed Mar 28 14:16:18 2012 From: john.yocum at fluidhosting.com (John T. Yocum) Date: Wed, 28 Mar 2012 12:16:18 -0700 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F7362F1.7000705@gmail.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> Message-ID: <4F736382.2030101@fluidhosting.com> On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: > I'm not convinced. What you mention is real, but the code they need is > little more than a regular expression that can be found on Google and a > 20-line script for testing lames. And a couple of weeks of testing, and > I think I'm exaggerating. > > If they don't want to offer support for it, they can just put up some > disclaimer. > > regards, > > Carlos > > > On 3/28/12 3:55 PM, David Conrad wrote: >> On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: >>> I'm not a fan of conspiracy theories, but, c'mon. For a provisioning >>> system, an AAAA record is just a fragging string, just like any other >>> DNS record. How difficult to support can it be ? >> >> Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. >> >> Regards, >> -drc >> >> > That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. --John From mike at mtcc.com Wed Mar 28 14:44:04 2012 From: mike at mtcc.com (Michael Thomas) Date: Wed, 28 Mar 2012 12:44:04 -0700 Subject: BCP38 Deployment In-Reply-To: <20120328190317.GA49400@ussenterprise.ufp.org> References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> <4F7341E1.4000804@mtcc.com> <20120328190317.GA49400@ussenterprise.ufp.org> Message-ID: <4F736A04.20703@mtcc.com> On 03/28/2012 12:03 PM, Leo Bicknell wrote: > > None of the routers are "trusted" if your perspective is right. > > It's easy to find a path like: > > "Tier 1 ISP" - Regional ISP - Local Provider - Subscriber - User > > Techologically it may look like: > > Tier 1 T640 core network with 10GE handoff > Regional Cisco GSR network with 1GE handoff > Local 1006 to Arris CMTS > Subscriber Motorola Cable Modem to NetGear SOHO Gateway > User Patron with Airport Express sharing a wired connection to WiFi > > I don't trust any of the people in that list. More interesting > from a BCP38 perspective who should be doing the filtering? If you > were going to write it into law/regulation, where would you require > it? I wasn't talking about laws/regulation, just responding to your comment that lack of RPF in CPE was the bigger problem which doesn't seem right to me. If I'm the owner of the CMTS network, I really shouldn't be trusting the CM to be doing filtering for me. Maybe it would be nice to have RPF checks in the CM to nip a spoofed DDOS before it ever gets on the HFC network, but I wouldn't count on the CM not being compromised too, which means I should probably be running RPF on the aggregation router as well. > > Maybe all of them should, but can they from a technologial perspective? > There's multi-homing in that chain somewhere. Do you require it > at the first single homed place? If the subscriber is using a > NetGear that does both ethernet and cell card backup and is thus > multi-homed does that mean the user must do it? It's not even in > my list, but re-asking my previous question why don't we go a step > further and require the Operating System to do unicast RPF on-box? It's been a long time since I've read bcp 38, but I thought its intent was if you can reasonably do it, you *should* do it. multipath obviously makes RPF problematic, but the vast majority of the edge networks aren't multi-homed, so they really should be running RPF just as a matter of... best common practice. > > I think given the thorny set of issues that taking a step back and > saying, "rather than a perfect solution, what gets us most of the > way there the cheapest, and quick" is a good question to ask. I'm > going to point to the local boxes. In my example the Netgear and > Airport devices are in a posion to do super-cheap unicast RPF. They > have (generally) one network behind them, and one way out. They > are CPU based boxes for which this check requires no hardware > changes. They don't even have enough interfaces in most cases to > multi-home, so the chance of it breaking is nil. And yes, while > the user may control both the end PC and these devices and thus be > able to turn it off and circumvent all of this, that's really not > the problem. The problem is infected machines spewing crap their > owners don't know about, and just having a separate device upstream > that stops it will do the job. > > The perfect is the enemy of the good in this case. Solving this at the > consumer CPE level would remove 90-95% of the problem at zero hardware > cost, a very small software cost, and a very small support cost and > probably make us stop talking about this issue all together. > Except for the small problem that getting cheap home router box manufacturers to do just about anything is a pushing on string exercise. So if I want to a) protect my network and b) be a good netizen, I'm still going to want to do BCP 38 regardless of whether others violate a, b or both. Right? Mike From rbf at rbfnet.com Wed Mar 28 15:17:49 2012 From: rbf at rbfnet.com (Brett Frankenberger) Date: Wed, 28 Mar 2012 15:17:49 -0500 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F7362F1.7000705@gmail.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> Message-ID: <20120328201749.GA8918@panix.com> On Wed, Mar 28, 2012 at 04:13:53PM -0300, Carlos Martinez-Cagnazzo wrote: > I'm not convinced. What you mention is real, but the code they need is > little more than a regular expression that can be found on Google and a > 20-line script for testing lames. And a couple of weeks of testing, and > I think I'm exaggerating. > > If they don't want to offer support for it, they can just put up some > disclaimer. > > regards, > > Carlos > > > On 3/28/12 3:55 PM, David Conrad wrote: > > On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: > >> I'm not a fan of conspiracy theories, but, c'mon. For a provisioning > >> system, an AAAA record is just a fragging string, just like any other > >> DNS record. How difficult to support can it be ? > > > > Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. > > > > Regards, > > -drc > > > > > From jgreco at ns.sol.net Wed Mar 28 15:22:05 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 28 Mar 2012 15:22:05 -0500 (CDT) Subject: BCP38 Deployment In-Reply-To: Message-ID: <201203282022.q2SKM6ph064958@aurora.sol.net> > 1. Give BCP38 the only practical anti-spoofing technique, can an ISP well > protect its customers by implementing BCP38? I don't think so, because I > think BCP38 is accurate near the source but inaccurate near the > destination, i.e. if its customer is the target of spoofing attack, its > capability to filter is relatively low. Nobody seems to have corrected this point. BCP38 is not intended to protect an ISP's customers. We're used to thinking in terms of protecting ourselves; you put locks on your front door or firewalls in front of your server. That's protecting yourself. If an ISP provides firewalling for their customers, then they are using it to protect the ISP's customers. BCP38 is intended to protect the *rest* of the Internet from *you* - or, more precisely, a bad guy who has taken over your connection. If your ISP implements BCP38, they are protecting everyone *else* from spoofed packets from your connection. It provides no protection for you, though. What provides protection for you is when *other* ISP's implement BCP38. If every other ISP except yours implemented BCP38, you'd be very well protected indeed. The problem here is that BCP38 assumes that service providers will work in the best interests of the Internet in general, implementing a filter that provides no measurable RoI for the SP. It's something that reduces everyone *else's* problems. It's good to implement on that basis, but most networks don't. ... 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 bicknell at ufp.org Wed Mar 28 15:36:49 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 28 Mar 2012 13:36:49 -0700 Subject: BCP38 Deployment In-Reply-To: <4F736A04.20703@mtcc.com> References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> <4F7341E1.4000804@mtcc.com> <20120328190317.GA49400@ussenterprise.ufp.org> <4F736A04.20703@mtcc.com> Message-ID: <20120328203649.GA52866@ussenterprise.ufp.org> In a message written on Wed, Mar 28, 2012 at 12:44:04PM -0700, Michael Thomas wrote: > Except for the small problem that getting cheap home router box > manufacturers to do just about anything is a pushing on string exercise. > So if I want to a) protect my network and b) be a good netizen, I'm > still going to want to do BCP 38 regardless of whether others violate > a, b or both. Right? BCP38 has nothing to do with a), doing it on your own network doesn't really protect you from much of anything of note. It's all about b), being a good citizen, and having a leg to stand on when you try to convince others to do the same which will help protect you. But the home router vendors aren't as hard to make move as you think. True, the chance of them moving in response to the fact that BCP38 exists, or that NANOG wants them to is zero. Nada, zilch. However, there are some powerful companies that buy a lot of boxes from these vendors. That free-to-the-subscriber box with a Comcast, Verizon, Cox, Cable Vision, AT&T, SBC, or other provider label on it is just a rebranded version of one of these devices. If the guy buying several million dollars worth of the boxes showed up and demanded this feature, it would be done. Once it's done for them, it's a free "feature" they can market in the boxes at best-buy to try and recover more of their development costs. So in that sense we need to pressure the ISP's to implement BCP38! Maybe I'm back to agreeing with the OP! However we need to pressure them not to turn on RPF on their routers (although that's a fine thing too, defense in depth and all, if they can they should), but to pressure the vendors they are buying from to do it. The standards bodies should also be pressured as well, to get it into the specifications. I think some engineers need to ask some interesting questions, like how, in a box doing NAT to an outside IP, does it ever emit a packet not from that outside IP? The fact that you can spoof packets through some of the NAT implementations out there is mind-blowing to me. I'm telling you, if the big 10 ISP's would just add one bullet point to their RFP's for equipment: * Any device performing an IP routing function must default to strict mode unicast RPF for all connected networks as specified in RFC 3704 Section 2.2 as a method of implementing BCP38. We'd be done with this issue and move on to other things. Sure, there would still be spoofed packets, and yes, other types of operators (like free public wifi and such) still need to do the right BCP38 filtering when configuring their systems...but just having this on all residential gear gets rid of well over 90% of the crud we're all trying to stop. -- 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 arturo.servin at gmail.com Wed Mar 28 16:23:41 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 28 Mar 2012 23:23:41 +0200 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F736382.2030101@fluidhosting.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> <4F736382.2030101@fluidhosting.com> Message-ID: <6C312793-A175-4960-9346-2125E36EB674@gmail.com> Another reason to not use them. Seriusly, if they cannot expend some thousands of dollars (because it shouldn't be more than that) in "touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc." I cannot take them as a serious provider for my names. Regards, .as On 28 Mar 2012, at 21:16, John T. Yocum wrote: > > > On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: >> I'm not convinced. What you mention is real, but the code they need is >> little more than a regular expression that can be found on Google and a >> 20-line script for testing lames. And a couple of weeks of testing, and >> I think I'm exaggerating. >> >> If they don't want to offer support for it, they can just put up some >> disclaimer. >> >> regards, >> >> Carlos >> >> >> On 3/28/12 3:55 PM, David Conrad wrote: >>> On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: >>>> I'm not a fan of conspiracy theories, but, c'mon. For a provisioning >>>> system, an AAAA record is just a fragging string, just like any other >>>> DNS record. How difficult to support can it be ? >>> >>> Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. >>> >>> Regards, >>> -drc >>> >>> >> > > That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. > > --John From drc at virtualized.org Wed Mar 28 16:49:02 2012 From: drc at virtualized.org (David Conrad) Date: Wed, 28 Mar 2012 14:49:02 -0700 Subject: BCP38 Deployment In-Reply-To: <20120328190317.GA49400@ussenterprise.ufp.org> References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> <4F7341E1.4000804@mtcc.com> <20120328190317.GA49400@ussenterprise.ufp.org> Message-ID: On Mar 28, 2012, at 12:03 PM, Leo Bicknell wrote: > Tier 1 T640 core network with 10GE handoff > Regional Cisco GSR network with 1GE handoff > Local 1006 to Arris CMTS > Subscriber Motorola Cable Modem to NetGear SOHO Gateway > User Patron with Airport Express sharing a wired connection to WiFi > ... > If you were going to write it into law/regulation, where would you require it? Seems to me that from a legislator's perspective, there is a pretty bright (as in "moth attracted to flame") line between "subscriber" and "provider". > Maybe all of them should, but can they from a technologial perspective? Implementing telephone number portability was probably technologically more challenging for the telcos to deal with but that didn't stop the legislators from requiring it. > I think given the thorny set of issues that taking a step back and > saying, "rather than a perfect solution, what gets us most of the > way there the cheapest, and quick" is a good question to ask. You don't think that question has already been asked? It has been a dozen years since BCP38 was published. Over that period, the Internet has grown immensely and with it, the threats the ability to trivially spoofing source addresses represents. As far as I can tell, there has been little to no improvement in mechanisms to reduce those threats, yet high profile attacks against governments, departments/ministries, commercial organizations, etc., have only increased. I figure at some point (likely after a particularly high-profile attack), politicians and their corporate masters are going to feel the need to be seen to "do something about the problem." I have some skepticism that 'something' is going to be an ideal solution. > The perfect is the enemy of the good in this case. Solving this at the > consumer CPE level would remove 90-95% of the problem at zero hardware > cost, a very small software cost, and a very small support cost and > probably make us stop talking about this issue all together. And the incentive for CPE manufacturers to invest in the small software cost is? Regards, -drc From joseph.snyder at gmail.com Wed Mar 28 17:55:02 2012 From: joseph.snyder at gmail.com (Joseph Snyder) Date: Wed, 28 Mar 2012 18:55:02 -0400 Subject: Quad-A records in Network Solutions ? In-Reply-To: <6C312793-A175-4960-9346-2125E36EB674@gmail.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> <4F736382.2030101@fluidhosting.com> <6C312793-A175-4960-9346-2125E36EB674@gmail.com> Message-ID: <1b1c34a7-1446-4f95-b8d6-9b642b1eabd2@email.android.com> I agree, but in a big company it generally would cost at least 10s of thousands of dollars just for training alone. The time away from the phones that would have to be covered would exceed that. Let's say you had 8000 phone staff and they were getting $10/be and training took an hour. That is 80k coverage expenses alone. For a large company I would expect a project budget of at least 250k minimal. And probably more if the company exceeds 50,000 employees. Arturo Servin wrote: Another reason to not use them. Seriusly, if they cannot expend some thousands of dollars (because it shouldn't be more than that) in "touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc." I cannot take them as a serious provider for my names. Regards, .as On 28 Mar 2012, at 21:16, John T. Yocum wrote: > > > On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: >> I'm not convinced. What you mention is real, but the code they need is >> little more than a regular expression that can be found on Google and a >> 20-line script for testing lames. And a couple of weeks of testing, and >> I think I'm exaggerating. >> >> If they don't want to offer support for it, they can just put up some >> disclaimer. >> >> regards, >> >> Carlos >> >> >> On 3/28/12 3:55 PM, David Conrad wrote: >>> On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: >>>> I'm not a fan of conspiracy theories, but, c'mon. For a provisioning >>>> system, an AAAA record is just a fragging string, just like any other >>>> DNS record. How difficult to support can it be ? >>> >>> Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. >>> >>> Regards, >>> -drc >>> >>> >> > > That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. > > --John From arturo.servin at gmail.com Wed Mar 28 18:15:30 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Thu, 29 Mar 2012 01:15:30 +0200 Subject: Quad-A records in Network Solutions ? In-Reply-To: <1b1c34a7-1446-4f95-b8d6-9b642b1eabd2@email.android.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> <4F736382.2030101@fluidhosting.com> <6C312793-A175-4960-9346-2125E36EB674@gmail.com> <1b1c34a7-1446-4f95-b8d6-9b642b1eabd2@email.android.com> Message-ID: I am not taking about a big imaginary company. I am taking about NSI and this specific case. Regards, as On 29 Mar 2012, at 00:55, Joseph Snyder wrote: > I agree, but in a big company it generally would cost at least 10s of thousands of dollars just for training alone. The time away from the phones that would have to be covered would exceed that. Let's say you had 8000 phone staff and they were getting $10/be and training took an hour. That is 80k coverage expenses alone. For a large company I would expect a project budget of at least 250k minimal. And probably more if the company exceeds 50,000 employees. > > Arturo Servin wrote: > > Another reason to not use them. > > Seriusly, if they cannot expend some thousands of dollars (because it shouldn't be more than that) in "touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc." I cannot take them as a serious provider for my names. > > Regards, > .as > > On 28 Mar 2012, at 21:16, John T. Yocum wrote: > > > > > > > On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: > >> I'm not convinced. What you mention is real, but the code they need is > >> little more than a regular expression that can be found on Google and a > >> 20-line script for testing lames. And a couple of weeks of testing, and > >> I think I'm exaggerating. > >> > >> If they don't want to offer support for it, they can just > put up some > >> disclaimer. > >> > >> regards, > >> > >> Carlos > >> > >> > >> On 3/28/12 3:55 PM, David Conrad wrote: > >>> On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: > >>>> I'm not a fan of conspiracy theories, but, c'mon. For a provisioning > >>>> system, an AAAA record is just a fragging string, just like any other > >>>> DNS record. How difficult to support can it be ? > >>> > >>> Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the > expense. Simple business decision. > >>> > >>> Regards, > >>> -drc > >>> > >>> > >> > > > > That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. > > > > --John > > From bicknell at ufp.org Wed Mar 28 18:35:02 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 28 Mar 2012 16:35:02 -0700 Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> <4F7341E1.4000804@mtcc.com> <20120328190317.GA49400@ussenterprise.ufp.org> Message-ID: <20120328233502.GA57810@ussenterprise.ufp.org> In a message written on Wed, Mar 28, 2012 at 02:49:02PM -0700, David Conrad wrote: > On Mar 28, 2012, at 12:03 PM, Leo Bicknell wrote: > > Tier 1 T640 core network with 10GE handoff > > Regional Cisco GSR network with 1GE handoff > > Local 1006 to Arris CMTS > > Subscriber Motorola Cable Modem to NetGear SOHO Gateway > > User Patron with Airport Express sharing a wired connection to WiFi > > ... > > If you were going to write it into law/regulation, where would you require it? > > Seems to me that from a legislator's perspective, there is a pretty bright (as in "moth attracted to flame") line between "subscriber" and "provider". The counterpoint I would offer is their are the most lobbiests and lawyers on the "provider" side of that equation, and indeed in the entire stack best I can tell. > And the incentive for CPE manufacturers to invest in the small software cost is? The "provders" are large buyers of much of the CPE, and in some cases get to approve what CPE gets attached to their network. They can push this on the CPE manufacturers, and should. I suspect if legislators tried to push the issue their lobbiests and lawyers would attempt to stall and deflect, and that would be the direction. Many places already have laws that running an unsecured WiFi network is the subscriber's problem, not the providers. There's already operational and legal precident that the person running that end router should be responsible. -- 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 cb.list6 at gmail.com Wed Mar 28 18:47:36 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 28 Mar 2012 16:47:36 -0700 Subject: Quad-A records in Network Solutions ? In-Reply-To: <6C312793-A175-4960-9346-2125E36EB674@gmail.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> <4F736382.2030101@fluidhosting.com> <6C312793-A175-4960-9346-2125E36EB674@gmail.com> Message-ID: On Mar 28, 2012 2:25 PM, "Arturo Servin" @ gmail.com > wrote: > > > Another reason to not use them. > > Seriusly, if they cannot expend some thousands of dollars (because it shouldn't be more than that) in "touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc." I cannot take them as a serious provider for my names. > Not having ipv6 and your website availability tied to some overloaded cgn at an ISP you have no relationship with .... or your abuse policy just blocked what you thought was a /24 ... turns out to be verizon nat44 space for nyc ... and now x million customers can't click "buy now" .... priceless. CB > Regards, > .as > > On 28 Mar 2012, at 21:16, John T. Yocum wrote: > > > > > > > On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: > >> I'm not convinced. What you mention is real, but the code they need is > >> little more than a regular expression that can be found on Google and a > >> 20-line script for testing lames. And a couple of weeks of testing, and > >> I think I'm exaggerating. > >> > >> If they don't want to offer support for it, they can just put up some > >> disclaimer. > >> > >> regards, > >> > >> Carlos > >> > >> > >> On 3/28/12 3:55 PM, David Conrad wrote: > >>> On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: > >>>> I'm not a fan of conspiracy theories, but, c'mon. For a provisioning > >>>> system, an AAAA record is just a fragging string, just like any other > >>>> DNS record. How difficult to support can it be ? > >>> > >>> Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. > >>> > >>> Regards, > >>> -drc > >>> > >>> > >> > > > > That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. > > > > --John > > From mike at txih.com Wed Mar 28 19:19:10 2012 From: mike at txih.com (Mike Gallagher) Date: Wed, 28 Mar 2012 19:19:10 -0500 Subject: Quad-A records in Network Solutions ? In-Reply-To: <1b1c34a7-1446-4f95-b8d6-9b642b1eabd2@email.android.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> <4F736382.2030101@fluidhosting.com> <6C312793-A175-4960-9346-2125E36EB674@gmail.com> <1b1c34a7-1446-4f95-b8d6-9b642b1eabd2@email.android.com> Message-ID: <1C546208-6D04-401B-BEC9-3E73E939A075@txih.com> Doesn't netsol charge something crazy like $50/year per for domain services? If that is still the case sounds like ipv6 support for 250k is a drop in the bucket :-). Not sure why any clueful DNS admin would still use netsol though. On Mar 28, 2012, at 5:55 PM, Joseph Snyder wrote: > I agree, but in a big company it generally would cost at least 10s of thousands of dollars just for training alone. The time away from the phones that would have to be covered would exceed that. Let's say you had 8000 phone staff and they were getting $10/be and training took an hour. That is 80k coverage expenses alone. For a large company I would expect a project budget of at least 250k minimal. And probably more if the company exceeds 50,000 employees. > > Arturo Servin wrote: > > > Another reason to not use them. > > Seriusly, if they cannot expend some thousands of dollars (because it shouldn't be more than that) in "touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc." I cannot take them as a serious provider for my names.. > > Regards, > .as > > On 28 Mar 2012, at 21:16, John T. Yocum wrote: > >> >> >> On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: >>> I'm not convinced. What you mention is real, but the code they need is >>> little more than a regular expression that can be found on Google and a >>> 20-line script for testing lames. And a couple of weeks of testing, and >>> I think I'm exaggerating. >>> >>> If they don't want to offer support for it, they can just put up some >>> disclaimer. >>> >>> regards, >>> >>> Carlos >>> >>> >>> On 3/28/12 3:55 PM, David Conrad wrote: >>>> On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: >>>>> I'm not a fan of conspiracy theories, but, c'mon. For a provisioning >>>>> system, an AAAA record is just a fragging string, just like any other >>>>> DNS record. How difficult to support can it be ? >>>> >>>> Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. >>>> >>>> Regards, >>>> -drc >>>> >>>> >>> >> >> That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. >> >> --John > > From rodrick.brown at gmail.com Wed Mar 28 19:25:21 2012 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Wed, 28 Mar 2012 20:25:21 -0400 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F7362F1.7000705@gmail.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> Message-ID: <97C576F0-D1D2-4E9F-B5E0-5C85B0E581D1@gmail.com> On Mar 28, 2012, at 3:13 PM, Carlos Martinez-Cagnazzo wrote: > I'm not convinced. What you mention is real, but the code they need is > little more than a regular expression that can be found on Google and a > 20-line script for testing lames. And a couple of weeks of testing, and > I think I'm exaggerating. > > If they don't want to offer support for it, they can just put up some > disclaimer. > > regards, > > Carlos > I absolutely agree with Carlos here this has got to be a joke or likelihood of NETSOL being extremely lazy on their part possibly lack of demand? There is absolutely no valid reason an update like this shouldn't be trivial to implement unless their system was built by IBM contractors :-) The core functionality of any IP/DNS management system is the flexibility and robustness to quickly add and remove address records. No matter how bad the system was designed or implemented not being able to support new record types is a complete FAIL on all counts especially from a veteran registrar like NETSOL. Like others have stated stick it where it hurts the most and use another vendor. > > On 3/28/12 3:55 PM, David Conrad wrote: >> On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: >>> I'm not a fan of conspiracy theories, but, c'mon. For a provisioning >>> system, an AAAA record is just a fragging string, just like any other >>> DNS record. How difficult to support can it be ? >> >> Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. >> >> Regards, >> -drc >> >> > From bmanning at vacation.karoshi.com Wed Mar 28 22:00:48 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 29 Mar 2012 03:00:48 +0000 Subject: Quad-A records in Network Solutions ? In-Reply-To: References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> Message-ID: <20120329030048.GA16200@vacation.karoshi.com.> On Wed, Mar 28, 2012 at 11:55:35AM -0700, David Conrad wrote: > On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: > > I'm not a fan of conspiracy theories, but, c'mon. For a provisioning > > system, an AAAA record is just a fragging string, just like any other > > DNS record. How difficult to support can it be ? > > > Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. > > Regards, > -drc > > once, years ago, Netsol -did- have a path for injecting AAAA records. It was prototype code with the engineering team. I had records registered with them. Have since sold the domains and they moved to other registries. But they did support it for a while. /bill From shadowedstrangerlists at gmail.com Wed Mar 28 22:09:56 2012 From: shadowedstrangerlists at gmail.com (Jacob Broussard) Date: Wed, 28 Mar 2012 20:09:56 -0700 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> Message-ID: While I can't provide an average, I can say we generally have anywhere from 2-5 microwaves on most sites (with a few exceptions that only have 1, and a few that have more.) Our MWs go up to 1.6gbps. The sites aren't provisioned a set amount of bandwidth, they can use as much as they want (up to the capacity of the aggregate of their links), which almost never puts our BH anywhere near capacity, unless the ring gets cut near the pop and we have to move lots of data through just a couple of sites. (Sorry for the crappy formatting, small and barely usable phone screen.) Thanks! -Jacob On Mar 28, 2012 1:45 AM, "Anurag Bhatia" wrote: > Hi > > Nice discussion. Just a small question here - how much backhaul at present > 2G, 3G and LTE based towers have? Just curious to hear an average number. I > agree it would be a significant difference from busy street in New York to > less crowded area say in Michigan but what sort of bandwidth telcos > provision per tower? > > On fiber - I can imagine virtually unlimited bandwidth with incremental > cost of optical instruments but how much to wireless backhaul based sites? > Do they put Gigabit microwave everywhere? > > If not then say 100Mbps? If so then how end users on Verizon LTE people > individual users get 10Mbps and so on? Is that operated at high contention? > > Thanks! > > (Sent from my mobile device) > > Anurag Bhatia > http://anuragbhatia.com > On Mar 27, 2012 10:26 PM, "Alexander Harrowell" > wrote: > > > On Tue, Mar 27, 2012 at 1:45 AM, William Herrin wrote: > > > > > On Mon, Mar 26, 2012 at 8:04 PM, Jacob Broussard > > > wrote: > > > > Who knows what technology will be like in 5-10 years? That's the > whole > > > > point of what he was trying to say. Maybe wireless carriers will use > > > > visible wavelength lasers to recievers on top of customer's houses > for > > > all > > > > we know. 10 years is a LONG time for tech, and anything can happen. > > > > > > > > Regarding lasers. I agree that modulating a laser beam to carry > information > > is a great idea. Perhaps, though, we could direct the beam down some sort > > of optical pipe or waveguide to spare ourselves the refractive losses and > > keep the pigeons and rain and whatnot out of the Fresnel zone. We might > > call it an "optical wire" or "optical fibre" or something. no, it'll > never > > catch on... > > > > Hi Jacob, > > > > > > The scientists doing the basic research now know. It's referred to as > > > the "technology pipeline." When someone says, "that's in the pipeline" > > > they mean that the basic science has been discovered to make something > > > possible and now engineers are in the process of figuring out how to > > > make it _viable_. The pipeline tends to be 5 to 10 years long, so > > > basic science researchers are making the discoveries *now* which will > > > be reflected in deployed technologies 10 years from now. > > > > > > > > > I recall an Agilent Technologies presentation from a couple of years back > > that demonstrated that historically, the great majority of incremental > > capacity on cellular networks was accounted for by cell subdivision. > Better > > air interfaces help, more spectrum helps, but as the maximum system > > throughput is roughly defined by (spectral efficiency * spectrum)* number > > of cells (assuming an even traffic distribution and no intercell > > interference or re-use overhead, for the sake of a finger exercise), > > nothing beats more cells. > > > > > > As a result, the Wireless Pony will only save you if you can find a > 10GigE > > Backhaul Pony to service the extra cells. After a certain degree of > > density, you'd need almost as much fibre (and more to the point, trench > > mileage) to service a couple of small cells per street as you would to > > *pass the houses in the street with fibre*. > > > > > > One of the great things FTTH gets you is a really awesome backhaul > network > > for us cell heads. One of the reasons we were able to roll out 3G in the > > first place was that DSL got deployed and you could provision on two or a > > dozen DSL lines for a cell site. > > > > > > You can't have wireless without backhaul (barring implausible discoveries > > in fundamental mesh network theory). Most wireless capacity comes from > cell > > subdivision. Subdivision demands more backhaul. > > > > > > > There is *nothing* promising in the pipeline for wireless tech that > > > has any real chance of leading to a wide scale replacement for fiber > > > optic cable. *Nothing.* Which means that in 10 years, wireless will be > > > better, faster and cheaper but it won't have made significant inroads > > > replacing fiber to the home and business. > > > > > > 20 years is a long time. 10 years, not so much. Even for the long > > > times, we can find the future by examining the past. The duration of > > > use of the predecessor technology (twisted pair) was about 50 years > > > ubiquitously deployed to homes. From that we can make an educated > > > guess about the current one (fiber). Fiber to the home started about > > > 10 years ago leaving about 40 more before something better might > > > replace it. > > > > > > Regards, > > > Bill Herrin > > > > > > > > > > > > -- > > > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > > > 3005 Crane Dr. ...................... Web: > > > Falls Church, VA 22042-3004 > > > > > > > > > From Valdis.Kletnieks at vt.edu Wed Mar 28 22:42:57 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 28 Mar 2012 23:42:57 -0400 Subject: BCP38 Deployment In-Reply-To: Your message of "Wed, 28 Mar 2012 13:36:49 -0700." <20120328203649.GA52866@ussenterprise.ufp.org> References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120328161610.GA43005@ussenterprise.ufp.org> <4F7341E1.4000804@mtcc.com> <20120328190317.GA49400@ussenterprise.ufp.org> <4F736A04.20703@mtcc.com> <20120328203649.GA52866@ussenterprise.ufp.org> Message-ID: <93896.1332992577@turing-police.cc.vt.edu> On Wed, 28 Mar 2012 13:36:49 -0700, Leo Bicknell said: > I think some engineers need to ask some interesting questions, like > how, in a box doing NAT to an outside IP, does it ever emit a packet > not from that outside IP? The fact that you can spoof packets > through some of the NAT implementations out there is mind-blowing > to me. The mind-blowing part for me: Look at the MIT spoofing website, at what percent of the net's address space is spoofable. Then consider what percent of the net is behind a NAT (either consumer grade, or enterprise NAT). http://spoofer.csail.mit.edu/summary.php They're reporting that 20% or so (eyeballing) is unable to spoof due to a NAT. From that, and a guess of what % is *really* behind a NAT, we can make an estimate of how common this failure mode is. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bbianchi at equinix.com Thu Mar 29 01:28:12 2012 From: bbianchi at equinix.com (Brandon Bianchi) Date: Wed, 28 Mar 2012 23:28:12 -0700 Subject: Force10 E Series at the edge? In-Reply-To: <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp> References: <011a01cd0c5f$737a1720$5a6e4560$@wirezsound.com> <12EFAA890B74E14782EFB259E5A63ABC78E5A7B0@GEMINI2.psi.corp> Message-ID: <73F6E72E-FD63-4FA2-8BEC-278C8392182A@equinix.com> Brent, While the E300 can probably get your job done for more flexibility and growth I would personally steer you towards the E600 (or E600i now). It is slightly outside of your RU requirement coming in at 16 RU but it fits the bill otherwise. The main reasons I make this suggestion is due to the fact that the E600i chassis gives you numerous options. The "standard" LC memory config is 10M, however you can buy cards with an increased 40M cam as well. Also Force10 has redundant route processors but takes it a little farther. The RPM which is redundant and supports hitless failover has three CPU's. CP - Control Processor RP1 - Handles the majority of the Layer 3 protocols RP2 - Handles the majority of the Layer 2 protocols including sflow. I could have that swapped in my head but its one way or the other. On the linecards you can change your memory allocation provisioning as well if need be, granted its more useful when you have the 40M CAM cards. The E600i can also be configured two ways.. 1 as a TeraScale supporting 4x10G XFP linerate and 16x10G XFP OverSub as well as 1G, or an ExaScale supporting 10x10G linerate and 40x10G OverSub. As well as numerous 1G options as well, take a look at this chart: http://i.dell.com/sites/content/shared-content/data-sheets/en/Documents/Dell_Force10_Switch_Reference_Guide.pdf Redundancy/Availability 1+1 redundant RPMs 4:1 redundant SFMs 1+1 redundant DC PEMs 2+2 redundant AC PSMs - 200/240 VAC 3+1 redundant AC PSMs - 100/120 VAC and 200/240 VAC FTOS is quite polished these days as well, and command accounting does work. Its just not captured in the switch log, but does record just fine on the TACACS side: 2012-03-28 23:12:29 -0700 xxx.xxx.xxx.xxx bbianchi vty0 xxx.xxx.xxx.xxx stop task_id=410 timezone=UTC service=shell priv-lvl=15 cmd=show interfaces description Id be happy to answer any specific questions you may have off list as well. -Brandon I have been supporting a large Force10 install base for a few years now and can attest to On Mar 27, 2012, at 2:21 PM, Roberts, Brent wrote: Is anyone running an E300 Series Chassis at the internet edge with multiple Full BGP feeds? 95th percent would be about 300 meg of traffic. BGP session count would be between 2 and 4 Peers. 6k internal Prefix count as it stands right now. Alternative are welcome. Thought about the ASR1006 but I need some local switching as well. Full requirements include Full internet Peering over GigE Links. Fully Redundant Power Redundant "Supervisor/Route Processor" Would prefer a Small Chassis unit. (under 10u) Would also prefer a single unit as opposed to a two smaller units. ________________________________ This email and any attached files may contain confidential and/or privileged material and is intended solely for the use of the person to whom it is addressed. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete it and all attachments from your computer. Progressive Solutions is not liable for any errors or omissions in the content or transmission of this email. From sean at donelan.com Thu Mar 29 01:35:16 2012 From: sean at donelan.com (Sean Donelan) Date: Thu, 29 Mar 2012 02:35:16 -0400 (EDT) Subject: BCP38 Deployment In-Reply-To: References: Message-ID: The power of defaults. The few successful Internet security "best practice" changes have primarily resulted from changes to default settings, not trying to get ISPs, operators, sysadmins or users to change. Smurf attacks - change default directed-broadcast settings in dominant router vendors Open SMTP relays - changed default SMTP server settings in dominant SMTP software sources/vendors Windows network-level worms - changed default Windows XP/SP2 firewall settings to closed inbound Although it may take 10+ years for a product replacement cycle (Windows XP is taking a longer), the same laziness/money/ignorance reasons why its nearly impossible to get people to implement "best practices" is why a change to the default settings is so effective. The few times the new default doesn't work, the operator then has an incentive to change it. The times the default doesn't impact the operator, there is no incentive to change it. Expecting an average person (ISP, sysadmin, programmer, etc) to discover and understand many obscure configuration options which don't directly impact what they want to do isn't realistic. People tend to not pro-actively look for problems until it causes them a problem. Even worse, systems tend to revert back to defaults when a mistake or change to unrelated parts of the system are made without the user/operator realizing it. The "experts" are the people who created the open source software or vendors creating the product, not the users/customers. SSH is a rare example where operators pro-actively sought and changed their behaivor; but even then, there were probably more operators that went with the default. From ryanczak at gmail.com Thu Mar 29 06:32:47 2012 From: ryanczak at gmail.com (Matt Ryanczak) Date: Thu, 29 Mar 2012 07:32:47 -0400 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4f73d08d.c4c52a0a.5a34.4638SMTPIN_ADDED@mx.google.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4f73d08d.c4c52a0a.5a34.4638SMTPIN_ADDED@mx.google.com> Message-ID: <4F74485F.3040401@gmail.com> On 3/28/12 11:00 PM, bmanning at vacation.karoshi.com wrote: > once, years ago, Netsol -did- have a path for injecting AAAA records. It was prototype > code with the engineering team. I had records registered with them. Have since sold the domains > and they moved to other registries. But they did support it for a while. I too had AAAA with nesol years ago. It required special phone calls to special people to update. Customer support never knew what was going on regarding AAAA or IPvWhat?. I suspect all of the people there that know about these types of things have moved on. Netsol has been leaking people since their sale to web.com last year, from actual layoffs and fear of the same. ~matt From arturo.servin at gmail.com Thu Mar 29 08:25:18 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Thu, 29 Mar 2012 15:25:18 +0200 Subject: Quad-A records in Network Solutions ? In-Reply-To: <4F74485F.3040401@gmail.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4f73d08d.c4c52a0a.5a34.4638SMTPIN_ADDED@mx.google.com> <4F74485F.3040401@gmail.com> Message-ID: <35B3AF3E-45EA-4523-A668-25E251565DAF@gmail.com> Summary: Do not use NSI, if you are. Switch. /as On 29 Mar 2012, at 13:32, Matt Ryanczak wrote: > On 3/28/12 11:00 PM, bmanning at vacation.karoshi.com wrote: >> once, years ago, Netsol -did- have a path for injecting AAAA records. It was prototype >> code with the engineering team. I had records registered with them. Have since sold the domains >> and they moved to other registries. But they did support it for a while. > > I too had AAAA with nesol years ago. It required special phone calls to special people to update. Customer support never knew what was going on regarding AAAA or IPvWhat?. > > I suspect all of the people there that know about these types of things have moved on. Netsol has been leaking people since their sale to web.com last year, from actual layoffs and fear of the same. > > ~matt From bhmccie at gmail.com Thu Mar 29 08:26:40 2012 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 29 Mar 2012 08:26:40 -0500 Subject: Looking for some diversity in Alabama that does not involve ATT Fiber In-Reply-To: <4F69F778.4060505@ttec.com> References: <4F69F778.4060505@ttec.com> Message-ID: <4F746310.2070401@gmail.com> Joe, We have a wide variety of both Internet and MPLS (WAN) circuits in Alabama from AT&T and ITC/Deltacom (Now Earthlink Business). They both have a significant footprint in Alabama. Check with Earthlink Business. -Hammer- "I was a normal American nerd" -Jack Herer On 3/21/2012 10:44 AM, Joe Maimon wrote: > Hey All, > > I have a site in Alabama that could really use some additional > diversity, but apparently ATT fiber is the only game in town. > > If anybody has any options, such as fixed wireless in the 10-50mbs, > please reply to me, off-list. > > Best, > > Joe > > . > From carlosm3011 at gmail.com Thu Mar 29 08:28:27 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Thu, 29 Mar 2012 10:28:27 -0300 Subject: Quad-A records in Network Solutions ? In-Reply-To: <35B3AF3E-45EA-4523-A668-25E251565DAF@gmail.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4f73d08d.c4c52a0a.5a34.4638SMTPIN_ADDED@mx.google.com> <4F74485F.3040401@gmail.com> <35B3AF3E-45EA-4523-A668-25E251565DAF@gmail.com> Message-ID: <4F74637B.3070003@gmail.com> +1 If after all this time they haven't been able to have support for AAAA records, they are doing a really lousy job. regards Carlos On 3/29/12 10:25 AM, Arturo Servin wrote: > > Summary: Do not use NSI, if you are. Switch. > > /as > > > On 29 Mar 2012, at 13:32, Matt Ryanczak wrote: > >> On 3/28/12 11:00 PM, bmanning at vacation.karoshi.com wrote: >>> once, years ago, Netsol -did- have a path for injecting AAAA records. It was prototype >>> code with the engineering team. I had records registered with them. Have since sold the domains >>> and they moved to other registries. But they did support it for a while. >> I too had AAAA with nesol years ago. It required special phone calls to special people to update. Customer support never knew what was going on regarding AAAA or IPvWhat?. >> >> I suspect all of the people there that know about these types of things have moved on. Netsol has been leaking people since their sale to web.com last year, from actual layoffs and fear of the same. >> >> ~matt > From felipe at starbyte.net Thu Mar 29 09:36:31 2012 From: felipe at starbyte.net (Felipe Zanchet Grazziotin) Date: Thu, 29 Mar 2012 11:36:31 -0300 Subject: ifHighSpeed for 10 Gb/s port-channels In-Reply-To: References: Message-ID: Hi, On Tue, Mar 20, 2012 at 4:51 PM, Felipe Zanchet Grazziotin < felipe at starbyte.net> wrote: > Hello, > > can anyone confirm why IF-MIB::ifHighSpeed should return 0 for aggregates > of 10 Gbit/s ports? > just to confirm what all those helpful souls told me off-list: most vendors (Cisco, Juniper, NetScalar) returns ifHighSpeed as sum of current link aggregate members speed. Something like: IF-MIB::ifHighSpeed.369098752 = Gauge32: 20000 or maybe, depends on your equipment configuration or model IF-MIB::ifHighSpeed.14 = Gauge32: 20000 > > My google-foo led me to several topics on "use ifHighSpeed to 10 Gbit/s", > but none is clear on 10 Gbit/s aggregated. > > So far I could only find references pointing to IEEE Std 802.1AX-2008 > clause 6.3.1.1.16 (aAggDataRate), > mapping to IF-MIB::ifSpeed, which is locked in 4,294,967,295 (Gauge32). In > this same standard it is very specific > about ifHighSpeed: "Set to zero.". > > Or, more directly: how can one find current speed of a 10Gb/s+ link > aggregate port? > Looks like it's a vendor thing, so blame them if it's different for you. :) > > Please, answer me off-list and I promise to summarize an answer... :) > > Wish to thank you all once more, this data helped me a lot! Kindly, Felipe From tony at swalter.com Thu Mar 29 11:11:29 2012 From: tony at swalter.com (Tony Patti) Date: Thu, 29 Mar 2012 12:11:29 -0400 Subject: Quad-A records in Network Solutions ? In-Reply-To: <1C546208-6D04-401B-BEC9-3E73E939A075@txih.com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> <4F736382.2030101@fluidhosting.com> <6C312793-A175-4960-9346-2125E36EB674@gmail.com> <1b1c34a7-1446-4f95-b8d6-9b642b1eabd2@email.android.com> <1C546208-6D04-401B-BEC9-3E73E939A075@txih.com> Message-ID: <19eb01cd0dc6$9968a470$cc39ed50$@com> No, not $50, NetSol charges me in the range of $9.75 to $9.99 per year per domain name. Not defending NetSol, just clarity for the purposes of the archives. Who knows, maybe I get those rates because I mention their competitor GoDaddy :-) Tony Patti CIO S. Walter Packaging Corp. -----Original Message----- From: Mike Gallagher [mailto:mike at txih.com] Sent: Wednesday, March 28, 2012 8:19 PM To: Joseph Snyder Cc: nanog at nanog.org; Arturo Servin Subject: Re: Quad-A records in Network Solutions ? Doesn't netsol charge something crazy like $50/year per for domain services? If that is still the case sounds like ipv6 support for 250k is a drop in the bucket :-). Not sure why any clueful DNS admin would still use netsol though. On Mar 28, 2012, at 5:55 PM, Joseph Snyder wrote: > I agree, but in a big company it generally would cost at least 10s of thousands of dollars just for training alone. The time away from the phones that would have to be covered would exceed that. Let's say you had 8000 phone staff and they were getting $10/be and training took an hour. That is 80k coverage expenses alone. For a large company I would expect a project budget of at least 250k minimal. And probably more if the company exceeds 50,000 employees. > > Arturo Servin wrote: > > > Another reason to not use them. > > Seriusly, if they cannot expend some thousands of dollars (because it shouldn't be more than that) in "touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc." I cannot take them as a serious provider for my names.. > > Regards, > .as > > On 28 Mar 2012, at 21:16, John T. Yocum wrote: > >> >> >> On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: >>> I'm not convinced. What you mention is real, but the code they need >>> is little more than a regular expression that can be found on Google >>> and a 20-line script for testing lames. And a couple of weeks of >>> testing, and I think I'm exaggerating. >>> >>> If they don't want to offer support for it, they can just put up >>> some disclaimer. >>> >>> regards, >>> >>> Carlos >>> >>> >>> On 3/28/12 3:55 PM, David Conrad wrote: >>>> On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: >>>>> I'm not a fan of conspiracy theories, but, c'mon. For a >>>>> provisioning system, an AAAA record is just a fragging string, >>>>> just like any other DNS record. How difficult to support can it be ? >>>> >>>> Of course it is more than a string. It requires touching code, (hopefully) testing that code, deploying it, training customer support staff to answer questions, updating documentation, etc. Presumably Netsol did the cost/benefit analysis and decided the potential increase in revenue generated by the vast hordes of people demanding IPv6 (or the potential lost in revenue as the vast hordes transfer away) didn't justify the expense. Simple business decision. >>>> >>>> Regards, >>>> -drc >>>> >>>> >>> >> >> That's assuming their system is sanely or logically designed. It could be a total disaster of code, which makes adding such a feature a major pain. >> >> --John > > From james at freedomnet.co.nz Thu Mar 29 11:21:40 2012 From: james at freedomnet.co.nz (james jones) Date: Thu, 29 Mar 2012 12:21:40 -0400 Subject: Quad-A records in Network Solutions ? In-Reply-To: <19eb01cd0dc6$9968a470$cc39ed50$@com> References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> <4F736382.2030101@fluidhosting.com> <6C312793-A175-4960-9346-2125E36EB674@gmail.com> <1b1c34a7-1446-4f95-b8d6-9b642b1eabd2@email.android.com> <1C546208-6D04-401B-BEC9-3E73E939A075@txih.com> <19eb01cd0dc6$9968a470$cc39ed50$@com> Message-ID: Not to sound like I am trolling here, but how hard is it get VPS servers or some EC2 servers and setup your own DNS servers. Are there use cases where that is not practical? On Thu, Mar 29, 2012 at 12:11 PM, Tony Patti wrote: > No, not $50, NetSol charges me in the range of $9.75 to $9.99 per year per > domain name. > > Not defending NetSol, just clarity for the purposes of the archives. > > Who knows, maybe I get those rates because I mention their competitor > GoDaddy :-) > > Tony Patti > CIO > S. Walter Packaging Corp. > > -----Original Message----- > From: Mike Gallagher [mailto:mike at txih.com] > Sent: Wednesday, March 28, 2012 8:19 PM > To: Joseph Snyder > Cc: nanog at nanog.org; Arturo Servin > Subject: Re: Quad-A records in Network Solutions ? > > Doesn't netsol charge something crazy like $50/year per for domain > services? > If that is still the case sounds like ipv6 support for 250k is a drop in > the > bucket :-). Not sure why any clueful DNS admin would still use netsol > though. > > On Mar 28, 2012, at 5:55 PM, Joseph Snyder > wrote: > > > I agree, but in a big company it generally would cost at least 10s of > thousands of dollars just for training alone. The time away from the phones > that would have to be covered would exceed that. Let's say you had 8000 > phone staff and they were getting $10/be and training took an hour. That is > 80k coverage expenses alone. For a large company I would expect a project > budget of at least 250k minimal. And probably more if the company exceeds > 50,000 employees. > > > > Arturo Servin wrote: > > > > > > Another reason to not use them. > > > > Seriusly, if they cannot expend some thousands of dollars (because it > shouldn't be more than that) in "touching code, (hopefully) testing that > code, deploying it, training customer support staff to answer questions, > updating documentation, etc." I cannot take them as a serious provider for > my names.. > > > > Regards, > > .as > > > > On 28 Mar 2012, at 21:16, John T. Yocum wrote: > > > >> > >> > >> On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote: > >>> I'm not convinced. What you mention is real, but the code they need > >>> is little more than a regular expression that can be found on Google > >>> and a 20-line script for testing lames. And a couple of weeks of > >>> testing, and I think I'm exaggerating. > >>> > >>> If they don't want to offer support for it, they can just put up > >>> some disclaimer. > >>> > >>> regards, > >>> > >>> Carlos > >>> > >>> > >>> On 3/28/12 3:55 PM, David Conrad wrote: > >>>> On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote: > >>>>> I'm not a fan of conspiracy theories, but, c'mon. For a > >>>>> provisioning system, an AAAA record is just a fragging string, > >>>>> just like any other DNS record. How difficult to support can it be ? > >>>> > >>>> Of course it is more than a string. It requires touching code, > (hopefully) testing that code, deploying it, training customer support > staff > to answer questions, updating documentation, etc. Presumably Netsol did the > cost/benefit analysis and decided the potential increase in revenue > generated by the vast hordes of people demanding IPv6 (or the potential > lost > in revenue as the vast hordes transfer away) didn't justify the expense. > Simple business decision. > >>>> > >>>> Regards, > >>>> -drc > >>>> > >>>> > >>> > >> > >> That's assuming their system is sanely or logically designed. It could > be > a total disaster of code, which makes adding such a feature a major pain. > >> > >> --John > > > > > > > From cb.list6 at gmail.com Thu Mar 29 11:27:28 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 29 Mar 2012 09:27:28 -0700 Subject: Quad-A records in Network Solutions ? In-Reply-To: References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> <4F736382.2030101@fluidhosting.com> <6C312793-A175-4960-9346-2125E36EB674@gmail.com> <1b1c34a7-1446-4f95-b8d6-9b642b1eabd2@email.android.com> <1C546208-6D04-401B-BEC9-3E73E939A075@txih.com> <19eb01cd0dc6$9968a470$cc39ed50$@com> Message-ID: On Thu, Mar 29, 2012 at 9:21 AM, james jones wrote: > Not to sound like I am trolling here, but how hard is it get VPS servers or > some EC2 servers and setup your own DNS servers. Are there use cases where > that is not practical? > If your goal is AAAA, i assume you care about native IPv6 as mandatory feature. And, if you care about native IPv6 as a mandatory, EC2 is not your best better. They have competition that work very well in this realm of providing native IPv6. CB From eugen at leitl.org Thu Mar 29 11:34:21 2012 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 29 Mar 2012 18:34:21 +0200 Subject: airFiber Message-ID: <20120329163421.GS14482@leitl.org> Claim: 1.4 GBit/s over up to 13 km, 24 GHZ, @3 kUSD/link price point. http://www.ubnt.com/airfiber From jeroen at unfix.org Thu Mar 29 11:43:31 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 29 Mar 2012 18:43:31 +0200 Subject: Quad-A records in Network Solutions ? In-Reply-To: References: <4F735B1B.4030909@deaddrop.org> <4F735CAC.2010700@gmail.com> <4F7362F1.7000705@gmail.com> <4F736382.2030101@fluidhosting.com> <6C312793-A175-4960-9346-2125E36EB674@gmail.com> <1b1c34a7-1446-4f95-b8d6-9b642b1eabd2@email.android.com> <1C546208-6D04-401B-BEC9-3E73E939A075@txih.com> <19eb01cd0dc6$9968a470$cc39ed50$@com> Message-ID: <4F749133.5040000@unfix.org> On 2012-03-29 18:21 , james jones wrote: > Not to sound like I am trolling here, but how hard is it get VPS servers or > some EC2 servers and setup your own DNS servers. Are there use cases where > that is not practical? They tend to not do IPv6, let alone native IPv6, they also tend to be behind a IPv4 NAT (which is why lots of folks use AYIYA tunnels to give them IPv6 connectivity) and more importantly on this subject, you still need a registrar to actually link the domain name from the tld to your server and for that purpose you need glue AAAA records and not many support those, but it is getting better. Greets, Jeroen From jared at puck.nether.net Thu Mar 29 11:44:46 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 29 Mar 2012 12:44:46 -0400 Subject: airFiber In-Reply-To: <20120329163421.GS14482@leitl.org> References: <20120329163421.GS14482@leitl.org> Message-ID: <20120329164446.GA4669@puck.nether.net> On Thu, Mar 29, 2012 at 06:34:21PM +0200, Eugen Leitl wrote: > > Claim: 1.4 GBit/s over up to 13 km, 24 GHZ, @3 kUSD/link price point. > > http://www.ubnt.com/airfiber Yeah, I got this note the other day. I am very interested in hearing about folks experience with this hardware once it ships. I almost posted it in the last-mile thread. Even compared to other hardware in the space the price-performance of it for the bitrate is amazing. I also recommend watching the video they posted: http://www.ubnt.com/themes/ubiquiti/air-fiber-video.html You are leaving out that it's an unlicensed band, so you can use this to have a decent backhaul to your house just by rigging it yourself on each end. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From tim at pelican.org Thu Mar 29 11:47:02 2012 From: tim at pelican.org (Tim Franklin) Date: Thu, 29 Mar 2012 17:47:02 +0100 (BST) Subject: Quad-A records in Network Solutions ? In-Reply-To: Message-ID: > Not to sound like I am trolling here, but how hard is > it get VPS servers or some EC2 servers and setup your > own DNS servers. Are there use cases where that is not > practical? Aren't we talking about NetSol as a *registrar* and inserting quad-A glue? Or did I miss the original intention? Regards, Tim. From carlosm3011 at gmail.com Thu Mar 29 12:03:53 2012 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Thu, 29 Mar 2012 14:03:53 -0300 Subject: Quad-A records in Network Solutions ? In-Reply-To: References: Message-ID: <4F7495F9.90104@gmail.com> Apparently they support quad-A glues if you phone them and ask for them. Personally, I run my own DNS servers, but sometimes it's not an option. My friend, who originally had this issue, is in a different business line, he is not proficient in DNS server operation, and thus he's comfortable hosting his DNS somewhere. He spent one hour on the phone this morning with Netsol to see if he could create a subdomain pointing to a DNS server I operate. It was also a no-go, he got fed up with them and is changing registrars. Thanks for all the input. regards Carlos On 3/29/12 1:47 PM, Tim Franklin wrote: >> Not to sound like I am trolling here, but how hard is >> it get VPS servers or some EC2 servers and setup your >> own DNS servers. Are there use cases where that is not >> practical? > Aren't we talking about NetSol as a *registrar* and inserting quad-A glue? Or did I miss the original intention? > > Regards, > Tim. > From drew.weaver at thenap.com Thu Mar 29 12:26:09 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 29 Mar 2012 13:26:09 -0400 Subject: airFiber In-Reply-To: <20120329164446.GA4669@puck.nether.net> References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> Message-ID: I've read that it requires perfect line of sight, which makes it sometimes tricky. Thanks, -Drew -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Thursday, March 29, 2012 12:45 PM To: Eugen Leitl Cc: NANOG list Subject: Re: airFiber On Thu, Mar 29, 2012 at 06:34:21PM +0200, Eugen Leitl wrote: > > Claim: 1.4 GBit/s over up to 13 km, 24 GHZ, @3 kUSD/link price point. > > http://www.ubnt.com/airfiber Yeah, I got this note the other day. I am very interested in hearing about folks experience with this hardware once it ships. I almost posted it in the last-mile thread. Even compared to other hardware in the space the price-performance of it for the bitrate is amazing. I also recommend watching the video they posted: http://www.ubnt.com/themes/ubiquiti/air-fiber-video.html You are leaving out that it's an unlicensed band, so you can use this to have a decent backhaul to your house just by rigging it yourself on each end. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From regnauld at nsrc.org Thu Mar 29 12:30:33 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 29 Mar 2012 17:30:33 +0000 Subject: airFiber In-Reply-To: References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> Message-ID: <20120329173033.GJ60830@macbook.bluepipe.net> Drew Weaver (drew.weaver) writes: > I've read that it requires perfect line of sight, which makes it sometimes tricky. > > Thanks, > -Drew Define perfect line of sight ? How is this different from any other wireless link and the associated Fresnel zone ? http://en.wikipedia.org/wiki/Fresnel_zone Even 100 Mbit/s wireless equipment (which ubqt also happens to make great gear for, at 800 USD / link) will need unobstructed view of the remote point - and it's not all or nothing, the performance will degrade. Cheers, Phil From joshbaird at gmail.com Thu Mar 29 12:58:36 2012 From: joshbaird at gmail.com (Josh Baird) Date: Thu, 29 Mar 2012 13:58:36 -0400 Subject: airFiber In-Reply-To: <20120329173033.GJ60830@macbook.bluepipe.net> References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> Message-ID: They are taking pre-orders now for a (hopefully) June delivery. I'm at a conference now and got the rundown yesterday from Ubiquiti. This product was designed completely from the ground up by the former Motorola Canopy 100 team. It -should- deliver ~700mbit in both directions @ full duplex. Note that 24ghz is very susceptible to "rain fade" and should be used in caution in certain climates, especially at longer distances approaching 10+km. Anyhow, check the video out on ubnt.com for an introduction and technical overview - it's worth watching. Josh On Thu, Mar 29, 2012 at 1:30 PM, Phil Regnauld wrote: > Drew Weaver (drew.weaver) writes: >> I've read that it requires perfect line of sight, which makes it sometimes tricky. >> >> Thanks, >> -Drew > > ? ? ? ?Define perfect line of sight ? How is this different from any other wireless > ? ? ? ?link and the associated Fresnel zone ? > > ? ? ? ?http://en.wikipedia.org/wiki/Fresnel_zone > > ? ? ? ?Even 100 Mbit/s wireless equipment (which ubqt also happens to make great > ? ? ? ?gear for, at 800 USD / link) will need unobstructed view of the remote > ? ? ? ?point - and it's not all or nothing, the performance will degrade. > > ? ? ? ?Cheers, > ? ? ? ?Phil > > From nick at flhsi.com Thu Mar 29 13:01:46 2012 From: nick at flhsi.com (Nick Olsen) Date: Thu, 29 Mar 2012 14:01:46 -0400 Subject: airFiber Message-ID: <3631ff80$65b2bbb3$4de71797$@com> It will need perfect line of site. And won't deal with NLOS like most 2/5 ghz gear can. It's 24ghz. They claim 15Km. Maybe in the desert. In any climate with rain, Like our's here in Florida even 2 miles is going to be a stretch as 24ghz will rain fade easy. A great application for this would be like between two buildings requiring highspeed backhaul. (Were talking roof-top to roof-top of maybe a few thousand feet or more between them. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Drew Weaver" Sent: Thursday, March 29, 2012 1:27 PM To: "Jared Mauch" , "Eugen Leitl" Subject: RE: airFiber I've read that it requires perfect line of sight, which makes it sometimes tricky. Thanks, -Drew -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Thursday, March 29, 2012 12:45 PM To: Eugen Leitl Cc: NANOG list Subject: Re: airFiber On Thu, Mar 29, 2012 at 06:34:21PM +0200, Eugen Leitl wrote: > > Claim: 1.4 GBit/s over up to 13 km, 24 GHZ, @3 kUSD/link price point. > > http://www.ubnt.com/airfiber Yeah, I got this note the other day. I am very interested in hearing about folks experience with this hardware once it ships. I almost posted it in the last-mile thread. Even compared to other hardware in the space the price-performance of it for the bitrate is amazing. I also recommend watching the video they posted: http://www.ubnt.com/themes/ubiquiti/air-fiber-video.html You are leaving out that it's an unlicensed band, so you can use this to have a decent backhaul to your house just by rigging it yourself on each end. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From cook at cookreport.com Thu Mar 29 13:23:19 2012 From: cook at cookreport.com (Gordon Cook) Date: Thu, 29 Mar 2012 14:23:19 -0400 Subject: airFiber (text of the 8 minute video) In-Reply-To: References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> Message-ID: <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> On Mar 29, 2012, at 1:58 PM, Josh Baird wrote: > Anyhow, check the > video out on ubnt.com for an introduction and technical overview - > it's worth watching. The claim is a huge decline in the cost of backhaul bandwidth for wisps between 10 and 100 times. I have just finished the preparation of an extensive article on a nebraska wisp whose network is backhaul radios on towers about 5 miles apart. he is on over 100 towers across a space of 150 miles by roughly 40 miles here is the text of the video which indeed is very good Robert Pera, CEO Ubiquity: Ubiquity had a lot of strength. We had hardware design software design, mechanical design, antenna design. We had firmware and protocol design but the one thing that we were missing was really our own radio design at our old modem design. Engineer 1: The group of guys who are here have been working together for about 20 years. we collectively have a lot of experience in the wireless data world - probably more so than any other company. This team of people originally were all hired into Motorola, some of us go back to the late 1980s. We actually worked on a program called altair. Altair was one of the 1st attempts at doing in building wireless networking. It was the 1st wireless local area network product ever. It was actually the 1st time that I am aware of that anyone had actually built a broadband wireless networking product. What we did on altair continued on through Motorola and eventually became a product called canopy. Canopy is a very popular product now. It is a wireless Internet distribution system used to provide high-speed Internet people in houses where there typically is no access to cable or to DSL Gary Schulz: we had kind of run the canopy product through its maturity and did not see a lot of additional room for growth there. When the ubiquity management approached us, we were looking for the opportunity to continue to build new stuff and that's what made it very interesting to come over and work for Ubiquity Because their focus is on the new stuff. It is on working on high speed and low cost. The freedom to design at our level was just go and do it. What are you going to do? it was like start with a clean sheet of paper. start with nothing. We could build and design this product in any way we saw fit. The idea was just to be the best we could. air fiber is the start of the new product line within Ubiquity. It is the 1st of several products that are highly efficient, high data rate, wireless broadband products. Greg Bedian: Our design is something that is a little bit crazy. We are trying to build a 0 IF radio at 24 GHz and do this for a 100 MHz bandwidth which is something that I am not sure anyone else has been crazy enough to try. Chuck Macenski: As fast as you can send a packet on an ethernet wire we can receive it and transmit with no limitations. Air fiber is designed to be mounted in a reasonably high location. It is a point to point network where the 2 antennas see each other. this is a system that under certain circumstances can work up to 10 miles. It is going to be very easy to deploy and align. It is a product that is going to require only one person to carry it up the tower and install it. There is a display on the bottom that tells you what sort of power is being received as well as a very comprehensive web interface. We designed all aspects of it. The modem, the radio, the mechanical housing. This is a completely designed from scratch, purpose built solution just to deliver backhaul. So it is not based on wi-fi or anybody else's standards. As a result it does not suffer from any of the other overhead normally associated with that. Built for speed -- if you want to compare the data rates of existing products to our product, other products on the market today would give you the expected data rate of the flow of water through a garden hose. Our product will provide the flow rate of a firehose. This product will provide 1.4 Gb per second of data flow which is 300 times faster than you would normally be able to get from your own home Internet service provider. Operators will be able to get 10 to 100 times more data throughput for the same dollar. That is the big impact that this product is going to have. Rick Keniuk: we looked at 24 GHz. We actually wanted to do something up in high frequency and that happens to be the next unlicensed band beyond six gigahertz. You can put it out anywhere. You don't have to do anything. No special paperwork. No license fees. Nobody to go get permission from to operate the radio. The nice part is that it him allows anyone to operate the product and started up without any issues of having to get licenses or jump through certain hoops of where you can place the product. It is a freedom thing. Inside the air Fiber Design -- As far as I know no one builds a modem with this level of sophistication. Most people when the building modem commit to custom silicon. But doing it this way is very expensive very time-consuming. It is rigid in its architecture. If you make mistake, you cannot reprogram it. If someone wants to change a feature, it's locked in stone and too late, once it is committed. We call this a modem but there may be times that we can actually change the identity of it by loading new software into it on the fly. This programmable. It is flexible. And it can basically do whatever function you want to do. With most systems, the farther you get away, the longer the amount of time that you have to wait for the packet to actually get there. we actually have a patent pending that allows us to synchronously send packets in between radios. So that packets transmitted from both ends of the link and actually meet in space halfway in between. It does not have to wait before it transmits. In this case they are both synchronize through global positioning And they can send packets simultaneously [This next paragraph is a summary] They point out at the end that in the developing world there are many people who given the high scrap value of copper are motivated to dig up copper cables between transmission centers in order to sell the copper. And furthermore that in many cases they go looking for cables and do not understand the difference between a fiber-optic cable copper cable. When they find the cable, they cut in order to extract it. And when they see it's not fiber, they just leave it alone. The nice thing about our solution is that other than the radios themselves there is nothing you have to protect in between the point-to-point links. [End summary] When you are given an opportunity to try to create something new and do something differently than anyone else has done, as an engineer, that's always very exciting. Ubiquiti has a reputation for being very disruptive in the market place and we found hat very attractive. We like to think about products differently than anyone else. It is going to be a whole lot less costly and much higher performance than anything else that is out there right now. ============================================================= The COOK Report on Internet Protocol, (PSTN) 609 882-2572 Back Issues: http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61 Cook's Collaborative Edge Blog http://gordoncook.net/wp/ Subscription info: http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65 ============================================================= On Mar 29, 2012, at 1:58 PM, Josh Baird wrote: > Anyhow, check the > video out on ubnt.com for an introduction and technical overview - > it's worth watching. From me at anuragbhatia.com Thu Mar 29 13:25:25 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 29 Mar 2012 23:55:25 +0530 Subject: Muni Fiber (was: Re: last mile, regulatory incentives, etc) In-Reply-To: References: <30236862.7717.1332438692605.JavaMail.root@benjamin.baylink.com> <02f201cd09f6$4b251a60$e16f4f20$@iname.com> <0D25AEDC-0C20-4193-B188-4BE9DFA5C17D@delong.com> <0e9896df-924b-4fa7-af2f-f51c5e3b4d2d@email.android.com> <20120325155602.GA84752@ussenterprise.ufp.org> <4F6F73F4.3070204@gmail.com> <92177.1332705649@turing-police.cc.vt.edu> Message-ID: Thanks Jacob and Alex. Appreciate your reply. On Thu, Mar 29, 2012 at 8:39 AM, Jacob Broussard < shadowedstrangerlists at gmail.com> wrote: > While I can't provide an average, I can say we generally have anywhere > from 2-5 microwaves on most sites (with a few exceptions that only have 1, > and a few that have more.) Our MWs go up to 1.6gbps. The sites aren't > provisioned a set amount of bandwidth, they can use as much as they want > (up to the capacity of the aggregate of their links), which almost never > puts our BH anywhere near capacity, unless the ring gets cut near the pop > and we have to move lots of data through just a couple of sites. (Sorry for > the crappy formatting, small and barely usable phone screen.) > > Thanks! > -Jacob > On Mar 28, 2012 1:45 AM, "Anurag Bhatia" wrote: > >> Hi >> >> Nice discussion. Just a small question here - how much backhaul at >> present >> 2G, 3G and LTE based towers have? Just curious to hear an average number. >> I >> agree it would be a significant difference from busy street in New York >> to >> less crowded area say in Michigan but what sort of bandwidth telcos >> provision per tower? >> >> On fiber - I can imagine virtually unlimited bandwidth with incremental >> cost of optical instruments but how much to wireless backhaul based sites? >> Do they put Gigabit microwave everywhere? >> >> If not then say 100Mbps? If so then how end users on Verizon LTE people >> individual users get 10Mbps and so on? Is that operated at high >> contention? >> >> Thanks! >> >> (Sent from my mobile device) >> >> Anurag Bhatia >> http://anuragbhatia.com >> On Mar 27, 2012 10:26 PM, "Alexander Harrowell" >> wrote: >> >> > On Tue, Mar 27, 2012 at 1:45 AM, William Herrin wrote: >> > >> > > On Mon, Mar 26, 2012 at 8:04 PM, Jacob Broussard >> > > wrote: >> > > > Who knows what technology will be like in 5-10 years? That's the >> whole >> > > > point of what he was trying to say. Maybe wireless carriers will >> use >> > > > visible wavelength lasers to recievers on top of customer's houses >> for >> > > all >> > > > we know. 10 years is a LONG time for tech, and anything can happen. >> > > >> > > >> > Regarding lasers. I agree that modulating a laser beam to carry >> information >> > is a great idea. Perhaps, though, we could direct the beam down some >> sort >> > of optical pipe or waveguide to spare ourselves the refractive losses >> and >> > keep the pigeons and rain and whatnot out of the Fresnel zone. We might >> > call it an "optical wire" or "optical fibre" or something. no, it'll >> never >> > catch on... >> > >> > Hi Jacob, >> > > >> > > The scientists doing the basic research now know. It's referred to as >> > > the "technology pipeline." When someone says, "that's in the pipeline" >> > > they mean that the basic science has been discovered to make something >> > > possible and now engineers are in the process of figuring out how to >> > > make it _viable_. The pipeline tends to be 5 to 10 years long, so >> > > basic science researchers are making the discoveries *now* which will >> > > be reflected in deployed technologies 10 years from now. >> > > >> > >> > >> > I recall an Agilent Technologies presentation from a couple of years >> back >> > that demonstrated that historically, the great majority of incremental >> > capacity on cellular networks was accounted for by cell subdivision. >> Better >> > air interfaces help, more spectrum helps, but as the maximum system >> > throughput is roughly defined by (spectral efficiency * spectrum)* >> number >> > of cells (assuming an even traffic distribution and no intercell >> > interference or re-use overhead, for the sake of a finger exercise), >> > nothing beats more cells. >> > >> > >> > As a result, the Wireless Pony will only save you if you can find a >> 10GigE >> > Backhaul Pony to service the extra cells. After a certain degree of >> > density, you'd need almost as much fibre (and more to the point, trench >> > mileage) to service a couple of small cells per street as you would to >> > *pass the houses in the street with fibre*. >> > >> > >> > One of the great things FTTH gets you is a really awesome backhaul >> network >> > for us cell heads. One of the reasons we were able to roll out 3G in the >> > first place was that DSL got deployed and you could provision on two or >> a >> > dozen DSL lines for a cell site. >> > >> > >> > You can't have wireless without backhaul (barring implausible >> discoveries >> > in fundamental mesh network theory). Most wireless capacity comes from >> cell >> > subdivision. Subdivision demands more backhaul. >> > >> > >> > > There is *nothing* promising in the pipeline for wireless tech that >> > > has any real chance of leading to a wide scale replacement for fiber >> > > optic cable. *Nothing.* Which means that in 10 years, wireless will be >> > > better, faster and cheaper but it won't have made significant inroads >> > > replacing fiber to the home and business. >> > > >> > > 20 years is a long time. 10 years, not so much. Even for the long >> > > times, we can find the future by examining the past. The duration of >> > > use of the predecessor technology (twisted pair) was about 50 years >> > > ubiquitously deployed to homes. From that we can make an educated >> > > guess about the current one (fiber). Fiber to the home started about >> > > 10 years ago leaving about 40 more before something better might >> > > replace it. >> > > >> > > Regards, >> > > Bill Herrin >> > > >> > > >> > > >> > > -- >> > > William D. Herrin ................ herrin at dirtside.com >> bill at herrin.us >> > > 3005 Crane Dr. ...................... Web: >> > > Falls Church, VA 22042-3004 >> > > >> > > >> > >> > -- Anurag Bhatia anuragbhatia.com or simply - http://[2600:3c01:e000:1::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From os10rules at gmail.com Thu Mar 29 13:52:53 2012 From: os10rules at gmail.com (Greg Ihnen) Date: Thu, 29 Mar 2012 14:22:53 -0430 Subject: airFiber (text of the 8 minute video) In-Reply-To: <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> Message-ID: <5FF4C0E4-23FC-4BEC-989F-C7226186ED1C@gmail.com> Respectfully, the claim isn't a "decline in the cost of backhaul bandwidth between 10 and 100 times", the claim is "Operators will be able to get 10 to 100 times more data throughput for the same dollar." which granted is a very good thing, but it does not imply how much more money one would have to spend with a competitor to reach that bandwidth level. It is only an assumption that you would have to buy between 10 and 100 of the competitor's products and put them in parallel (not feasible anyway) to get the same performance thereby costing between 10 and 100 times a much. Logically it's possible that the competitor's product which matches AirFiber is only penny more, which it's not, but that's all one could logically conclude from UBNT's statement - for the same price you get a lot more bandwidth _not_ how much more you'd have to spend to get that performance level from a competitor. Ubiquiti gear is shattering price barriers, but I believe the difference in cost between their product and their competition's which can offer the same bandwidth is less than 10:1 and certainly not 100:1. AirFiber is reported to be $3000 a pair (both ends of the link). 100:1 would mean the competitor's cost is $300,000. I don't believe anyone else's 24 GHz UNLICENSED gear is in that price range. Also keep in mind this is unlicensed gear (think unprotected airspace). Nothing stops everyone else in town from throwing one up and soon you're drowning in a high noise floor and it goes slow or doesn't work at all. Like what's happened to 2.4GHz and 5.8GHz in a lot of places. There's few urban or semi-urban places where you still can use those frequencies for backhaul. The reason why people pay the big bucks for licenses and gear for licensed frequencies is you're buying insurance it's going to work in the future. Greg On Mar 29, 2012, at 1:53 PM, Gordon Cook wrote: > > On Mar 29, 2012, at 1:58 PM, Josh Baird wrote: > >> Anyhow, check the >> video out on ubnt.com for an introduction and technical overview - >> it's worth watching. > > The claim is a huge decline in the cost of backhaul bandwidth for wisps between 10 and 100 times. I have just finished the preparation of an extensive article on a nebraska wisp whose network is backhaul radios on towers about 5 miles apart. he is on over 100 towers across a space of 150 miles by roughly 40 miles > > here is the text of the video which indeed is very good > > Robert Pera, CEO Ubiquity: Ubiquity had a lot of strength. We had hardware design software design, mechanical design, antenna design. We had firmware and protocol design but the one thing that we were missing was really our own radio design at our old modem design. > > Engineer 1: The group of guys who are here have been working together for about 20 years. we collectively have a lot of experience in the wireless data world - probably more so than any other company. This team of people originally were all hired into Motorola, some of us go back to the late 1980s. We actually worked on a program called altair. Altair was one of the 1st attempts at doing in building wireless networking. It was the 1st wireless local area network product ever. It was actually the 1st time that I am aware of that anyone had actually built a broadband wireless networking product. > > What we did on altair continued on through Motorola and eventually became a product called canopy. Canopy is a very popular product now. It is a wireless Internet distribution system used to provide high-speed Internet people in houses where there typically is no access to cable or to DSL > > Gary Schulz: we had kind of run the canopy product through its maturity and did not see a lot of additional room for growth there. When the ubiquity management approached us, we were looking for the opportunity to continue to build new stuff and that's what made it very interesting to come over and work for Ubiquity Because their focus is on the new stuff. It is on working on high speed and low cost. > > The freedom to design at our level was just go and do it. What are you going to do? it was like start with a clean sheet of paper. start with nothing. We could build and design this product in any way we saw fit. The idea was just to be the best we could. > air fiber is the start of the new product line within Ubiquity. It is the 1st of several products that are highly efficient, high data rate, wireless broadband products. > > Greg Bedian: Our design is something that is a little bit crazy. We are trying to build a 0 IF radio at 24 GHz and do this for a 100 MHz bandwidth which is something that I am not sure anyone else has been crazy enough to try. > > Chuck Macenski: As fast as you can send a packet on an ethernet wire we can receive it and transmit with no limitations. > > Air fiber is designed to be mounted in a reasonably high location. It is a point to point network where the 2 antennas see each other. this is a system that under certain circumstances can work up to 10 miles. It is going to be very easy to deploy and align. It is a product that is going to require only one person to carry it up the tower and install it. There is a display on the bottom that tells you what sort of power is being received as well as a very comprehensive web interface. > > We designed all aspects of it. The modem, the radio, the mechanical housing. This is a completely designed from scratch, purpose built solution just to deliver backhaul. So it is not based on wi-fi or anybody else's standards. As a result it does not suffer from any of the other overhead normally associated with that. > > Built for speed -- if you want to compare the data rates of existing products to our product, other products on the market today would give you the expected data rate of the flow of water through a garden hose. Our product will provide the flow rate of a firehose. This product will provide 1.4 Gb per second of data flow which is 300 times faster than you would normally be able to get from your own home Internet service provider. > > Operators will be able to get 10 to 100 times more data throughput for the same dollar. That is the big impact that this product is going to have. > > Rick Keniuk: we looked at 24 GHz. We actually wanted to do something up in high frequency and that happens to be the next unlicensed band beyond six gigahertz. You can put it out anywhere. You don't have to do anything. No special paperwork. No license fees. Nobody to go get permission from to operate the radio. The nice part is that it him allows anyone to operate the product and started up without any issues of having to get licenses or jump through certain hoops of where you can place the product. It is a freedom thing. > > Inside the air Fiber Design -- As far as I know no one builds a modem with this level of sophistication. Most people when the building modem commit to custom silicon. But doing it this way is very expensive very time-consuming. It is rigid in its architecture. If you make mistake, you cannot reprogram it. If someone wants to change a feature, it's locked in stone and too late, once it is committed. We call this a modem but there may be times that we can actually change the identity of it by loading new software into it on the fly. This programmable. It is flexible. And it can basically do whatever function you want to do. > > With most systems, the farther you get away, the longer the amount of time that you have to wait for the packet to actually get there. we actually have a patent pending that allows us to synchronously send packets in between radios. So that packets transmitted from both ends of the link and actually meet in space halfway in between. It does not have to wait before it transmits. In this case they are both synchronize through global positioning And they can send packets simultaneously > > [This next paragraph is a summary] They point out at the end that in the developing world there are many people who given the high scrap value of copper are motivated to dig up copper cables between transmission centers in order to sell the copper. And furthermore that in many cases they go looking for cables and do not understand the difference between a fiber-optic cable copper cable. When they find the cable, they cut in order to extract it. And when they see it's not fiber, they just leave it alone. The nice thing about our solution is that other than the radios themselves there is nothing you have to protect in between the point-to-point links. [End summary] > > When you are given an opportunity to try to create something new and do something differently than anyone else has done, as an engineer, that's always very exciting. Ubiquiti has a reputation for being very disruptive in the market place and we found hat very attractive. We like to think about products differently than anyone else. It is going to be a whole lot less costly and much higher performance than anything else that is out there right now. > > > ============================================================= > The COOK Report on Internet Protocol, (PSTN) 609 882-2572 > Back Issues: http://www.cookreport.com/index.php?option=com_docman&task=cat_view&gid=37&Itemid=61 > Cook's Collaborative Edge Blog http://gordoncook.net/wp/ Subscription info: http://www.cookreport.com/index.php?option=com_content&view=article&id=54&Itemid=65 > ============================================================= > > > On Mar 29, 2012, at 1:58 PM, Josh Baird wrote: > >> Anyhow, check the >> video out on ubnt.com for an introduction and technical overview - >> it's worth watching. > From oliver at g.garraux.net Thu Mar 29 14:33:41 2012 From: oliver at g.garraux.net (Oliver Garraux) Date: Thu, 29 Mar 2012 15:33:41 -0400 Subject: airFiber (text of the 8 minute video) In-Reply-To: <5FF4C0E4-23FC-4BEC-989F-C7226186ED1C@gmail.com> References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> <5FF4C0E4-23FC-4BEC-989F-C7226186ED1C@gmail.com> Message-ID: > Also keep in mind this is unlicensed gear (think unprotected airspace). Nothing stops everyone else in town from throwing one up and soon you're drowning in a high noise floor and it goes slow or doesn't work at all. Like what's happened to 2.4GHz and 5.8GHz in a lot of places. There's few urban or semi-urban places where you still can use those frequencies for backhaul. The reason why people pay the big bucks for licenses and gear for licensed ?frequencies is you're buying insurance it's going to work in the future. > > Greg I was at Ubiquiti's conference. I don't disagree with what you're saying. Ubiquiti's take on it seemed to be that 24 Ghz would likely never be used to the extent that 2.4 / 5.8 is. They are seeing 24 Ghz as only for backhaul - no connections to end users. I guess point-to-multipoint connections aren't permitted by the FCC for 24 Ghz. AirFiber appears to be fairly highly directional. It needs to be though, as each link uses 100 Mhz, and there's only 250 Mhz available @ 24 Ghz. It also sounded like there was a decent possibility of supporting licensed 21 / 25 Ghz spectrum with AirFiber in the future. Oliver From me at anuragbhatia.com Thu Mar 29 14:36:53 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 30 Mar 2012 01:06:53 +0530 Subject: airFiber (text of the 8 minute video) In-Reply-To: References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> <5FF4C0E4-23FC-4BEC-989F-C7226186ED1C@gmail.com> Message-ID: Probably it will be a good alternate to FSO based laswer links for backhual. Probably cheaper & more reliable solution then hanging lasers between towers for backhaul? On Fri, Mar 30, 2012 at 1:03 AM, Oliver Garraux wrote: > > Also keep in mind this is unlicensed gear (think unprotected airspace). > Nothing stops everyone else in town from throwing one up and soon you're > drowning in a high noise floor and it goes slow or doesn't work at all. > Like what's happened to 2.4GHz and 5.8GHz in a lot of places. There's few > urban or semi-urban places where you still can use those frequencies for > backhaul. The reason why people pay the big bucks for licenses and gear for > licensed frequencies is you're buying insurance it's going to work in the > future. > > > > Greg > > I was at Ubiquiti's conference. I don't disagree with what you're > saying. Ubiquiti's take on it seemed to be that 24 Ghz would likely > never be used to the extent that 2.4 / 5.8 is. They are seeing 24 Ghz > as only for backhaul - no connections to end users. I guess > point-to-multipoint connections aren't permitted by the FCC for 24 > Ghz. AirFiber appears to be fairly highly directional. It needs to > be though, as each link uses 100 Mhz, and there's only 250 Mhz > available @ 24 Ghz. > > It also sounded like there was a decent possibility of supporting > licensed 21 / 25 Ghz spectrum with AirFiber in the future. > > Oliver > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2600:3c01:e000:1::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com From jof at thejof.com Thu Mar 29 14:53:17 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 29 Mar 2012 12:53:17 -0700 Subject: airFiber (text of the 8 minute video) In-Reply-To: References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> <5FF4C0E4-23FC-4BEC-989F-C7226186ED1C@gmail.com> Message-ID: On Thu, Mar 29, 2012 at 12:33 PM, Oliver Garraux wrote: > I was at Ubiquiti's conference. ?I don't disagree with what you're > saying. ?Ubiquiti's take on it seemed to be that 24 Ghz would likely > never be used to the extent that 2.4 / 5.8 is. ?They are seeing 24 Ghz > as only for backhaul - no connections to end users. I suspect this is just due to cost and practicality. ISPs, nor users will want to pay 3k USD, nor widely utilize a service that requires near-direct LOS. I could see this working well in rural or sparse areas that might not mind the transceiver. > I guess > point-to-multipoint connections aren't permitted by the FCC for 24 > Ghz. The whole point of these unlicensed bands is that their usage is not tightly controlled. I imagine hardware for use still should comply with FCC's part 15 rules though. > AirFiber appears to be fairly highly directional. It needs to > be though, as each link uses 100 Mhz, and there's only 250 Mhz > available @ 24 Ghz. Being so directional, I'm not sure that cross-talk will as much of an issue, except for dense hub-like sites. It sounds like there's some novel application of using GPS timing to make the radios spectrally orthogonal -- that's pretty cool. If they can somehow coordinate timing across point-to-point links, that would be great for sites that co-locate multiple link terminations. Overall, this looks like a pretty cool product! --j From joelja at bogus.com Thu Mar 29 16:37:24 2012 From: joelja at bogus.com (Joel jaeggli) Date: Thu, 29 Mar 2012 23:37:24 +0200 Subject: airFiber (text of the 8 minute video) In-Reply-To: References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> <5FF4C0E4-23FC-4BEC-989F-C7226186ED1C@gmail.com> Message-ID: <4F74D614.6000202@bogus.com> On 3/29/12 21:53 , Jonathan Lassoff wrote: > On Thu, Mar 29, 2012 at 12:33 PM, Oliver Garraux wrote: >> I was at Ubiquiti's conference. I don't disagree with what you're >> saying. Ubiquiti's take on it seemed to be that 24 Ghz would likely >> never be used to the extent that 2.4 / 5.8 is. They are seeing 24 Ghz >> as only for backhaul - no connections to end users. > > I suspect this is just due to cost and practicality. ISPs, nor users > will want to pay 3k USD, nor widely utilize a service that requires > near-direct LOS. > I could see this working well in rural or sparse areas that might not > mind the transceiver. Cost will continue to drop, fact of the matter is the beam width is rather narrow and they attenuate rather well so you can have a fair number of them deployed without co-channel interference. if you pack a tower full of them you're going to have issues. >> I guess >> point-to-multipoint connections aren't permitted by the FCC for 24 >> Ghz. > > The whole point of these unlicensed bands is that their usage is not > tightly controlled. I imagine hardware for use still should comply > with FCC's part 15 rules though. > >> AirFiber appears to be fairly highly directional. It needs to >> be though, as each link uses 100 Mhz, and there's only 250 Mhz >> available @ 24 Ghz. > > Being so directional, I'm not sure that cross-talk will as much of an > issue, except for dense hub-like sites. It sounds like there's some > novel application of using GPS timing to make the radios spectrally > orthogonal -- that's pretty cool. If they can somehow coordinate > timing across point-to-point links, that would be great for sites that > co-locate multiple link terminations. > > Overall, this looks like a pretty cool product! > > --j > > From jof at thejof.com Thu Mar 29 16:44:56 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 29 Mar 2012 14:44:56 -0700 Subject: airFiber (text of the 8 minute video) In-Reply-To: <4F74D614.6000202@bogus.com> References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> <5FF4C0E4-23FC-4BEC-989F-C7226186ED1C@gmail.com> <4F74D614.6000202@bogus.com> Message-ID: On Thu, Mar 29, 2012 at 2:37 PM, Joel jaeggli wrote: > Cost will continue to drop, fact of the matter is the beam width is > rather narrow and they attenuate rather well so you can have a fair > number of them deployed without co-channel interference. if you pack a > tower full of them you're going to have issues. This is exactly the kind of case that I'm thinking about (central towers). The novel thing Ubiquiti seems to do is TDMA-like channelization (like with Airmax), or by changing the coding scheme over the air to maintain orthogonality (what it sounds like this new product may be doing). --j From nanog-post at rsuc.gweep.net Thu Mar 29 17:50:52 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 29 Mar 2012 18:50:52 -0400 Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> Message-ID: <20120329225052.GA79627@gweep.net> On Wed, Mar 28, 2012 at 08:45:12AM -0700, David Conrad wrote: > Leo, > > On Mar 28, 2012, at 8:13 AM, Leo Bicknell wrote: > >> #1) Money. > >> #2) Laziness. > > > While Patrick is spot on, there is a third issue which is related > > to money and laziness, but also has some unique aspects. > > > > BCP38 makes the assumption that the ISP does some "configuration" > > to insure only properly sourced packets enter the network. That > > may have been true when BCP38 was written, but no longer accurately > > reflects how networks are built and operated. > > An interesting assertion. I haven't looked at how end-user > networks are built recently. I had assumed there continue to be > customer aggregation points within ISP infrastructure in which > BCP38-type filtering could occur. You're saying this is no longer > the case? What has replaced it? uRFP was a trivial, 0-impact feature on the cisco VXR-based CMTS platform. Assert a simple statement in the default config (along with 'ips classless' and all your other standard config elements) and job done. It assisted in reducing our abuse desk workload by eliminating a class of attacks from us, so the trivial "cost" was worth it in opex. ISTR it being on the required feature list for additional CMTS evaluations but it has been many years since I touched that kit. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From scott at sberkman.net Thu Mar 29 18:03:15 2012 From: scott at sberkman.net (Scott Berkman) Date: Thu, 29 Mar 2012 19:03:15 -0400 Subject: Looking for some diversity in Alabama that does not involve ATT Fiber In-Reply-To: <4F746310.2070401@gmail.com> References: <4F69F778.4060505@ttec.com> <4F746310.2070401@gmail.com> Message-ID: <063101cd0e00$20462830$60d27890$@sberkman.net> Someone else to check is USCarrier (http://www.uscarrier.com/), they are a smaller regional fiber transit provider I've had great experiences with in the past. They only have a few POPs in Alabama though. Good luck, -Scott -----Original Message----- From: -Hammer- [mailto:bhmccie at gmail.com] Sent: Thursday, March 29, 2012 9:27 AM To: nanog at nanog.org Subject: Re: Looking for some diversity in Alabama that does not involve ATT Fiber Joe, We have a wide variety of both Internet and MPLS (WAN) circuits in Alabama from AT&T and ITC/Deltacom (Now Earthlink Business). They both have a significant footprint in Alabama. Check with Earthlink Business. -Hammer- "I was a normal American nerd" -Jack Herer On 3/21/2012 10:44 AM, Joe Maimon wrote: > Hey All, > > I have a site in Alabama that could really use some additional > diversity, but apparently ATT fiber is the only game in town. > > If anybody has any options, such as fixed wireless in the 10-50mbs, > please reply to me, off-list. > > Best, > > Joe > > . > From owen at delong.com Thu Mar 29 18:18:18 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Mar 2012 16:18:18 -0700 Subject: airFiber (text of the 8 minute video) In-Reply-To: References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> <5FF4C0E4-23FC-4BEC-989F-C7226186ED1C@gmail.com> Message-ID: <7F9D3BC0-A630-435F-A654-2E242730777C@delong.com> On Mar 29, 2012, at 12:33 PM, Oliver Garraux wrote: >> Also keep in mind this is unlicensed gear (think unprotected airspace). Nothing stops everyone else in town from throwing one up and soon you're drowning in a high noise floor and it goes slow or doesn't work at all. Like what's happened to 2.4GHz and 5.8GHz in a lot of places. There's few urban or semi-urban places where you still can use those frequencies for backhaul. The reason why people pay the big bucks for licenses and gear for licensed frequencies is you're buying insurance it's going to work in the future. >> >> Greg > > I was at Ubiquiti's conference. I don't disagree with what you're > saying. Ubiquiti's take on it seemed to be that 24 Ghz would likely > never be used to the extent that 2.4 / 5.8 is. They are seeing 24 Ghz > as only for backhaul - no connections to end users. I guess > point-to-multipoint connections aren't permitted by the FCC for 24 > Ghz. AirFiber appears to be fairly highly directional. It needs to > be though, as each link uses 100 Mhz, and there's only 250 Mhz > available @ 24 Ghz. > > It also sounded like there was a decent possibility of supporting > licensed 21 / 25 Ghz spectrum with AirFiber in the future. > > Oliver I don't think it's an FCC issue so much as 24Ghz has so much fade tendency with atmospheric moisture that an omnidirectional antenna is about as effective as a resistor coupled to ground (i.e. dummy load). The only way you can get a signal to go any real distance at that frequency is to use a highly directional high-gain antenna at both ends. Owen From jlewis at lewis.org Thu Mar 29 18:31:26 2012 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 29 Mar 2012 19:31:26 -0400 (EDT) Subject: BCP38 Deployment In-Reply-To: <20120329225052.GA79627@gweep.net> References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120329225052.GA79627@gweep.net> Message-ID: On Thu, 29 Mar 2012, Joe Provo wrote: > uRFP was a trivial, 0-impact feature on the cisco VXR-based CMTS > platform. Assert a simple statement in the default config (along > with 'ips classless' and all your other standard config elements) uRPF: or as it's now used in ios, ip verify unicast source reachable-via rx ... I don't know what it would have to do with ip classless. It requires ip cef, but so do lots of other "features" including reasonably fast packet forwarding. > and job done. It assisted in reducing our abuse desk workload by > eliminating a class of attacks from us, so the trivial "cost" was > worth it in opex. ISTR it being on the required feature list for > additional CMTS evaluations but it has been many years since I > touched that kit. uRPF stops your customers from sending forged source address packets. Since forged source address packets are rarely traced back to their actual source, I'm not sure how configuring it on your network would reduce your abuse desk workload at all. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nanog-post at rsuc.gweep.net Thu Mar 29 18:39:39 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 29 Mar 2012 19:39:39 -0400 Subject: BCP38 Deployment In-Reply-To: References: <20120328151335.GA40955@ussenterprise.ufp.org> <20120329225052.GA79627@gweep.net> Message-ID: <20120329233939.GA94037@gweep.net> On Thu, Mar 29, 2012 at 07:31:26PM -0400, Jon Lewis wrote: > On Thu, 29 Mar 2012, Joe Provo wrote: > > >uRFP was a trivial, 0-impact feature on the cisco VXR-based CMTS > >platform. Assert a simple statement in the default config (along > >with 'ips classless' and all your other standard config elements) > > uRPF: or as it's now used in ios, > ip verify unicast source reachable-via rx ... > > I don't know what it would have to do with ip classless. Stated to counter 'config is hard' as there junk you have to do regardless. Add it to your standard specs and be done. > uRPF stops your customers from sending forged source address > packets. Since forged source address packets are rarely traced back to > their actual source, I'm not sure how configuring it on your network would > reduce your abuse desk workload at all. Guess we had better informed neighbors? :-) You caught the rhetoric; the cost was that trivial. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From brwatters at absfoc.com Thu Mar 29 19:36:43 2012 From: brwatters at absfoc.com (Brian R. Watters) Date: Thu, 29 Mar 2012 17:36:43 -0700 (PDT) Subject: Comcast Ethernet Feed In-Reply-To: Message-ID: <30107560.1217.1333067803253.JavaMail.root@mail.absfoc.com> We are about to accept a 20MEG Ethernet feed via Comcast and their fiber plant as well as a BGP feed across the same link. I have a space GIGE interface on a 7206VXR and would like to know best practice for deploying for optimal performance across this interface. Any ideas and or direction would be extremely helpful as we are seeing some real issues such as. Direct connect (without BGP) to the CPE from Comcast (Fiber to Ethernet) via a laptop gives the level of performance we would expect, However as soon as we terminate to our router via the GIGE which is set to 100MB full duplex and all flow control turned off (Negotiation auto) per Comcast and connect up via a 100MB fast Ethernet interface directly connected we get a fraction of the speed when direct connected. Ideas? BRW From bruns at 2mbit.com Thu Mar 29 19:47:11 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 29 Mar 2012 18:47:11 -0600 Subject: Comcast Ethernet Feed In-Reply-To: <30107560.1217.1333067803253.JavaMail.root@mail.absfoc.com> References: <30107560.1217.1333067803253.JavaMail.root@mail.absfoc.com> Message-ID: <4F75028F.9070109@2mbit.com> On 3/29/12 6:36 PM, Brian R. Watters wrote: > We are about to accept a 20MEG Ethernet feed via Comcast and their > fiber plant as well as a BGP feed across the same link. > > I have a space GIGE interface on a 7206VXR and would like to know > best practice for deploying for optimal performance across this > interface. > > Any ideas and or direction would be extremely helpful as we are > seeing some real issues such as. > > Direct connect (without BGP) to the CPE from Comcast (Fiber to > Ethernet) via a laptop gives the level of performance we would > expect, However as soon as we terminate to our router via the GIGE > which is set to 100MB full duplex and all flow control turned off > (Negotiation auto) per Comcast and connect up via a 100MB fast > Ethernet interface directly connected we get a fraction of the speed > when direct connected. From my own experience here with our 7200s, some of the PA based 100BaseT interfaces (ie: not on the IO module) can not negotiate 100-full, but rather only half. This leaves one end diff then the other and creates issues with performance. Try forcing both the laptop and router to 100-full and see if it helps. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jlewis at lewis.org Thu Mar 29 19:53:20 2012 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 29 Mar 2012 20:53:20 -0400 (EDT) Subject: Comcast Ethernet Feed In-Reply-To: <4F75028F.9070109@2mbit.com> References: <30107560.1217.1333067803253.JavaMail.root@mail.absfoc.com> <4F75028F.9070109@2mbit.com> Message-ID: On Thu, 29 Mar 2012, Brielle Bruns wrote: > From my own experience here with our 7200s, some of the PA based 100BaseT > interfaces (ie: not on the IO module) can not negotiate 100-full, but rather > only half. This leaves one end diff then the other and creates issues with > performance. Try forcing both the laptop and router to 100-full and see if > it helps. Those interfaces don't to auto-negotiation at all. That's why they default to 100 half. OP said they were using a Gig interface though. Maybe a copper 10/100/1000 port on an NPE-G<1|2>? I haven't used those, but I'd bet they support auto-negotiation. 1000baseT requires it. It'd be helpful to know how they've tested through the router, and if there are other connections routed through that VXR that are working at the expected rates. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From derek at derekivey.com Thu Mar 29 19:56:57 2012 From: derek at derekivey.com (Derek Ivey) Date: Thu, 29 Mar 2012 20:56:57 -0400 Subject: Comcast Ethernet Feed In-Reply-To: <4F75028F.9070109@2mbit.com> References: <30107560.1217.1333067803253.JavaMail.root@mail.absfoc.com> <4F75028F.9070109@2mbit.com> Message-ID: <1E12CEF5-1CC1-4999-BFF1-97033F423269@derekivey.com> This. We have a Comcast MetroE PtP connection between our office and our datacenter and I found that it was defaulting to half duplex. I forced both of my ends to 100 Full and it fixed my issue. Derek On Mar 29, 2012, at 8:47 PM, Brielle Bruns wrote: > On 3/29/12 6:36 PM, Brian R. Watters wrote: >> We are about to accept a 20MEG Ethernet feed via Comcast and their >> fiber plant as well as a BGP feed across the same link. >> >> I have a space GIGE interface on a 7206VXR and would like to know >> best practice for deploying for optimal performance across this >> interface. >> >> Any ideas and or direction would be extremely helpful as we are >> seeing some real issues such as. >> >> Direct connect (without BGP) to the CPE from Comcast (Fiber to >> Ethernet) via a laptop gives the level of performance we would >> expect, However as soon as we terminate to our router via the GIGE >> which is set to 100MB full duplex and all flow control turned off >> (Negotiation auto) per Comcast and connect up via a 100MB fast >> Ethernet interface directly connected we get a fraction of the speed >> when direct connected. > > > > From my own experience here with our 7200s, some of the PA based 100BaseT interfaces (ie: not on the IO module) can not negotiate 100-full, but rather only half. This leaves one end diff then the other and creates issues with performance. Try forcing both the laptop and router to 100-full and see if it helps. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From bruns at 2mbit.com Thu Mar 29 20:06:59 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 29 Mar 2012 19:06:59 -0600 Subject: Comcast Ethernet Feed In-Reply-To: References: <30107560.1217.1333067803253.JavaMail.root@mail.absfoc.com> <4F75028F.9070109@2mbit.com> Message-ID: <4F750733.6040300@2mbit.com> On 3/29/12 6:53 PM, Jon Lewis wrote: > On Thu, 29 Mar 2012, Brielle Bruns wrote: > >> From my own experience here with our 7200s, some of the PA based >> 100BaseT interfaces (ie: not on the IO module) can not negotiate >> 100-full, but rather only half. This leaves one end diff then the >> other and creates issues with performance. Try forcing both the >> laptop and router to 100-full and see if it helps. > > Those interfaces don't to auto-negotiation at all. That's why they > default to 100 half. OP said they were using a Gig interface though. > Maybe a copper 10/100/1000 port on an NPE-G<1|2>? I haven't used those, > but I'd bet they support auto-negotiation. 1000baseT requires it. I'm pretty sure the PA-FE-TX boards can do auto neg, just not 100 full (just tested with a 7507 with a VIP4 w a PA-FE-TX and a cheap 10BT hub - my 7206VXR is not powered up ATM). Believe it has something to do with the DEC ethernet chip they use (I have an older desktop that just happens to have the same DEC chipset that those do and has exactly the same problem). Based on what he said, I read his setup as having a G1 or G2 NPE, using the on-NPE gig to hook to comcast, and a PA-FE-TX in one of the PA slots. At least, that's how it sounded to me - why else use 100BaseT on a gige as most laptops and desktops in the past... 4-5 years or so have onboard gige? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Thu Mar 29 20:27:17 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 29 Mar 2012 19:27:17 -0600 Subject: Comcast Ethernet Feed In-Reply-To: <4F750733.6040300@2mbit.com> References: <30107560.1217.1333067803253.JavaMail.root@mail.absfoc.com> <4F75028F.9070109@2mbit.com> <4F750733.6040300@2mbit.com> Message-ID: <4F750BF5.8000106@2mbit.com> On 3/29/12 7:06 PM, Brielle Bruns wrote: > > I'm pretty sure the PA-FE-TX boards can do auto neg, just not 100 full > (just tested with a 7507 with a VIP4 w a PA-FE-TX and a cheap 10BT hub - > my 7206VXR is not powered up ATM). Eh, just tried again to show someone and the link didn't even come up this time. I'll toss is up to an oddity or me misreading (likely the latter). My mistake. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From brwatters at absfoc.com Thu Mar 29 20:32:12 2012 From: brwatters at absfoc.com (Brian R. Watters) Date: Thu, 29 Mar 2012 18:32:12 -0700 (PDT) Subject: Comcast Ethernet Feed In-Reply-To: <4F750733.6040300@2mbit.com> Message-ID: <16096964.1233.1333071132861.JavaMail.root@mail.absfoc.com> Your correct with your understanding of our setup, I also note on our NPE-G1 that the onboard GIGE interface will auto-negotiation and I do see the flow control is not supported via the other side (Comcast) but as soon as I refresh and view the GIG# interface again I note that flow control is turned back on and "no negotiation auto" is back on the interface cfg ?, this is certainly part of the issue .. is their a way to disable flow control on the onboard GIGE ? .. as stated Comcast does not want flow control on. Yes there are other ports on this router that perform without issue and as designed both other GIGE interfaces that are VLAN'ed and Serial interfaces that are both DS3 and a PA-4T bonded to 6MEG's. the GIGE cfg is as follows interface GigabitEthernet0/1 description Comcast Inet Feed Metro E 20MB bandwidth 100000 ip address 12.12.12.12 255.255.255.252 no ip unreachables no ip route-cache load-interval 30 duplex full speed 100 media-type rj45 no negotiation auto no cdp enable We have 2GB of memory on this router with a very light load on the CPU. On 3/29/12 6:53 PM, Jon Lewis wrote: > On Thu, 29 Mar 2012, Brielle Bruns wrote: > >> From my own experience here with our 7200s, some of the PA based >> 100BaseT interfaces (ie: not on the IO module) can not negotiate >> 100-full, but rather only half. This leaves one end diff then the >> other and creates issues with performance. Try forcing both the >> laptop and router to 100-full and see if it helps. > > Those interfaces don't to auto-negotiation at all. That's why they > default to 100 half. OP said they were using a Gig interface though. > Maybe a copper 10/100/1000 port on an NPE-G<1|2>? I haven't used those, > but I'd bet they support auto-negotiation. 1000baseT requires it. I'm pretty sure the PA-FE-TX boards can do auto neg, just not 100 full (just tested with a 7507 with a VIP4 w a PA-FE-TX and a cheap 10BT hub - my 7206VXR is not powered up ATM). Believe it has something to do with the DEC ethernet chip they use (I have an older desktop that just happens to have the same DEC chipset that those do and has exactly the same problem). Based on what he said, I read his setup as having a G1 or G2 NPE, using the on-NPE gig to hook to comcast, and a PA-FE-TX in one of the PA slots. At least, that's how it sounded to me - why else use 100BaseT on a gige as most laptops and desktops in the past... 4-5 years or so have onboard gige? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Thu Mar 29 20:42:11 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 29 Mar 2012 19:42:11 -0600 Subject: Comcast Ethernet Feed In-Reply-To: <16096964.1233.1333071132861.JavaMail.root@mail.absfoc.com> References: <16096964.1233.1333071132861.JavaMail.root@mail.absfoc.com> Message-ID: <4F750F73.9050906@2mbit.com> On 3/29/12 7:32 PM, Brian R. Watters wrote: > Your correct with your understanding of our setup, I also note on our > NPE-G1 that the onboard GIGE interface will auto-negotiation and I do > see the flow control is not supported via the other side (Comcast) > but as soon as I refresh and view the GIG# interface again I note > that flow control is turned back on and "no negotiation auto" is back > on the interface cfg ?, this is certainly part of the issue .. is > their a way to disable flow control on the onboard GIGE ? .. as > stated Comcast does not want flow control on. > > Yes there are other ports on this router that perform without issue > and as designed both other GIGE interfaces that are VLAN'ed and > Serial interfaces that are both DS3 and a PA-4T bonded to 6MEG's. How do you have the PA modules installed? Layout can make a huge difference on those given the bandwidth points system. http://www.cisco.com/en/US/docs/routers/7200/configuration/7200_port_adapter_config_guidelines/3875In.html#wp1061412 -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From brwatters at absfoc.com Thu Mar 29 20:47:30 2012 From: brwatters at absfoc.com (Brian R. Watters) Date: Thu, 29 Mar 2012 18:47:30 -0700 (PDT) Subject: Comcast Ethernet Feed In-Reply-To: <4F750F73.9050906@2mbit.com> Message-ID: <502930.1245.1333072050864.JavaMail.root@mail.absfoc.com> The GIGe is on-board with the NPE-G1 and from what I am told no bandwidth points to deal with .. the PA is in slot 4 with ZERO other traffic on that slot or the port, all other traffic that is of any real size is on the other two GIGE interfaces that are also on-board with the NPE-G1 blade. ----- Original Message ----- From: "Brielle Bruns" To: "NANOG list" Sent: Thursday, March 29, 2012 6:42:11 PM Subject: Re: Comcast Ethernet Feed On 3/29/12 7:32 PM, Brian R. Watters wrote: > Your correct with your understanding of our setup, I also note on our > NPE-G1 that the onboard GIGE interface will auto-negotiation and I do > see the flow control is not supported via the other side (Comcast) > but as soon as I refresh and view the GIG# interface again I note > that flow control is turned back on and "no negotiation auto" is back > on the interface cfg ?, this is certainly part of the issue .. is > their a way to disable flow control on the onboard GIGE ? .. as > stated Comcast does not want flow control on. > > Yes there are other ports on this router that perform without issue > and as designed both other GIGE interfaces that are VLAN'ed and > Serial interfaces that are both DS3 and a PA-4T bonded to 6MEG's. How do you have the PA modules installed? Layout can make a huge difference on those given the bandwidth points system. http://www.cisco.com/en/US/docs/routers/7200/configuration/7200_port_adapter_config_guidelines/3875In.html#wp1061412 -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org -- Brian R. Watters Director 5718 East Shields Ave ? Fresno, CA 93727 tel - (559) - 420-0205 ? fax - (559) - 272-5266 Line website | My LinkedIn | email TwitterFacebookLinkedIn From randy_94108 at yahoo.com Thu Mar 29 20:49:48 2012 From: randy_94108 at yahoo.com (Randy) Date: Thu, 29 Mar 2012 18:49:48 -0700 (PDT) Subject: Comcast Ethernet Feed In-Reply-To: <30107560.1217.1333067803253.JavaMail.root@mail.absfoc.com> Message-ID: <1333072188.90428.YahooMailClassic@web181114.mail.ne1.yahoo.com> --- On Thu, 3/29/12, Brian R. Watters wrote: > From: Brian R. Watters > Subject: Comcast Ethernet Feed > To: "NANOG list" > Date: Thursday, March 29, 2012, 5:36 PM > We are about to accept a 20MEG > Ethernet feed via Comcast and their fiber plant as well as a > BGP feed across the same link. > > I have a space GIGE interface on a 7206VXR and would like to > know best practice for deploying for optimal performance > across this interface. > > Any ideas and or direction would be extremely helpful as we > are seeing some real issues such as. > > Direct connect (without BGP) to the CPE from Comcast (Fiber > to Ethernet) via a laptop gives the level of performance we > would expect, However as soon as we terminate to our router > via the GIGE which is set to 100MB full duplex and all flow > control turned off (Negotiation auto) per Comcast and > connect up via a 100MB fast Ethernet interface directly > connected we get a fraction of the speed when direct > connected. > > Ideas? > > > BRW > A couple of questions - 1) What flavor of NPE are you using? 2) Is the GigE interface on the NPE-G1/G2 OR is this a PA? 3) Is the FaE ethernet interface that you appear to be connecting your laptop to, on a separate PA in chassis? 4) Have you verified you that "bandwidth-points" have not been exceeded for bus-1 and/or 2: slots 1,3,5 for bus1 and 2,4,6; also 0(if I/O controller is present. It is 600 points for bus1 and 600 for bus2. (A sh ver will provice the info) You can google: "Cisco 7200 Series Port Adapter Hardware Configuration Guidelines" for additional info. Finally, Have you *hard-coded* speed and duplex on any of you eth ints? Please don't! Let both ints auto-negotiate speed&duplex. after having done so, post the output of: sh int gi x/y and sh int fa x/y (hardcoding speed/duplex is sometimes required when dealing with brain-dead CPE. I have also seen other flavors of brain-dead CPE that *only* work when speed/duplex are set to auto) ./Randy From ianh at ianh.net.au Thu Mar 29 20:50:14 2012 From: ianh at ianh.net.au (Ian Henderson) Date: Fri, 30 Mar 2012 12:50:14 +1100 Subject: Comcast Ethernet Feed In-Reply-To: <16096964.1233.1333071132861.JavaMail.root@mail.absfoc.com> References: <16096964.1233.1333071132861.JavaMail.root@mail.absfoc.com> Message-ID: <71B86F62-9414-48CD-BFEF-0760082EE1CE@ianh.net.au> On 30/03/2012, at 12:32 PM, Brian R. Watters wrote: > interface GigabitEthernet0/1 > description Comcast Inet Feed Metro E 20MB > bandwidth 100000 > ip address 12.12.12.12 255.255.255.252 > no ip unreachables > no ip route-cache > load-interval 30 > duplex full > speed 100 > media-type rj45 > no negotiation auto > no cdp enable Remove 'no ip route-cache'. This will be forcing all traffic via the slowest path possible. From brwatters at absfoc.com Thu Mar 29 21:02:49 2012 From: brwatters at absfoc.com (Brian R. Watters) Date: Thu, 29 Mar 2012 19:02:49 -0700 (PDT) Subject: Comcast Ethernet Feed In-Reply-To: <1333072188.90428.YahooMailClassic@web181114.mail.ne1.yahoo.com> Message-ID: <4884832.1249.1333072968959.JavaMail.root@mail.absfoc.com> A couple of questions - 1) What flavor of NPE are you using? NPE-G1 2) Is the GigE interface on the NPE-G1/G2 OR is this a PA? 3) Is the FaE ethernet interface that you appear to be connecting your laptop to, on a separate PA in chassis? Laptop connected directly to router via slot 4 PA-FE-TX 4) Have you verified you that "bandwidth-points" have not been exceeded for bus-1 and/or 2: slots 1,3,5 for bus1 and 2,4,6; also 0(if I/O controller is present. It is 600 points for bus1 and 600 for bus2. PCI bus mb1 has 390 bandwidth points PCI bus mb2 has 500 bandwidth points Have you *hard-coded* speed and duplex on any of you eth ints? Please don't! GIGE has been both hard and auto .. same results .. Fast Ether has always been set @ auto Let both ints auto-negotiate speed&duplex. Comcast states that we are required to have a hard code FULL DUPLEX and SPEED 100 as well as flow control OFF however I can not appear to be able to disable it :( after having done so, post the output of: sh int gi x/y and sh int fa x/y (hardcoding speed/duplex is sometimes required when dealing with brain-dead CPE. I have also seen other flavors of brain-dead CPE that *only* work when speed/duplex are set to auto) ./Randy From jneiberger at gmail.com Thu Mar 29 21:16:53 2012 From: jneiberger at gmail.com (John Neiberger) Date: Thu, 29 Mar 2012 20:16:53 -0600 Subject: Comcast Ethernet Feed In-Reply-To: <4884832.1249.1333072968959.JavaMail.root@mail.absfoc.com> References: <1333072188.90428.YahooMailClassic@web181114.mail.ne1.yahoo.com> <4884832.1249.1333072968959.JavaMail.root@mail.absfoc.com> Message-ID: On Thu, Mar 29, 2012 at 8:02 PM, Brian R. Watters wrote: > > > A couple of questions - > > 1) What flavor of NPE are you using? > > NPE-G1 > > 2) Is the GigE interface on the NPE-G1/G2 ?OR is this a PA? > 3) Is the FaE ethernet interface that you appear to be connecting your laptop to, on a separate PA in chassis? > > Laptop connected directly to router via slot 4 ?PA-FE-TX > > 4) Have you verified you that "bandwidth-points" have not been exceeded for bus-1 and/or 2: slots 1,3,5 for bus1 and 2,4,6; also 0(if I/O controller is present. It is 600 points for bus1 and 600 for bus2. > > PCI bus mb1 has 390 bandwidth points > PCI bus mb2 has 500 bandwidth points > > > Have you *hard-coded* speed and duplex on any of you eth ints? Please don't! > > GIGE has been both hard and auto .. same results .. Fast Ether has always been set @ auto > > Let both ints auto-negotiate speed&duplex. > > Comcast states that we are required to have a hard code FULL DUPLEX and SPEED 100 as well as flow control OFF however I can not appear to be able to disable it :( If the Comcast side is hard-coded to 100/Full then you really only have one choice, set your side to 100/Full, as well. For the past decade, Cisco gear completely disables autonegotiation if you hard set the speed and duplex settings. Some equipment still participates in auto even when you hard set it. That's why you occasionally get duplex mismatches even when both sides are hard set. The side that participates in auto will expect to see an autonegotiating link partner. When it doesn't see one, it drops back to half duplex because it assumes it is connected to a hub (This is for Fast Ethernet.) So, if you connect a piece of Cisco gear and it is hard set to 100/full, you'll be fine. If you connect a laptop or some other device with a NIC that still participates in auto even when you hard set the settings, you won't get that to work well. From randy_94108 at yahoo.com Thu Mar 29 21:32:58 2012 From: randy_94108 at yahoo.com (Randy) Date: Thu, 29 Mar 2012 19:32:58 -0700 (PDT) Subject: Comcast Ethernet Feed In-Reply-To: <4884832.1249.1333072968959.JavaMail.root@mail.absfoc.com> Message-ID: <1333074778.32916.YahooMailClassic@web181119.mail.ne1.yahoo.com> Never mind control and what Comcast says about hard-coding speed and duplex! The question is: What happens when you set the int facing Comcast CPE to auto? Does the link even come up? *IF* the link comes up, can you ping your next-hop? If you can, leave auto-neg on despite what what Comcast may say/require. Post a "sh int gix/y" and "sh int fax/y" If the above outputs are *clean*, I would say a TAC case is called for. --- On Thu, 3/29/12, Brian R. Watters wrote: > From: Brian R. Watters > Subject: Re: Comcast Ethernet Feed > To: "Randy" > Cc: "NANOG list" > Date: Thursday, March 29, 2012, 7:02 PM > > > A couple of questions - > > 1) What flavor of NPE are you using? > > NPE-G1 > > 2) Is the GigE interface on the NPE-G1/G2? OR is this a > PA? > 3) Is the FaE ethernet interface that you appear to be > connecting your laptop to, on a separate PA in chassis? > > Laptop connected directly to router via slot 4? > PA-FE-TX > > 4) Have you verified you that "bandwidth-points" have not > been exceeded for bus-1 and/or 2: slots 1,3,5 for bus1 and > 2,4,6; also 0(if I/O controller is present. It is 600 points > for bus1 and 600 for bus2. > > PCI bus mb1 has 390 bandwidth points > PCI bus mb2 has 500 bandwidth points > > > Have you *hard-coded* speed and duplex on any of you eth > ints? Please don't! > > GIGE has been both hard and auto .. same results .. Fast > Ether has always been set @ auto > > Let both ints auto-negotiate speed&duplex. > > Comcast states that we are required to have a hard code FULL > DUPLEX and SPEED 100 as well as flow control OFF however I > can not appear to be able to disable it :( > > > after having done so, post the output of: > > sh int gi x/y and sh int fa x/y > > (hardcoding speed/duplex is sometimes required when dealing > with brain-dead CPE. I have also seen other flavors of > brain-dead CPE that *only* work when speed/duplex are set to > auto) > > ./Randy > > From nathana at fsr.com Fri Mar 30 00:07:15 2012 From: nathana at fsr.com (Nathan Anderson) Date: Thu, 29 Mar 2012 22:07:15 -0700 Subject: Comcast Ethernet Feed In-Reply-To: <4884832.1249.1333072968959.JavaMail.root@mail.absfoc.com> References: <1333072188.90428.YahooMailClassic@web181114.mail.ne1.yahoo.com> <4884832.1249.1333072968959.JavaMail.root@mail.absfoc.com> Message-ID: On Thursday, March 29, 2012 7:03 PM, Brian R. Watters wrote: [snip] > Fast Ether has always been set @ auto Just in case you missed it, I would echo Brielle's earlier advice: please try forcing both laptop and the FE it's plugged into to 100/Full, auto disabled, and try your tests again. I feel like this thread has developed an unhealthy fixation with the GE <-> Comcast segment when it's just as likely that it's working perfectly fine and the problem is between Laptop <-> FE. :-) For whatever reason, I have historically had very bad luck/experience with 7200 FE interfaces and auto-negotiation, FWIW. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From tlyons at ivenue.com Fri Mar 30 08:01:36 2012 From: tlyons at ivenue.com (Todd Lyons) Date: Fri, 30 Mar 2012 06:01:36 -0700 Subject: Comcast Ethernet Feed In-Reply-To: References: <1333072188.90428.YahooMailClassic@web181114.mail.ne1.yahoo.com> <4884832.1249.1333072968959.JavaMail.root@mail.absfoc.com> Message-ID: On Thu, Mar 29, 2012 at 10:07 PM, Nathan Anderson wrote: > On Thursday, March 29, 2012 7:03 PM, Brian R. Watters wrote: > > [snip] > >> Fast Ether has always been set @ auto > > Just in case you missed it, I would echo Brielle's earlier advice: please try forcing both laptop and the FE it's plugged into to 100/Full, auto disabled, and try your tests again. ?I feel like this thread has developed an unhealthy fixation with the GE <-> Comcast segment when it's just as likely that it's working perfectly fine and the problem is between Laptop <-> FE. :-) > For whatever reason, I have historically had very bad luck/experience with 7200 FE interfaces and auto-negotiation, FWIW. Ditto! Plug laptop_2 into one of the FE ports and see if you get good speeds between the laptops. On the 7200, show interface for each of the FE ports, compare to what the laptops think it has. Our 7200's have FE ports that have to be hard coded to get full duplex. (We no longer have that issue since almost all 7200's have only GigE ports, we only have one 7204 with a FE port and it's the only one that's hard coded to duplex full). ...Todd -- Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Martin Golding From cgrosskopf at scoe.org Fri Mar 30 10:10:45 2012 From: cgrosskopf at scoe.org (Cody Grosskopf) Date: Fri, 30 Mar 2012 08:10:45 -0700 (PDT) Subject: Comcast Ethernet Feed In-Reply-To: <30107560.1217.1333067803253.JavaMail.root@mail.absfoc.com> Message-ID: <910201995.4273457.1333120245863.JavaMail.root@zimbra.scoe.org> What does Comcast do if you exceed 20 meg? We were told by AT&T that anything over the specified limit would be dropped, so we use rate limiting...not sure if Comcast does the same. Cody ----- Original Message ----- From: "Brian R. Watters" To: "NANOG list" Sent: Thursday, March 29, 2012 5:36:43 PM Subject: Comcast Ethernet Feed We are about to accept a 20MEG Ethernet feed via Comcast and their fiber plant as well as a BGP feed across the same link. I have a space GIGE interface on a 7206VXR and would like to know best practice for deploying for optimal performance across this interface. Any ideas and or direction would be extremely helpful as we are seeing some real issues such as. Direct connect (without BGP) to the CPE from Comcast (Fiber to Ethernet) via a laptop gives the level of performance we would expect, However as soon as we terminate to our router via the GIGE which is set to 100MB full duplex and all flow control turned off (Negotiation auto) per Comcast and connect up via a 100MB fast Ethernet interface directly connected we get a fraction of the speed when direct connected. Ideas? BRW Notice to Recipient: Information contained in this message may be privileged, confidential and protected from disclosure. If you are not an intended recipient, it is strictly prohibited to use, disseminate or copy this communication. If you have received this in error, please reply to the sender and then delete the message.Thank you. From rmaunier at neotelecoms.com Fri Mar 30 13:21:48 2012 From: rmaunier at neotelecoms.com (Raphael MAUNIER) Date: Fri, 30 Mar 2012 18:21:48 +0000 Subject: French Regulator to ask all your information about your Peering Message-ID: Hello All, This is now the end. The French regulator ( Arcep ) is now asking all the people with an ASN in France ( with a L33 license ) to get all their information on their peering. The Arcep claim it's for the "net neutrality" and still don't understand it works because it's self regulated. So, some of US network with a L33 License will also have to respond ( obligation because you have the L33-1) The documents can be downloaded here http://www.arcep.fr/index.php?id=8571&L=&tx_gsactualite_pi1[uid]=1508&tx_gs actualite_pi1[backID]=1&cHash=ed82d44a55 : ( french for now, english courtesy version will come soon ) The document is asking for informations like : BW, Prices, contract or not, level of use, date of the contract S You have to give them information twice a year We ( @Neo Telecoms ) and other folks in France will probably setup something with other carriers ( I already had some discussion with some of you ) to talk to them on a single voice. -- Rapha?l Maunier NEO TELECOMS CTO / Directeur Ing?nierie AS8218 From woody at pch.net Fri Mar 30 13:27:07 2012 From: woody at pch.net (Bill Woodcock) Date: Fri, 30 Mar 2012 11:27:07 -0700 Subject: French Regulator to ask all your information about your Peering In-Reply-To: References: Message-ID: <7FF80F49-7F29-426B-B701-DDEA23B70A05@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mar 30, 2012, at 11:21 AM, Raphael MAUNIER wrote: > Hello All, > > This is now the end. The French regulator ( Arcep ) is now asking all the > people with an ASN in France ( with a L33 license ) to get all their > information on their peering. > > The Arcep claim it's for the "net neutrality" and still don't understand > it works because it's self regulated. > > So, some of US network with a L33 License will also have to respond ( > obligation because you have the L33-1) > > The documents can be downloaded here > http://www.arcep.fr/index.php?id=8571&L=&tx_gsactualite_pi1[uid]=1508&tx_gs > actualite_pi1[backID]=1&cHash=ed82d44a55 : ( french for now, english > courtesy version will come soon ) > > The document is asking for informations like : BW, Prices, contract or > not, level of use, date of the contract S > > You have to give them information twice a year For those anglophones following this from afar, Malcolm Hutty's excellent submission is relevant to your interests: https://publicaffairs.linx.net/news/wp-content/uploads/2012/02/ARCEP-2012-02-09-FINAL.pdf -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPdfr7AAoJEG+kcEsoi3+HpAEQALR2kyVDVqiVWnGVps3UUcRZ +BxdiGEmcmmI+ZvDopR1vz00hzcojp3C+7tKQ7oCnabVKISgsN4egF9WTR03Xahp TNSQqgDRf7mph2RGba5S/DAt1QEHfdSwRGVv+egjtJE7en7k2E90MU1q3rkT2y9P gKRNusd4m4I0rIRFm4G6WVMy2O6VmWqtgQcUyHzj6yocl84jf+yO2KfyxsLwz5PM Sln3oE7wKsFqtwf8uTxrEdslVTcbzCQ5ZgkNVdVXO/KiMbXe37IHjDZIZ4v1bUtq NcqznnVSlKoMUgGFOJ1dRocWOw4JcgxD+U3xTHx3xRyx3ggwnG0gjpp38198wFVw 1B5pIJ+I7UIOM4lDtSV5gJYlxA1YKYXHcktyqyAVtCh+4oPWiHKhFtpsFv77lrhl NOGy5NC66YN+u8Bpmo7l+2Z1yLqJmasLsmRazOm81V6wMzwiCF9ZEJsbU+ULz7Rc ObzvpqD585ObkCUVJYmjk1IptxJJOMBhX6qbBnlf2UlU2BhY/+r/EGu10EB8XNMw U8QW0CNIUucgVNHdLWoIdIakij7wuSlJEGoNiK6BVTi6TqJe5eZRXH5OSGYx4QrE BQ0iG7nTf7LFUo+W07G5hscfvCUZSBV/iL6O69T3zcmc3jqG544iIjcnASTeol8R 5rBSLVqixj5fwP4ephyb =dNaW -----END PGP SIGNATURE----- From nanog at stefan-neufeind.de Fri Mar 30 13:29:03 2012 From: nanog at stefan-neufeind.de (Stefan Neufeind) Date: Fri, 30 Mar 2012 20:29:03 +0200 Subject: French Regulator to ask all your information about your Peering In-Reply-To: References: Message-ID: <4F75FB6F.3080501@stefan-neufeind.de> On 03/30/2012 08:21 PM, Raphael MAUNIER wrote: > > This is now the end. The French regulator ( Arcep ) is now asking all the > people with an ASN in France ( with a L33 license ) to get all their > information on their peering. [...] > You have to give them information twice a year Well, then for a few hundered peerings send them one letter each and wait for a reaction :-) Cheers, Stefan From brunner at nic-naa.net Fri Mar 30 13:43:50 2012 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 30 Mar 2012 14:43:50 -0400 Subject: French Regulator to ask all your information about your Peering In-Reply-To: <7FF80F49-7F29-426B-B701-DDEA23B70A05@pch.net> References: <7FF80F49-7F29-426B-B701-DDEA23B70A05@pch.net> Message-ID: <4F75FEE6.2030703@nic-naa.net> interesting discussion of jurisdiction. > In the present instance, we regard ARCEP?s proposed reporting requirement as constituting an extra- > territorial obligation that ought not to be applied to operators who are neither established in France nor > directly providing services within France, merely by virtue of their interconnecting with a network that > does operate in France. > > Similar considerations apply, mutatis mutandis, to the application of a reporting requirement to the > providers of content services established and operating outside France. We do not consider the provision > of content in the French language to be sufficient, by itself, to place the content provider within ARCEP?s > jurisdiction. > > We consider this lack of jurisdiction to be sufficient reason for ARCEP to withdraw categories (b) and (d) > from the scope of persons enumerated in Article 1 of the Draft Decision. -e From mblanche at google.com Fri Mar 30 13:50:43 2012 From: mblanche at google.com (Mike Blanche) Date: Fri, 30 Mar 2012 19:50:43 +0100 Subject: French Regulator to ask all your information about your Peering In-Reply-To: <7FF80F49-7F29-426B-B701-DDEA23B70A05@pch.net> References: <7FF80F49-7F29-426B-B701-DDEA23B70A05@pch.net> Message-ID: On 30 March 2012 19:27, Bill Woodcock wrote: > For those anglophones following this from afar, Malcolm Hutty's excellent > submission is relevant to your interests: > > > https://publicaffairs.linx.net/news/wp-content/uploads/2012/02/ARCEP-2012-02-09-FINAL.pdf > > And here is who is caught: http://www.arcep.fr/index.php?id=9320 That's quite a big list. :-( (assuming I understand that list to be everyone licenced under L33-1) Mike -- Mike Blanche / mblanche at google.com / +44 7917 635 931 Google Peering & Content Distribution - Europe, Middle East and Africa From cscora at apnic.net Fri Mar 30 13:59:57 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 Mar 2012 04:59:57 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201203301859.q2UIxvJf016509@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 31 Mar, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 403929 Prefixes after maximum aggregation: 171635 Deaggregation factor: 2.35 Unique aggregates announced to Internet: 195814 Total ASes present in the Internet Routing Table: 40542 Prefixes per ASN: 9.96 Origin-only ASes present in the Internet Routing Table: 32969 Origin ASes announcing only one prefix: 15468 Transit ASes present in the Internet Routing Table: 5416 Transit-only ASes present in the Internet Routing Table: 140 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 32 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 555 Unregistered ASNs in the Routing Table: 265 Number of 32-bit ASNs allocated by the RIRs: 2342 Number of 32-bit ASNs visible in the Routing Table: 2157 Prefixes from 32-bit ASNs in the Routing Table: 5295 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 1252 Number of addresses announced to Internet: 2531398224 Equivalent to 150 /8s, 226 /16s and 18 /24s Percentage of available address space announced: 68.3 Percentage of allocated address space announced: 68.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 92.1 Total number of prefixes smaller than registry allocations: 171545 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 98994 Total APNIC prefixes after maximum aggregation: 32099 APNIC Deaggregation factor: 3.08 Prefixes being announced from the APNIC address blocks: 95394 Unique aggregates announced from the APNIC address blocks: 39244 APNIC Region origin ASes present in the Internet Routing Table: 4680 APNIC Prefixes per ASN: 20.38 APNIC Region origin ASes announcing only one prefix: 1238 APNIC Region transit ASes present in the Internet Routing Table: 730 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 19 Number of APNIC region 32-bit ASNs visible in the Routing Table: 171 Number of APNIC addresses announced to Internet: 642314080 Equivalent to 38 /8s, 72 /16s and 239 /24s Percentage of available APNIC address space announced: 81.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-132095, 132096-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 149258 Total ARIN prefixes after maximum aggregation: 75828 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 120636 Unique aggregates announced from the ARIN address blocks: 49969 ARIN Region origin ASes present in the Internet Routing Table: 14935 ARIN Prefixes per ASN: 8.08 ARIN Region origin ASes announcing only one prefix: 5686 ARIN Region transit ASes present in the Internet Routing Table: 1569 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 22 Number of ARIN region 32-bit ASNs visible in the Routing Table: 16 Number of ARIN addresses announced to Internet: 805141184 Equivalent to 47 /8s, 253 /16s and 122 /24s Percentage of available ARIN address space announced: 64.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 100814 Total RIPE prefixes after maximum aggregation: 53186 RIPE Deaggregation factor: 1.90 Prefixes being announced from the RIPE address blocks: 92127 Unique aggregates announced from the RIPE address blocks: 57226 RIPE Region origin ASes present in the Internet Routing Table: 16345 RIPE Prefixes per ASN: 5.64 RIPE Region origin ASes announcing only one prefix: 7946 RIPE Region transit ASes present in the Internet Routing Table: 2622 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1462 Number of RIPE addresses announced to Internet: 502238984 Equivalent to 29 /8s, 239 /16s and 143 /24s Percentage of available RIPE address space announced: 80.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 40250 Total LACNIC prefixes after maximum aggregation: 8151 LACNIC Deaggregation factor: 4.94 Prefixes being announced from the LACNIC address blocks: 39809 Unique aggregates announced from the LACNIC address blocks: 19696 LACNIC Region origin ASes present in the Internet Routing Table: 1574 LACNIC Prefixes per ASN: 25.29 LACNIC Region origin ASes announcing only one prefix: 434 LACNIC Region transit ASes present in the Internet Routing Table: 295 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 21 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 503 Number of LACNIC addresses announced to Internet: 98765960 Equivalent to 5 /8s, 227 /16s and 12 /24s Percentage of available LACNIC address space announced: 65.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 8916 Total AfriNIC prefixes after maximum aggregation: 2121 AfriNIC Deaggregation factor: 4.20 Prefixes being announced from the AfriNIC address blocks: 6971 Unique aggregates announced from the AfriNIC address blocks: 2163 AfriNIC Region origin ASes present in the Internet Routing Table: 526 AfriNIC Prefixes per ASN: 13.25 AfriNIC Region origin ASes announcing only one prefix: 164 AfriNIC Region transit ASes present in the Internet Routing Table: 115 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 31533568 Equivalent to 1 /8s, 225 /16s and 42 /24s Percentage of available AfriNIC address space announced: 47.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2479 11109 992 Korea Telecom (KIX) 17974 1787 503 63 PT TELEKOMUNIKASI INDONESIA 7545 1659 301 89 TPG Internet Pty Ltd 4755 1573 386 158 TATA Communications formerly 9583 1238 95 540 Sify Limited 9829 1209 1025 29 BSNL National Internet Backbo 7552 1173 1062 11 Vietel Corporation 4808 1102 2050 316 CNCGROUP IP network: China169 24560 1021 385 167 Bharti Airtel Ltd., Telemedia 18101 949 131 160 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3379 3807 196 bellsouth.net, inc. 7029 3379 990 155 Windstream Communications Inc 18566 2092 383 179 Covad Communications 1785 1889 680 129 PaeTec Communications, Inc. 20115 1633 1559 624 Charter Communications 4323 1602 1060 382 Time Warner Telecom 22773 1552 2910 111 Cox Communications, Inc. 30036 1415 256 745 Mediacom Communications Corp 7018 1282 9791 831 AT&T WorldNet Services 11492 1184 216 364 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1792 544 16 Corbina telecom 2118 1427 97 13 EUnet/RELCOM Autonomous Syste 31148 677 37 9 FreeNet ISP 34984 673 188 174 BILISIM TELEKOM 12479 656 658 57 Uni2 Autonomous System 20940 646 206 498 Akamai Technologies European 6830 641 1943 412 UPC Distribution Services 8551 571 360 81 Bezeq International 3320 532 8442 398 Deutsche Telekom AG 2578 500 33 7 Demos, Moscow, Russia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1817 330 131 TVCABLE BOGOTA 28573 1745 1105 60 NET Servicos de Comunicao S.A 8151 1491 3018 350 UniNet S.A. de C.V. 7303 1352 827 188 Telecom Argentina Stet-France 6503 1348 418 65 AVANTEL, S.A. 26615 903 700 28 Tim Brasil S.A. 27947 688 74 100 Telconet S.A 11172 636 91 73 Servicios Alestra S.A de C.V 22047 584 326 15 VTR PUNTO NET S.A. 3816 566 242 105 Empresa Nacional de Telecomun Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1294 958 13 TEDATA 24863 848 274 35 LINKdotNET AS number 6713 491 649 18 Itissalat Al-MAGHRIB 3741 272 924 229 The Internet Solution 33776 208 12 21 Starcomms Nigeria Limited 12258 197 28 62 Vodacom Internet Company 24835 178 80 8 RAYA Telecom - Egypt 15706 168 32 6 Sudatel Internet Exchange Aut 16637 164 664 82 MTN Network Solutions 29571 159 15 16 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3379 3807 196 bellsouth.net, inc. 7029 3379 990 155 Windstream Communications Inc 4766 2479 11109 992 Korea Telecom (KIX) 18566 2092 383 179 Covad Communications 1785 1889 680 129 PaeTec Communications, Inc. 10620 1817 330 131 TVCABLE BOGOTA 8402 1792 544 16 Corbina telecom 17974 1787 503 63 PT TELEKOMUNIKASI INDONESIA 28573 1745 1105 60 NET Servicos de Comunicao S.A 7545 1659 301 89 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3379 3224 Windstream Communications Inc 18566 2092 1913 Covad Communications 8402 1792 1776 Corbina telecom 1785 1889 1760 PaeTec Communications, Inc. 17974 1787 1724 PT TELEKOMUNIKASI INDONESIA 10620 1817 1686 TVCABLE BOGOTA 28573 1745 1685 NET Servicos de Comunicao S.A 7545 1659 1570 TPG Internet Pty Ltd 4766 2479 1487 Korea Telecom (KIX) 22773 1552 1441 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 54439 UNALLOCATED 8.25.174.0/24 17378 DBS International 54470 UNALLOCATED 8.30.171.0/24 3356 Level 3 Communicatio 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 23.27.0.0/20 54500 EGIHosting 23.27.16.0/20 54500 EGIHosting Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:12 /10:28 /11:81 /12:235 /13:457 /14:833 /15:1482 /16:12185 /17:6278 /18:10478 /19:20577 /20:28760 /21:29730 /22:40327 /23:37561 /24:211199 /25:1192 /26:1432 /27:797 /28:170 /29:60 /30:17 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 3039 3379 Windstream Communications Inc 6389 2095 3379 bellsouth.net, inc. 18566 2041 2092 Covad Communications 8402 1769 1792 Corbina telecom 10620 1707 1817 TVCABLE BOGOTA 30036 1359 1415 Mediacom Communications Corp 11492 1147 1184 Cable One 6503 1118 1348 AVANTEL, S.A. 8452 1102 1294 TEDATA 1785 1067 1889 PaeTec Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:531 2:755 4:14 6:3 8:394 12:1987 13:1 14:605 15:12 16:3 17:7 20:8 23:160 24:1754 27:1257 31:936 32:58 33:2 34:2 36:8 37:313 38:790 40:120 41:3086 42:129 44:3 46:1454 47:3 49:343 50:535 52:13 54:6 55:11 56:3 57:32 58:966 59:495 60:278 61:1202 62:972 63:1996 64:4198 65:2274 66:4497 67:2022 68:1146 69:3184 70:910 71:465 72:1817 74:2591 75:493 76:317 77:959 78:1007 79:498 80:1210 81:897 82:666 83:548 84:513 85:1205 86:408 87:900 88:342 89:1623 90:297 91:4657 92:516 93:1376 94:1461 95:1160 96:377 97:316 98:844 99:37 100:6 101:168 103:929 106:66 107:180 108:218 109:1275 110:759 111:901 112:445 113:593 114:652 115:780 116:908 117:724 118:907 119:1207 120:350 121:696 122:1665 123:1099 124:1363 125:1263 128:561 129:189 130:256 131:595 132:173 133:21 134:242 135:62 136:212 137:176 138:351 139:145 140:494 141:244 142:385 143:399 144:513 145:66 146:485 147:243 148:748 149:298 150:157 151:176 152:460 153:171 154:7 155:430 156:215 157:379 158:176 159:525 160:343 161:248 162:343 163:190 164:555 165:391 166:562 167:464 168:819 169:127 170:844 171:124 172:4 173:1721 174:582 175:436 176:437 177:619 178:1310 180:1199 181:73 182:777 183:279 184:445 185:1 186:2136 187:1006 188:1158 189:1688 190:5498 192:5996 193:5608 194:4622 195:3589 196:1292 197:123 198:3617 199:4487 200:5805 201:1901 202:8463 203:8589 204:4342 205:2476 206:2752 207:2781 208:4053 209:3599 210:2764 211:1471 212:2008 213:1908 214:876 215:109 216:5079 217:1524 218:537 219:324 220:1228 221:557 222:325 223:329 End of report From woody at pch.net Fri Mar 30 14:05:35 2012 From: woody at pch.net (Bill Woodcock) Date: Fri, 30 Mar 2012 12:05:35 -0700 Subject: French Regulator to ask all your information about your Peering In-Reply-To: <4F75FB6F.3080501@stefan-neufeind.de> References: <4F75FB6F.3080501@stefan-neufeind.de> Message-ID: <608FE78D-529C-4DE7-B73A-57716189B64B@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mar 30, 2012, at 11:29 AM, Stefan Neufeind wrote: >> You have to give them information twice a year > > Well, then for a few hundered peerings send them one letter each and > wait for a reaction :-) Remember, these are bureaucrats? Their reaction would be to fine you for not submitting each letter in triplicate, and then charge you interest on the fines. :-) -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPdgP/AAoJEG+kcEsoi3+H/sYP/2PY0yeJh6KMmP0yQIYfE7+C XSH43rsKpMoP8vMs8OPuA4MNcVYXRbXly1XGhtrVR2dnc2EXpRb/bcpRrHdYbdwg wD36EFPlrdv42mtw1e9lMUitod91xuIlYhqvJ+h5qMBfDjtcHVMRp4CAGcNzlRa4 +Tfc6mAKOeKl84DiL1UDl7QSxcIBBsS3pM/Y1kKcxtR5hP8BhPY3WIFGSEslMa1R TC3sxfS/aux626JNtAdOyqjPF3NACkX4TwdKpfCGJusG1H7LkCj1lTqfpLT++yQP suSnJsrmJmGPlu83Bm/yuRFMQ8RiyEYNcfWOUMkjnWlCIaVmbBC/5q9DWd9h457B 3reZdCx540s1Of7bz6l5z4wPUx233BnPZ+jbrp5VMgTAJ3Qr+EbPCisA6YZVk1/D W1LcRvE0NOIqbTlBwG04qbbJCCmqljVcC9a3lYra1ULP4UEcLj64k41VEtN8iNZj PnAePhib4fBR0ZGT1qd1mrfSTB5oRN5FA5hcqRYXtdIKNafakhBUbUAlXZrdQrcX lHhyNzgkhtCClzqq7tR0e0chjpFKwh2Lo5nWVNExareWGnx1lGGypkz9Qj4UFENs w3S8InqOaHnyjyXvzm1DVh/VjIpjEVNT71V/YcqheymmG2CDC+rArl6vAfxWTkH+ DayMftFMf8u0UZ6/j+qB =1jgK -----END PGP SIGNATURE----- From bicknell at ufp.org Fri Mar 30 14:06:09 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 30 Mar 2012 12:06:09 -0700 Subject: French Regulator to ask all your information about your Peering In-Reply-To: References: <7FF80F49-7F29-426B-B701-DDEA23B70A05@pch.net> Message-ID: <20120330190609.GA46840@ussenterprise.ufp.org> In a message written on Fri, Mar 30, 2012 at 07:50:43PM +0100, Mike Blanche wrote: > http://www.arcep.fr/index.php?id=9320 > > That's quite a big list. :-( (assuming I understand that list to be > everyone licenced under L33-1) Can someone with more local knowledge explain a "L33" license? Looking at the names and some quick googling make me think this is like a CLEC license in the US. If so, aren't they missing a fair number of the folks who might be present at an exchange but not have such a license? I'm almost afraid to ask, since they will likely want to license such folks... *sigh* -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mikea at mikea.ath.cx Fri Mar 30 14:10:57 2012 From: mikea at mikea.ath.cx (Mike Andrews) Date: Fri, 30 Mar 2012 14:10:57 -0500 Subject: French Regulator to ask all your information about your Peering In-Reply-To: <608FE78D-529C-4DE7-B73A-57716189B64B@pch.net> References: <4F75FB6F.3080501@stefan-neufeind.de> <608FE78D-529C-4DE7-B73A-57716189B64B@pch.net> Message-ID: <20120330191057.GB2151@mikea.ath.cx> On Fri, Mar 30, 2012 at 12:05:35PM -0700, Bill Woodcock wrote: > On Mar 30, 2012, at 11:29 AM, Stefan Neufeind wrote: > >> You have to give them information twice a year > > Well, then for a few hundered peerings send them one letter each and > > wait for a reaction :-) > > Remember, these are bureaucrats??? Their reaction would be to fine > you for not submitting each letter in triplicate, and then charge you > interest on the fines. :-) "The official state religion of France is Bureaucracy. They've replaced the Trinity with the Triplicate." (David Richerby) Besides which, you'd be boosting the economy! They'd have to hire people, and cash flow would increase. How can they *not* do it? -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From bonomi at mail.r-bonomi.com Fri Mar 30 15:26:42 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 30 Mar 2012 15:26:42 -0500 (CDT) Subject: French Regulator to ask all your information about your Peering In-Reply-To: <4F75FB6F.3080501@stefan-neufeind.de> Message-ID: <201203302026.q2UKQgHl098685@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Fri Mar 30 13:30:19 2012 > Date: Fri, 30 Mar 2012 20:29:03 +0200 > From: Stefan Neufeind > To: "'NANOG list'" > Subject: Re: French Regulator to ask all your information about your Peering > > On 03/30/2012 08:21 PM, Raphael MAUNIER wrote: > > > > This is now the end. The French regulator ( Arcep ) is now asking all the > > people with an ASN in France ( with a L33 license ) to get all their > > information on their peering. > > [...] > > > You have to give them information twice a year > > Well, then for a few hundered peerings send them one letter each and > wait for a reaction :-) If I were in an *evil* frame of mind, I'd do something like a color pdf with white lettering on a white backgound. Or maybe just do everything in a 0.01 point high font. From afenioux at gmail.com Fri Mar 30 15:38:37 2012 From: afenioux at gmail.com (Arnaud Fenioux) Date: Fri, 30 Mar 2012 22:38:37 +0200 Subject: French Regulator to ask all your information about your Peering In-Reply-To: <20120330190609.GA46840@ussenterprise.ufp.org> References: <7FF80F49-7F29-426B-B701-DDEA23B70A05@pch.net> <20120330190609.GA46840@ussenterprise.ufp.org> Message-ID: On Fri, Mar 30, 2012 at 9:06 PM, Leo Bicknell wrote: > In a message written on Fri, Mar 30, 2012 at 07:50:43PM +0100, Mike > Blanche wrote: > > http://www.arcep.fr/index.php?id=9320 > > > > That's quite a big list. :-( (assuming I understand that list to be > > everyone licenced under L33-1) > > Can someone with more local knowledge explain a "L33" license? > In France, L33 is the license for companies that operate public networks and provide public electronic communications services, here is a translation (if you dare) : http://translate.googleusercontent.com/translate_c?act=url&hl=fr&ie=UTF8&prev=_t&rurl=translate.google.fr&sl=fr&tl=en&twu=1&u=http://www.legifrance.gouv.fr/affichCodeArticle.do%3FidArticle%3DLEGIARTI000024506015%26cidTexte%3DLEGITEXT000006070987%26categorieLien%3Did%26dateTexte%3D20120330&usg=ALkJrhj-oUuDkvh8f068LcNFYXc0ceE-RQ Looking at the names and some quick googling make me think this is > like a CLEC license in the US. If so, aren't they missing a > fair number of the folks who might be present at an exchange but not > have such a license? > all companies that operate their network for their own use, but ARCEP will know most of the major peering relationships. Let's hope it will help peering.... :/ From henry at AegisInfoSys.com Fri Mar 30 15:41:19 2012 From: henry at AegisInfoSys.com (Henry Yen) Date: Fri, 30 Mar 2012 16:41:19 -0400 Subject: uunet ends newsfeed/newsreader in US Message-ID: <20120330204119.GC23534@nntp.AegisInfoSys.com> uunet/vzb "will terminate its United States Newsreader and Newsfeed services on March 31, 2012, with no plans to offer a replacement, and any content/data remaining after that date will be unrecoverably deleted". does anyone on NANOG have any thoughtful comments on this? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York 1-800-AEGIS-00 (800-234-4700) From jlewis at lewis.org Fri Mar 30 15:47:07 2012 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 30 Mar 2012 16:47:07 -0400 (EDT) Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120330204119.GC23534@nntp.AegisInfoSys.com> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> Message-ID: On Fri, 30 Mar 2012, Henry Yen wrote: > uunet/vzb "will terminate its United States Newsreader and Newsfeed > services on March 31, 2012, with no plans to offer a replacement, and > any content/data remaining after that date will be unrecoverably deleted". > > does anyone on NANOG have any thoughtful comments on this? UUNet's still been running NNTP/NNRP servers? I had an NNTP feed from them...back in 1995...when you could actually do a feed on a T1 and have room for dial-up customer traffic. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jgreco at ns.sol.net Fri Mar 30 15:50:33 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 30 Mar 2012 15:50:33 -0500 (CDT) Subject: uunet ends newsfeed/newsreader in US In-Reply-To: Message-ID: <201203302050.q2UKoXc1001366@aurora.sol.net> > On Fri, 30 Mar 2012, Henry Yen wrote: > > uunet/vzb "will terminate its United States Newsreader and Newsfeed > > services on March 31, 2012, with no plans to offer a replacement, and > > any content/data remaining after that date will be unrecoverably deleted". > > > > does anyone on NANOG have any thoughtful comments on this? > > UUNet's still been running NNTP/NNRP servers? > I had an NNTP feed from them...back in 1995...when you could actually do a > feed on a T1 and have room for dial-up customer traffic. UUNet hasn't been relevant to USENET for many, many, many years. ... 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 trelane at trelane.net Fri Mar 30 15:51:06 2012 From: trelane at trelane.net (Andrew D Kirch) Date: Fri, 30 Mar 2012 16:51:06 -0400 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120330204119.GC23534@nntp.AegisInfoSys.com> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> Message-ID: <4F761CBA.3000503@trelane.net> On 3/30/2012 4:41 PM, Henry Yen wrote: > uunet/vzb "will terminate its United States Newsreader and Newsfeed > services on March 31, 2012, with no plans to offer a replacement, and > any content/data remaining after that date will be unrecoverably deleted". > > does anyone on NANOG have any thoughtful comments on this? > Obsolete protocol is obsolete? Andrew From r.hyunseog at ieee.org Fri Mar 30 15:54:47 2012 From: r.hyunseog at ieee.org (Alex Ryu) Date: Fri, 30 Mar 2012 15:54:47 -0500 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120330204119.GC23534@nntp.AegisInfoSys.com> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> Message-ID: Less, and less people keep using Usenet... A lot of people just use Search Engine, Web download, P2P... I guess given the traffic and data too stored, it may not be useful for the effort to keep Usenet service running. Alex On Fri, Mar 30, 2012 at 3:41 PM, Henry Yen wrote: > uunet/vzb "will terminate its United States Newsreader and Newsfeed > services on March 31, 2012, with no plans to offer a replacement, and > any content/data remaining after that date will be unrecoverably deleted". > > does anyone on NANOG have any thoughtful comments on this? > > -- > Henry Yen Aegis Information > Systems, Inc. > Senior Systems Programmer Hicksville, New York > 1-800-AEGIS-00 > (800-234-4700) > > > From jgreco at ns.sol.net Fri Mar 30 15:55:14 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 30 Mar 2012 15:55:14 -0500 (CDT) Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <4F761CBA.3000503@trelane.net> Message-ID: <201203302055.q2UKtEeb001448@aurora.sol.net> > On 3/30/2012 4:41 PM, Henry Yen wrote: > > uunet/vzb "will terminate its United States Newsreader and Newsfeed > > services on March 31, 2012, with no plans to offer a replacement, and > > any content/data remaining after that date will be unrecoverably deleted". > > > > does anyone on NANOG have any thoughtful comments on this? > > Obsolete protocol is obsolete? Guessing: you mean ipv4? Because NNTP is still alive and kicking. ... 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 scott at virtuaprise.com Fri Mar 30 15:55:21 2012 From: scott at virtuaprise.com (K. Scott Bethke) Date: Fri, 30 Mar 2012 16:55:21 -0400 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120330204119.GC23534@nntp.AegisInfoSys.com> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> Message-ID: <65CCB887-E0BF-42F9-95E7-691208BE9E63@virtuaprise.com> On Mar 30, 2012, at 4:41 PM, Henry Yen wrote: > uunet/vzb "will terminate its United States Newsreader and Newsfeed > services on March 31, 2012 > > does anyone on NANOG have any thoughtful comments on this? No comment just a question... Why did it take so long? All good things must come to an end. and for NNTP that end was when web based Forums software and P2P was invented. Seriously does anyone still use UUCP for email? I thought it should have died when pr0n and w4rez took it over (in the late 90's).. but that ended up fueling the need :) Who is the Kim Dotcom of usenet? Lets bust him and move on. -Scott From kuenzler at init7.net Fri Mar 30 16:06:39 2012 From: kuenzler at init7.net (Fredy Kuenzler) Date: Fri, 30 Mar 2012 23:06:39 +0200 Subject: French Regulator to ask all your information about your Peering In-Reply-To: References: Message-ID: <4F76205F.90204@init7.net> Am 30.03.2012 20:21, schrieb Raphael MAUNIER: > This is now the end. The French regulator ( Arcep ) is now asking all the > people with an ASN in France ( with a L33 license ) to get all their > information on their peering. > > The Arcep claim it's for the "net neutrality" and still don't understand > it works because it's self regulated. I suggest to stop whining. Why do we see regulators stepping in? Simply because some networks (mainly, but not only incumbents) abused their market power. It doesn't surprise me that it starts in France, as it's a common knowledge that the French incumbent has only one default answer, which is 'no'. > [...] > > You have to give them information twice a year > > We ( @Neo Telecoms ) and other folks in France will probably setup > something with other carriers ( I already had some discussion with some > of you ) to talk to them on a single voice. Much appreciated. They certainly will come to some automated solution where they can generate reports on BGP feeds we send to their route collector. Everyone with proper route tagging should be ok and live happily. If, after all, the French incumbent has trouble to find an appropriate explanation for the regulator to justify their policy, so be it... From rmaunier at neotelecoms.com Fri Mar 30 16:20:10 2012 From: rmaunier at neotelecoms.com (Raphael MAUNIER) Date: Fri, 30 Mar 2012 21:20:10 +0000 Subject: French Regulator to ask all your information about your Peering In-Reply-To: <4F76205F.90204@init7.net> Message-ID: Sorry Fredy, but you are living in a care bear world ? Do you think some people build an intense national backbone You were @GPF last week, when Martin asked : Who want this to be regulated ? And Who want to have his peering controled ? why you didn't raise your hand ? In my memory, no one did. I didn't get my peering with France Telecom, so I get in touch with them and I have a fair contrat and I have a good backbone quality. In my market, I need for now direct access to them, and that's life. My business is not made on the "wishes" to have free peering with my incumbent. -- Rapha?l Maunier NEO TELECOMS CTO / Directeur Ing?nierie AS8218 -----Original Message----- From: Fredy Kuenzler Organization: Init Seven AG - http://www.init7.net/ Date: Fri, 30 Mar 2012 23:06:39 +0200 To: 'NANOG list' Subject: Re: French Regulator to ask all your information about your Peering >Am 30.03.2012 20:21, schrieb Raphael MAUNIER: >> This is now the end. The French regulator ( Arcep ) is now asking all >>the >> people with an ASN in France ( with a L33 license ) to get all their >> information on their peering. >> >> The Arcep claim it's for the "net neutrality" and still don't understand >> it works because it's self regulated. > >I suggest to stop whining. Why do we see regulators stepping in? Simply >because some networks (mainly, but not only incumbents) abused their >market >power. It doesn't surprise me that it starts in France, as it's a common >knowledge that the French incumbent has only one default answer, which is >'no'. > >> [...] >> >> You have to give them information twice a year >> >> We ( @Neo Telecoms ) and other folks in France will probably setup >> something with other carriers ( I already had some discussion with some >> of you ) to talk to them on a single voice. > >Much appreciated. They certainly will come to some automated solution >where >they can generate reports on BGP feeds we send to their route collector. >Everyone with proper route tagging should be ok and live happily. > >If, after all, the French incumbent has trouble to find an appropriate >explanation for the regulator to justify their policy, so be it... > From jra at baylink.com Fri Mar 30 16:31:48 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 30 Mar 2012 17:31:48 -0400 (EDT) Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <65CCB887-E0BF-42F9-95E7-691208BE9E63@virtuaprise.com> Message-ID: <4405831.9247.1333143108249.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "K. Scott Bethke" > No comment just a question... Why did it take so long? > > All good things must come to an end. and for NNTP that end was when > web based Forums software and P2P was invented. Seriously does anyone > still use UUCP for email? Yeah, that has nothing to do with whether Usenet is useful. Nobody (to speak of) has used UUCP for *Usenet* since about 1997 or 8. > I thought it should have died when pr0n and > w4rez took it over (in the late 90's).. And yet, I was a fairly active participant in several tech and rec groups in 96 and 02-04ish, and it seemed perfectly serviceable to me. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 From bicknell at ufp.org Fri Mar 30 16:37:51 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 30 Mar 2012 14:37:51 -0700 Subject: French Regulator to ask all your information about your Peering In-Reply-To: References: <4F76205F.90204@init7.net> Message-ID: <20120330213751.GA51555@ussenterprise.ufp.org> In a message written on Fri, Mar 30, 2012 at 09:20:10PM +0000, Raphael MAUNIER wrote: > You were @GPF last week, when Martin asked : Who want this to be regulated > ? And Who want to have his peering controled ? why you didn't raise your > hand ? > > In my memory, no one did. It's also fearmongering. I am not in favor of the type of regulation that Martin alluded to in his question. However, I also do not think all regulation is bad. As long as the industry's attitude is to avoid the regulator at all costs the regulator will make decisions without information and consultation, and those decisions will be bad. "Regulation" could be as benign as "Anyone who peers in France must publically post their peering policy" to something as sinister as "the regulator will dictate all peering arrangements to all parties". Everyone on this list should be working _with_ the regulators wherever possible to educate them, and help shape regulations to meet your business needs. Other industries have done this for years. Lobbiests get paid millions of dollars to shape government regulations in favor of their employer; peering and more importantly regulation of the Internet is no different. -- 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 rmaunier at neotelecoms.com Fri Mar 30 16:48:00 2012 From: rmaunier at neotelecoms.com (Raphael MAUNIER) Date: Fri, 30 Mar 2012 21:48:00 +0000 Subject: French Regulator to ask all your information about your Peering In-Reply-To: <20120330213751.GA51555@ussenterprise.ufp.org> Message-ID: -----Original Message----- From: Leo Bicknell Organization: United Federation of Planets Date: Fri, 30 Mar 2012 14:37:51 -0700 To: 'NANOG list' Subject: Re: French Regulator to ask all your information about your Peering >In a message written on Fri, Mar 30, 2012 at 09:20:10PM +0000, Raphael >MAUNIER wrote: >> You were @GPF last week, when Martin asked : Who want this to be >>regulated >> ? And Who want to have his peering controled ? why you didn't raise your >> hand ? >> >> In my memory, no one did. > >It's also fearmongering. You may be right. > >I am not in favor of the type of regulation that Martin alluded to >in his question. However, I also do not think all regulation is >bad. As long as the industry's attitude is to avoid the regulator >at all costs the regulator will make decisions without information >and consultation, and those decisions will be bad. I spent time to talk to them ( hours honestly ) trying to explain what is really the peering. I don't get the point to ask for a "consultation" and less than the month after, oblige people to do it ? > >"Regulation" could be as benign as "Anyone who peers in France must >publically post their peering policy" to something as sinister as >"the regulator will dictate all peering arrangements to all parties". This is my problem. In a near future, this will be the case. My guess is : how to get some vat on top of this. Today there is no prices, so no vat, we need to get some. >Everyone on this list should be working _with_ the regulators >wherever possible to educate them, and help shape regulations to >meet your business needs. Toons of hours for this ? Really ? Ok, I don't speak english very well, it seems that it's the same for french. > Other industries have done this for >years. Lobbiests get paid millions of dollars to shape government >regulations in favor of their employer; peering and more importantly >regulation of the Internet is no different. +1 > >-- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From kuenzler at init7.net Fri Mar 30 16:48:17 2012 From: kuenzler at init7.net (Fredy Kuenzler) Date: Fri, 30 Mar 2012 23:48:17 +0200 Subject: French Regulator to ask all your information about your Peering In-Reply-To: References: Message-ID: <4F762A21.7080907@init7.net> Am 30.03.2012 23:20, schrieb Raphael MAUNIER: > Sorry Fredy, but you are living in a care bear world ? > > Do you think some people build an intense national backbone > > You were @GPF last week, when Martin asked : Who want this to be > regulated ? And Who want to have his peering controled ? why you didn't > raise your hand ? > > In my memory, no one did. > > I didn't get my peering with France Telecom, so I get in touch with them > and I have a fair contrat and I have a good backbone quality. In my > market, I need for now direct access to them, and that's life. > > My business is not made on the "wishes" to have free peering with my > incumbent. I'm not saying I want this regulated, in fact I prefer to have it as it is and keep authorities out of the game. That's why I didn't raise my hand. But: Fact is that competition commissions and regulators are investigating against incumbents and such. They could have avoided this easily if they would have been more cooperative and keep their policy less restrictive. I don't blame anyone who is filing against someone who is abusing market power. Now, obviously, the French regulator sees the trouble and trys to understand and 'regulate' it the way they do it usually. From our perspective certainly not a good way, but why blaming the regulator? Blame those which made it all happen! Read: the restrictive incumbents which put obstacles in the way of everyone else. You've choosen to pay to get obstacles away. Others prefer to call the court. And probably the majority suffers in silence, especially the countless broadband users which actually pay our salaries and make our industry happening. Regulators should primarily care about those, and therefore it's good that the French regulator actually made a move, however arguably in the wrong direction. F. From johnl at iecc.com Fri Mar 30 16:55:49 2012 From: johnl at iecc.com (John Levine) Date: 30 Mar 2012 21:55:49 -0000 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <4405831.9247.1333143108249.JavaMail.root@benjamin.baylink.com> Message-ID: <20120330215549.68551.qmail@joyce.lan> >> I thought it should have died when pr0n and >> w4rez took it over (in the late 90's).. Many of the tech groups remain quite healthy. I still moderate comp.compilers which gets about 100 posts/month. Actually, it's fine with us that the ignorant masses think that usenet is dead, since it tends to keep out the riffraff. R's, John From cidr-report at potaroo.net Fri Mar 30 17:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Mar 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201203302200.q2UM01TS002910@wattle.apnic.net> BGP Update Report Interval: 22-Mar-12 -to- 29-Mar-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS786 98735 3.9% 484.0 -- JANET The JNT Association 2 - AS8402 78832 3.1% 39.1 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 42019 1.6% 34.8 -- BSNL-NIB National Internet Backbone 4 - AS12479 27956 1.1% 42.6 -- UNI2-AS France Telecom Espana SA 5 - AS24560 25962 1.0% 25.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 6 - AS7552 24172 0.9% 20.3 -- VIETEL-AS-AP Vietel Corporation 7 - AS32528 22938 0.9% 2293.8 -- ABBOTT Abbot Labs 8 - AS7029 21407 0.8% 6.0 -- WINDSTREAM - Windstream Communications Inc 9 - AS27947 20116 0.8% 28.5 -- Telconet S.A 10 - AS26615 18678 0.7% 20.7 -- Tim Celular S.A. 11 - AS28683 17766 0.7% 323.0 -- BENINTELECOM 12 - AS5800 16470 0.7% 52.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS23216 16342 0.6% 92.3 -- MEGADATOS S.A. 14 - AS7843 15780 0.6% 52.1 -- TWCABLE-BACKBONE - Road Runner HoldCo LLC 15 - AS17974 14834 0.6% 8.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 16 - AS45899 11964 0.5% 37.2 -- VNPT-AS-VN VNPT Corp 17 - AS28573 11799 0.5% 5.8 -- NET Servicos de Comunicao S.A. 18 - AS8452 11344 0.5% 8.7 -- TE-AS TE-AS 19 - AS12008 10792 0.4% 131.6 -- ULTRADNS - Centergate Research, LLC. 20 - AS8151 10663 0.4% 7.1 -- Uninet S.A. de C.V. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS13277 8990 0.3% 4495.0 -- HP-MS HP-MS Autonomous System 2 - AS57767 2353 0.1% 2353.0 -- RTTC-AS Federal State-owned Enterprise Russian Television and Radio Broadcasting Network 3 - AS32528 22938 0.9% 2293.8 -- ABBOTT Abbot Labs 4 - AS36926 7691 0.3% 1538.2 -- CKL1-ASN 5 - AS26678 1091 0.0% 1091.0 -- ASN-QMFI - QUINCY MUTUAL FIRE INSURANCE, CO. 6 - AS23266 1050 0.0% 1050.0 -- COMCAST-23266 - Comcast Cable Communications 7 - AS55665 926 0.0% 926.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 8 - AS6066 1371 0.1% 685.5 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc. 9 - AS16045 677 0.0% 677.0 -- SPEKTAR-AD Spektar AD 10 - AS16935 2000 0.1% 666.7 -- KSC-NETWORKS - Kingland Systems Corp. 11 - AS56915 617 0.0% 617.0 -- ASELITTELECOM Elit Telecom Ltd. 12 - AS15770 593 0.0% 593.0 -- DERWENTSIDE Derwentside District Council 13 - AS26779 1760 0.1% 586.7 -- PANDO-NETWORKS - Pando Networks 14 - AS48018 582 0.0% 582.0 -- MTB-COMPUTER-SERVICES-LTD MTB Computer Services Ltd 15 - AS48632 580 0.0% 580.0 -- BTS-HOLDINGS-PLC BTS Holdings PLC 16 - AS39779 576 0.0% 576.0 -- MESHDIGITAL Mesh Digital Ltd 17 - AS12295 570 0.0% 570.0 -- LONDONLINK Professional Telecommunications Ltd. 18 - AS28861 569 0.0% 569.0 -- CARR-FUTURES-LONDON-AS Carr Futures Inc London 19 - AS31392 558 0.0% 558.0 -- PHOENIX-VENTURE-HOLDINGS-AS Phoenix Venture Holdings Ltd 20 - AS53045 1090 0.0% 545.0 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 130.36.34.0/24 11460 0.4% AS32528 -- ABBOTT Abbot Labs 2 - 130.36.35.0/24 11460 0.4% AS32528 -- ABBOTT Abbot Labs 3 - 204.234.0.0/17 10768 0.4% AS7029 -- WINDSTREAM - Windstream Communications Inc 4 - 62.36.252.0/22 8621 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 5 - 62.36.249.0/24 6491 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 6 - 122.161.0.0/16 6329 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 182.64.0.0/16 6240 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - 62.36.241.0/24 5903 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 9 - 62.36.210.0/24 5675 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 194.63.9.0/24 4915 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 11 - 194.209.13.0/24 4495 0.2% AS13277 -- HP-MS HP-MS Autonomous System 12 - 194.209.211.0/24 4495 0.2% AS13277 -- HP-MS HP-MS Autonomous System 13 - 217.15.120.0/22 4336 0.2% AS56696 -- ASLIQUID-MPLS Liquid Telecommunications Ltd 14 - 205.107.121.0/24 4335 0.2% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - 41.223.57.0/24 3839 0.1% AS36926 -- CKL1-ASN 16 - 41.223.56.0/24 3839 0.1% AS36926 -- CKL1-ASN 17 - 202.153.174.0/24 3470 0.1% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 18 - 67.214.235.0/24 3438 0.1% AS29933 -- OFF-CAMPUS-TELECOMMUNICATIONS - Off Campus Telecommunications 19 - 205.106.248.0/24 3277 0.1% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - 96.45.89.0/24 2905 0.1% AS16552 -- TIGGEE - Tiggee LLC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 30 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Mar 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201203302200.q2UM00Mw002905@wattle.apnic.net> This report has been generated at Fri Mar 30 21:12:26 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 23-03-12 405211 237312 24-03-12 406791 237506 25-03-12 406910 237612 26-03-12 407108 237709 27-03-12 407254 237193 28-03-12 406770 236263 29-03-12 406051 236496 30-03-12 406585 236469 AS Summary 40664 Number of ASes in routing system 17035 Number of ASes announcing only one prefix 3419 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 111385888 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'). --- 30Mar12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 406832 236438 170394 41.9% All ASes AS6389 3379 199 3180 94.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3419 1820 1599 46.8% WINDSTREAM - Windstream Communications Inc AS4766 2483 1015 1468 59.1% KIXS-AS-KR Korea Telecom AS22773 1552 120 1432 92.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS2118 1427 14 1413 99.0% RELCOM-AS OOO "NPO Relcom" AS18566 2092 705 1387 66.3% COVAD - Covad Communications Co. AS28573 1745 492 1253 71.8% NET Servicos de Comunicao S.A. AS4323 1603 384 1219 76.0% TWTC - tw telecom holdings, inc. AS4755 1572 394 1178 74.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1892 805 1087 57.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS10620 1817 809 1008 55.5% Telmex Colombia S.A. AS7552 1173 221 952 81.2% VIETEL-AS-AP Vietel Corporation AS8402 1738 805 933 53.7% CORBINA-AS OJSC "Vimpelcom" AS7303 1353 439 914 67.6% Telecom Argentina S.A. AS26615 903 28 875 96.9% Tim Celular S.A. AS8151 1493 671 822 55.1% Uninet S.A. de C.V. AS18101 932 157 775 83.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1101 347 754 68.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9394 888 207 681 76.7% CRNET CHINA RAILWAY Internet(CRNET) AS7545 1659 983 676 40.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS17974 1787 1115 672 37.6% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS30036 1415 774 641 45.3% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS3356 1099 461 638 58.1% LEVEL3 Level 3 Communications AS17676 686 74 612 89.2% GIGAINFRA Softbank BB Corp. AS19262 996 401 595 59.7% VZGNI-TRANSIT - Verizon Online LLC AS24560 1021 434 587 57.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3549 1004 435 569 56.7% GBLX Global Crossing Ltd. AS22561 991 422 569 57.4% DIGITAL-TELEPORT - Digital Teleport Inc. AS4804 654 95 559 85.5% MPX-AS Microplex PTY LTD AS22047 584 31 553 94.7% VTR BANDA ANCHA S.A. Total 44458 14857 29601 66.6% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 37.208.120.0/21 AS50077 MGN-STK-AS "Set-Telekom" Ltd. 37.208.120.0/24 AS50077 MGN-STK-AS "Set-Telekom" Ltd. 37.208.121.0/24 AS50077 MGN-STK-AS "Set-Telekom" Ltd. 37.208.122.0/24 AS50077 MGN-STK-AS "Set-Telekom" Ltd. 37.208.123.0/24 AS50077 MGN-STK-AS "Set-Telekom" Ltd. 37.208.124.0/24 AS50077 MGN-STK-AS "Set-Telekom" Ltd. 37.208.125.0/24 AS50077 MGN-STK-AS "Set-Telekom" Ltd. 37.208.126.0/24 AS50077 MGN-STK-AS "Set-Telekom" Ltd. 37.208.127.0/24 AS50077 MGN-STK-AS "Set-Telekom" Ltd. 37.212.0.0/14 AS6697 BELPAK-AS Republican Association BELTELECOM 37.216.0.0/15 AS34744 GVM S.C. GVM SISTEM 2003 S.R.L. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS14208 74.91.49.0/24 AS14208 74.91.50.0/24 AS14208 74.91.51.0/24 AS14208 74.91.52.0/24 AS14208 74.91.53.0/24 AS14208 74.91.54.0/24 AS14208 74.91.55.0/24 AS14208 74.91.56.0/24 AS14208 74.91.57.0/24 AS14208 74.91.58.0/24 AS14208 74.91.59.0/24 AS14208 74.91.60.0/24 AS14208 74.91.61.0/24 AS14208 74.91.62.0/24 AS14208 74.91.63.0/24 AS14208 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.86.32.0/20 AS18255 BRISBANE-AP Brisbane City Council 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.122.134.0/24 AS38615 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jgreco at ns.sol.net Fri Mar 30 17:03:58 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 30 Mar 2012 17:03:58 -0500 (CDT) Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120330215549.68551.qmail@joyce.lan> Message-ID: <201203302203.q2UM3wCg002284@aurora.sol.net> > >> I thought it should have died when pr0n and > >> w4rez took it over (in the late 90's).. > > Many of the tech groups remain quite healthy. I still moderate > comp.compilers which gets about 100 posts/month. Those of us still doing work with USENET know that it isn't dead, far from it, but we're aware that there's a certain amount of illicit traffic. It's kind of like the way that pr0n and w4rez dominate all the Internet, but this doesn't seem to faze Internet network operators. > Actually, it's fine with us that the ignorant masses think that usenet > is dead, since it tends to keep out the riffraff. And that's the difference between USENET and the Internet; we've largely gotten our nice messaging network back now that all the AOL newbies are instead attracted to all the forums and blogs of the Internet; running a newsreader client is needlessly complex and may be beyond some of them. :-) ... 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 mfidelman at meetinghouse.net Fri Mar 30 17:06:05 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 30 Mar 2012 18:06:05 -0400 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120330215549.68551.qmail@joyce.lan> References: <20120330215549.68551.qmail@joyce.lan> Message-ID: <4F762E4D.7080108@meetinghouse.net> John Levine wrote: >>> I thought it should have died when pr0n and >>> w4rez took it over (in the late 90's).. > Many of the tech groups remain quite healthy. I still moderate > comp.compilers which gets about 100 posts/month. > > Actually, it's fine with us that the ignorant masses think that usenet > is dead, since it tends to keep out the riffraff. > And NNTP is still one of the most brilliant protocols ever written. Replicated information, no central control, ad hoc group creation. It's really a shame that the Netscape Collaboration Server was never open sourced (easy newsgroup management, a layer of user management) - facebook or googlegroups without the centralized control. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From morrowc.lists at gmail.com Fri Mar 30 17:13:15 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 30 Mar 2012 18:13:15 -0400 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120330204119.GC23534@nntp.AegisInfoSys.com> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> Message-ID: On Fri, Mar 30, 2012 at 4:41 PM, Henry Yen wrote: > uunet/vzb "will terminate its United States Newsreader and Newsfeed > services on March 31, 2012, with no plans to offer a replacement, and > any content/data remaining after that date will be unrecoverably deleted". > > does anyone on NANOG have any thoughtful comments on this? This is really about: "What do our customers pay for?" more than anything else. Keeping 12 diablo servers running for the zero actual customers who use them is ... patently a waste of assets. one server is ~1 sun-something + 1 large disk-array (at least)... so there's some significant savings in power and network ports alone. plus, Verizon is a Cellular carrier, just look at all of the advertisements you see for them, ever seen an "internet" add? or "usenet" ? (fios doesn't count as it's a move by VZ back to monopoly-carrier status, not "internet") From rmaunier at neotelecoms.com Fri Mar 30 17:12:25 2012 From: rmaunier at neotelecoms.com (Raphael MAUNIER) Date: Fri, 30 Mar 2012 22:12:25 +0000 Subject: French Regulator to ask all your information about your Peering In-Reply-To: <4F762A21.7080907@init7.net> References: <4F762A21.7080907@init7.net> Message-ID: On Mar 30, 2012, at 23:46, "Fredy Kuenzler" wrote: > Am 30.03.2012 23:20, schrieb Raphael MAUNIER: >> Sorry Fredy, but you are living in a care bear world ? >> >> Do you think some people build an intense national backbone >> >> You were @GPF last week, when Martin asked : Who want this to be >> regulated ? And Who want to have his peering controled ? why you didn't >> raise your hand ? >> >> In my memory, no one did. >> >> I didn't get my peering with France Telecom, so I get in touch with them >> and I have a fair contrat and I have a good backbone quality. In my >> market, I need for now direct access to them, and that's life. >> >> My business is not made on the "wishes" to have free peering with my >> incumbent. > > I'm not saying I want this regulated, in fact I prefer to have it as it is > and keep authorities out of the game. That's why I didn't raise my hand. > > But: Fact is that competition commissions and regulators are investigating > against incumbents and such. They could have avoided this easily if they > would have been more cooperative and keep their policy less restrictive. I > don't blame anyone who is filing against someone who is abusing market power. > > Now, obviously, the French regulator sees the trouble and trys to understand > and 'regulate' it the way they do it usually. From our perspective certainly > not a good way, but why blaming the regulator? Blame those which made it all > happen! Read: the restrictive incumbents which put obstacles in the way of > everyone else. I respect your position, but I'm not buying it. Those issue are the result of cheap transit provider trying to abuse their peers by selling a cheap ip transit and force the incumbent to upgrade. That's exactly the start of all of this. > > You've choosen to pay to get obstacles away. Others prefer to call the > court. And probably the majority suffers in silence, especially the > countless broadband users which actually pay our salaries and make our > industry happening. I came to see my incumbent to talk to them and really explain what I'm doing, I spent time to explain and get their points and I had some very good discussion about backbone and cost for a big eyeball ... They told me : no one came to us to really understand what are really the "global cost" even the French regulator ! So I still don't buy it ! > Regulators should primarily care about those, and > therefore it's good that the French regulator actually made a move, however > arguably in the wrong direction. That's my point here. We are on the same line. > > F. > From cb.list6 at gmail.com Fri Mar 30 17:22:23 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 30 Mar 2012 15:22:23 -0700 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: References: <20120330204119.GC23534@nntp.AegisInfoSys.com> Message-ID: On Mar 30, 2012 3:13 PM, "Christopher Morrow" wrote: > > On Fri, Mar 30, 2012 at 4:41 PM, Henry Yen wrote: > > uunet/vzb "will terminate its United States Newsreader and Newsfeed > > services on March 31, 2012, with no plans to offer a replacement, and > > any content/data remaining after that date will be unrecoverably deleted". > > > > does anyone on NANOG have any thoughtful comments on this? > > This is really about: "What do our customers pay for?" more than > anything else. Keeping 12 diablo servers running for the zero actual > customers who use them is ... patently a waste of assets. > > one server is ~1 sun-something + 1 large disk-array (at least)... so > there's some significant savings in power and network ports alone. > > plus, Verizon is a Cellular carrier, just look at all of the > advertisements you see for them, ever seen an "internet" add? or Looks more like news groups than cellular to me. : / http://www.youtube.com/watch?v=A-K71MpwCko Cb > "usenet" ? (fios doesn't count as it's a move by VZ back to > monopoly-carrier status, not "internet") > From dylan at corp.power1.com Fri Mar 30 17:31:18 2012 From: dylan at corp.power1.com (Dylan Bouterse) Date: Fri, 30 Mar 2012 22:31:18 +0000 Subject: airFiber (text of the 8 minute video) In-Reply-To: <7F9D3BC0-A630-435F-A654-2E242730777C@delong.com> References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> <5FF4C0E4-23FC-4BEC-989F-C7226186ED1C@gmail.com> <7F9D3BC0-A630-435F-A654-2E242730777C@delong.com> Message-ID: <218AB54691EB49439829EFD136F473CF2774E187@exchange2k10.corp.power1.com> A couple of thoughts. First, it's not fair to compare 24GHz to 2.4 or even 5Gig range due to the wave length. You will get 2.4GHz bleed through walls, windows, etc. VERY close to a 5GHz transmitter you may get some bleed through walls but not reliably. 24GHz will not propagate through objects as it's millimeter wavelength. That coupled with the fact it is a directional PTP product, you will be able to get a good amount of density of 24GHz PTP links using the same frequency in a small area (downtown for instance). Another point, the GPS on the airFiber will also allow for frequency reuse to a point. I would like to see smaller channel sizes though. I hear it will be a software upgrade down the road. I'm shocked the old Canopy guys didn't code that into the first release to be honest. Dylan -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Thursday, March 29, 2012 7:18 PM To: Oliver Garraux Cc: NANOG list Subject: Re: airFiber (text of the 8 minute video) On Mar 29, 2012, at 12:33 PM, Oliver Garraux wrote: >> Also keep in mind this is unlicensed gear (think unprotected airspace). Nothing stops everyone else in town from throwing one up and soon you're drowning in a high noise floor and it goes slow or doesn't work at all. Like what's happened to 2.4GHz and 5.8GHz in a lot of places. There's few urban or semi-urban places where you still can use those frequencies for backhaul. The reason why people pay the big bucks for licenses and gear for licensed frequencies is you're buying insurance it's going to work in the future. >> >> Greg > > I was at Ubiquiti's conference. I don't disagree with what you're > saying. Ubiquiti's take on it seemed to be that 24 Ghz would likely > never be used to the extent that 2.4 / 5.8 is. They are seeing 24 Ghz > as only for backhaul - no connections to end users. I guess > point-to-multipoint connections aren't permitted by the FCC for 24 > Ghz. AirFiber appears to be fairly highly directional. It needs to > be though, as each link uses 100 Mhz, and there's only 250 Mhz > available @ 24 Ghz. > > It also sounded like there was a decent possibility of supporting > licensed 21 / 25 Ghz spectrum with AirFiber in the future. > > Oliver I don't think it's an FCC issue so much as 24Ghz has so much fade tendency with atmospheric moisture that an omnidirectional antenna is about as effective as a resistor coupled to ground (i.e. dummy load). The only way you can get a signal to go any real distance at that frequency is to use a highly directional high-gain antenna at both ends. Owen From brett at the-watsons.org Fri Mar 30 17:48:40 2012 From: brett at the-watsons.org (Brett Watson) Date: Fri, 30 Mar 2012 17:48:40 -0500 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: References: <20120330204119.GC23534@nntp.AegisInfoSys.com> Message-ID: <6AFBF2B3-BF64-4DE1-BEF2-3FBB4889728C@the-watsons.org> On Mar 30, 2012, at 3:47 PM, Jon Lewis wrote: > On Fri, 30 Mar 2012, Henry Yen wrote: > >> uunet/vzb "will terminate its United States Newsreader and Newsfeed >> services on March 31, 2012, with no plans to offer a replacement, and >> any content/data remaining after that date will be unrecoverably deleted". >> >> does anyone on NANOG have any thoughtful comments on this? > > UUNet's still been running NNTP/NNRP servers? > I had an NNTP feed from them...back in 1995...when you could actually do a feed on a T1 and have room for dial-up customer traffic. There's a flashback! I was still shoveling news over UUCP to customers in Texas in '93 :) -b From michael at rancid.berkeley.edu Fri Mar 30 17:59:35 2012 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Fri, 30 Mar 2012 15:59:35 -0700 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120330204119.GC23534@nntp.AegisInfoSys.com> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> Message-ID: <4F763AD7.30805@rancid.berkeley.edu> On 03/30/12 13:41, Henry Yen wrote: > uunet/vzb "will terminate its United States Newsreader and Newsfeed > services on March 31, 2012, with no plans to offer a replacement, and > any content/data remaining after that date will be unrecoverably deleted". > > does anyone on NANOG have any thoughtful comments on this? Only a retrospective: I was hired by the central networking group at UC Berkeley in the late 90s to run the USENET service for campus. At the time, the USENET service was still critically important for the teaching mission of the campus, as many courses (especially in EECS) had very active class newsgroups. As you can see from examples such as CS 61a ( https://groups.google.com/group/ucb.class.cs61a/about?pli=1), use of these groups peaked while I was operating the service. (The numbers are probably skewed a bit, as I don't know how much of the archives google was able to get from before the early 90s. But still, by sheer volume, the early 2000s was probably the peak of the ucb.class hierarchy.) I was following big footsteps: Chris van den Berg preceded me, and he made UCB the #3 USENET transit peer in the world. Before that, Rob Robertson ran the service and he was the one who created the first overview database for INN and contributed the code for that. I enjoyed running the service: It was heavily used and I enjoyed making contacts and setting up peers. Then layers 8 and 9 settled in. Commodity bandwidth became very expensive, and demand for bandwidth simultaneously exploded due to file sharing, legal or otherwise. My job became less of a matter of running a world-class service and more of a matter of "how do we throttle this thing, or just get rid of/outsource it?"--a question management would often ask. I spent a lot of time adjusting rate-limits for peers and at one point we ended up putting USENET into the scavenger class behind a packetshaper. An indignity, to be certain. By the time of the economic collapse, usage had declined sufficiently that USENET was easy for management to put on the chopping block. This, even though bandwidth had become much cheaper. My job (thanks to my USENET tasks and systems background) had evolved into more of a general network engineering position, and I had a surplus of interesting work to do, so it wasn't a major loss for me. Still, I am glad that USENET (and NNTP in particular) is going strong elsewhere. I learned a lot from running the service, and to this day, I am still one of the more "systemy" network engineers out there. I enjoy running DNS, NTP, and other system-based network services an much as I like configuring routers. I think running USENET a while back had a lot to do with that. michael From rsk at gsp.org Fri Mar 30 18:19:17 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 30 Mar 2012 19:19:17 -0400 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <201203302055.q2UKtEeb001448@aurora.sol.net> References: <4F761CBA.3000503@trelane.net> <201203302055.q2UKtEeb001448@aurora.sol.net> Message-ID: <20120330231917.GA22459@gsp.org> On Fri, Mar 30, 2012 at 03:55:14PM -0500, Joe Greco wrote: > Because NNTP is still alive and kicking. Of course it is. Usenet is *still* the best experiment ever run in the area of scalable, distributed forums, which I think is a tribute to the vision of its originators (and to the architects of NNTP). Newsgroups share a number of significant advantages with mailing lists -- not surprising, given their lineage and the observation that mailing lists have been unidirectionally or bidirectionally gatewayed with newsgroups for decades. 1. They're asynchronous: you don't have to interact in real time. You can download messages when connected to the 'net, then read them and compose responses when offline. 2. They work reasonably well even in the presence of multiple outages and severe congestion. 3. They're push, not pull, so new content just shows up. Web forums and social sites require that you go fishing for it. 4. They scale beautifully. 5. They allow you to use YOUR software with the user interface of YOUR choosing rather than being compelled to learn 687 different web forums with 687 different user interfaces, all of which range from "merely bad" to "hideously bad". 6. You can archive them locally... 7. ...which means you can search them locally with the software of YOUR choice. Including when you're offline. And provided you make backups, you'll always have that archive. 8. They're portable: lists and newsgroups can be rehosted relatively easily. 9. (When properly run) they're relatively free of abuse vectors. 10. They're low-bandwidth, which is especially important at a point in time when many people are interacting via metered services that charge by the byte. (Obviously I'm talking about text-only newsgroups in this point -- of course I am, they're the most important ones.) And so on. ---rsk From jlewis at lewis.org Fri Mar 30 18:31:20 2012 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 30 Mar 2012 19:31:20 -0400 (EDT) Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <201203302203.q2UM3wCg002284@aurora.sol.net> References: <201203302203.q2UM3wCg002284@aurora.sol.net> Message-ID: On Fri, 30 Mar 2012, Joe Greco wrote: > Those of us still doing work with USENET know that it isn't dead, far > from it, but we're aware that there's a certain amount of illicit > traffic. A certain amount? Even years and years ago, when I last ran a server, I'd wager porn and warez was statistically "all" of the traffic. > It's kind of like the way that pr0n and w4rez dominate all the Internet, > but this doesn't seem to faze Internet network operators. Perhaps because the pr0n and w4rez are just bits on the wire for most operators, not terabytes of disk space on servers we own. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From os10rules at gmail.com Fri Mar 30 18:36:01 2012 From: os10rules at gmail.com (Greg Ihnen) Date: Fri, 30 Mar 2012 19:06:01 -0430 Subject: airFiber (text of the 8 minute video) In-Reply-To: <218AB54691EB49439829EFD136F473CF2774E187@exchange2k10.corp.power1.com> References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> <5FF4C0E4-23FC-4BEC-989F-C7226186ED1C@gmail.com> <7F9D3BC0-A630-435F-A654-2E242730777C@delong.com> <218AB54691EB49439829EFD136F473CF2774E187@exchange2k10.corp.power1.com> Message-ID: <5F13D397-F0F9-4A96-8609-1B8E30B22653@gmail.com> On Mar 30, 2012, at 6:01 PM, Dylan Bouterse wrote: > A couple of thoughts. First, it's not fair to compare 24GHz to 2.4 or even 5Gig range due to the wave length. You will get 2.4GHz bleed through walls, windows, etc. VERY close to a 5GHz transmitter you may get some bleed through walls but not reliably. 24GHz will not propagate through objects as it's millimeter wavelength. That coupled with the fact it is a directional PTP product, you will be able to get a good amount of density of 24GHz PTP links using the same frequency in a small area (downtown for instance). The comparison isn't on wavelength, it's on the unlicensed-ness of it. Think CB vs Ham Radio. Where 2.4GHz and 5.8GHz are congested people have no where to go but up. You may not be alone up there. Guys already running 24GHz links might look at the sudden availability of cheap 24GHz gear in a different light. Granted there's many things in AirFiber's favor regarding congestion being less of a problem. The short range and high directivity, high cost, etc, but remember this isn't the only 24GHz product out there. In the kind of places where one of these links might be needed, others might have the same need. If you're thinking about the implications of possible congestion/interference when you're thinking about a link between the main office and the warehouse at a plant to give the guys in the warehouse internet that's not mission critical that's one thing. If it's key infrastructure for your ISP business then things start to look different. The licensed links start looking better regarding reliability down the road because you have a protected frequency. For ISPs out in farm country this is less of an issue, but in the more urban areas it is a concern. You start getting interference to your backhaul and you've got serious issues. You possibly have downgraded service or no service at many towers involving lots of customers. > > Another point, the GPS on the airFiber will also allow for frequency reuse to a point. I would like to see smaller channel sizes though. I hear it will be a software upgrade down the road. I'm shocked the old Canopy guys didn't code that into the first release to be honest. The GPS/reuse thing is for transmitters that are synced, that is transmitters belonging to the same system. Someone else's system won't be synced with yours and you won't see that benefit. So if you're thinking that's going to help between competitors it won't. Greg > > Dylan > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Thursday, March 29, 2012 7:18 PM > To: Oliver Garraux > Cc: NANOG list > Subject: Re: airFiber (text of the 8 minute video) > > > On Mar 29, 2012, at 12:33 PM, Oliver Garraux wrote: > >>> Also keep in mind this is unlicensed gear (think unprotected airspace). Nothing stops everyone else in town from throwing one up and soon you're drowning in a high noise floor and it goes slow or doesn't work at all. Like what's happened to 2.4GHz and 5.8GHz in a lot of places. There's few urban or semi-urban places where you still can use those frequencies for backhaul. The reason why people pay the big bucks for licenses and gear for licensed frequencies is you're buying insurance it's going to work in the future. >>> >>> Greg >> >> I was at Ubiquiti's conference. I don't disagree with what you're >> saying. Ubiquiti's take on it seemed to be that 24 Ghz would likely >> never be used to the extent that 2.4 / 5.8 is. They are seeing 24 Ghz >> as only for backhaul - no connections to end users. I guess >> point-to-multipoint connections aren't permitted by the FCC for 24 >> Ghz. AirFiber appears to be fairly highly directional. It needs to >> be though, as each link uses 100 Mhz, and there's only 250 Mhz >> available @ 24 Ghz. >> >> It also sounded like there was a decent possibility of supporting >> licensed 21 / 25 Ghz spectrum with AirFiber in the future. >> >> Oliver > > I don't think it's an FCC issue so much as 24Ghz has so much fade tendency with atmospheric moisture that an omnidirectional antenna is about as effective as a resistor coupled to ground (i.e. dummy load). > > The only way you can get a signal to go any real distance at that frequency is to use a highly directional high-gain antenna at both ends. > > Owen > > > > From gbonser at seven.com Fri Mar 30 18:59:46 2012 From: gbonser at seven.com (George Bonser) Date: Fri, 30 Mar 2012 23:59:46 +0000 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <65CCB887-E0BF-42F9-95E7-691208BE9E63@virtuaprise.com> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> <65CCB887-E0BF-42F9-95E7-691208BE9E63@virtuaprise.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D75160@RWC-MBX1.corp.seven.com> > No comment just a question... Why did it take so long? > > All good things must come to an end. and for NNTP that end was when > web based Forums software and P2P was invented. Seriously does anyone > still use UUCP for email? I thought it should have died when pr0n and > w4rez took it over (in the late 90's).. but that ended up fueling the > need :) Who is the Kim Dotcom of usenet? Lets bust him and move on. > > -Scott I think there is still a place for things like NNTP and UUCP but maybe not as they were used in the past. Private NNTP groups could be used to create discussion boards or even a coordination system for emergency response with each jurisdiction having its own group hierarchy. UUCP could be used to move mail and "news" between locations via telephone dial if the conventional internet is broken. UUCP has the advantage of moving email for entire domains rather than simply a user. It could be a good emergency backup or used in places where Internet connectivity is spotty/denied but telephone service is available. In fact I once had an idea of using NNTP as the "backend" database for a distributed ticketing system though it wouldn't "look" like NNTP from the UI. From MGauvin at dryden.ca Fri Mar 30 19:30:30 2012 From: MGauvin at dryden.ca (Mark Gauvin) Date: Fri, 30 Mar 2012 19:30:30 -0500 Subject: airFiber (text of the 8 minute video) In-Reply-To: <5F13D397-F0F9-4A96-8609-1B8E30B22653@gmail.com> References: <20120329163421.GS14482@leitl.org> <20120329164446.GA4669@puck.nether.net> <20120329173033.GJ60830@macbook.bluepipe.net> <09B459CC-91F8-4D0D-B4A3-7B632021990C@cookreport.com> <5FF4C0E4-23FC-4BEC-989F-C7226186ED1C@gmail.com> <7F9D3BC0-A630-435F-A654-2E242730777C@delong.com> <218AB54691EB49439829EFD136F473CF2774E187@exchange2k10.corp.power1.com>, <5F13D397-F0F9-4A96-8609-1B8E30B22653@gmail.com> Message-ID: <4DEA063ACE629740877D59B74D6FB2642406D290F5@exchange.citydryden.local> that statement posted a few days ago saying that the former Motorola Canopy team designed this product turned me off right away ________________________________________ From: Greg Ihnen [os10rules at gmail.com] Sent: Friday, March 30, 2012 6:36 PM To: Dylan Bouterse Cc: 'nanog at nanog.org' Subject: Re: airFiber (text of the 8 minute video) On Mar 30, 2012, at 6:01 PM, Dylan Bouterse wrote: > A couple of thoughts. First, it's not fair to compare 24GHz to 2.4 or even 5Gig range due to the wave length. You will get 2.4GHz bleed through walls, windows, etc. VERY close to a 5GHz transmitter you may get some bleed through walls but not reliably. 24GHz will not propagate through objects as it's millimeter wavelength. That coupled with the fact it is a directional PTP product, you will be able to get a good amount of density of 24GHz PTP links using the same frequency in a small area (downtown for instance). The comparison isn't on wavelength, it's on the unlicensed-ness of it. Think CB vs Ham Radio. Where 2.4GHz and 5.8GHz are congested people have no where to go but up. You may not be alone up there. Guys already running 24GHz links might look at the sudden availability of cheap 24GHz gear in a different light. Granted there's many things in AirFiber's favor regarding congestion being less of a problem. The short range and high directivity, high cost, etc, but remember this isn't the only 24GHz product out there. In the kind of places where one of these links might be needed, others might have the same need. If you're thinking about the implications of possible congestion/interference when you're thinking about a link between the main office and the warehouse at a plant to give the guys in the warehouse internet that's not mission critical that's one thing. If it's key infrastructure for your ISP business then things start to look different. The licensed links start looking better regarding reliability down the road because you have a protected frequency. For ISPs out in farm country this is less of an issue, but in the more urban areas it is a concern. You start getting interference to your backhaul and you've got serious issues. You possibly have downgraded service or no service at many towers involving lots of customers. > > Another point, the GPS on the airFiber will also allow for frequency reuse to a point. I would like to see smaller channel sizes though. I hear it will be a software upgrade down the road. I'm shocked the old Canopy guys didn't code that into the first release to be honest. The GPS/reuse thing is for transmitters that are synced, that is transmitters belonging to the same system. Someone else's system won't be synced with yours and you won't see that benefit. So if you're thinking that's going to help between competitors it won't. Greg > > Dylan > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Thursday, March 29, 2012 7:18 PM > To: Oliver Garraux > Cc: NANOG list > Subject: Re: airFiber (text of the 8 minute video) > > > On Mar 29, 2012, at 12:33 PM, Oliver Garraux wrote: > >>> Also keep in mind this is unlicensed gear (think unprotected airspace). Nothing stops everyone else in town from throwing one up and soon you're drowning in a high noise floor and it goes slow or doesn't work at all. Like what's happened to 2.4GHz and 5.8GHz in a lot of places. There's few urban or semi-urban places where you still can use those frequencies for backhaul. The reason why people pay the big bucks for licenses and gear for licensed frequencies is you're buying insurance it's going to work in the future. >>> >>> Greg >> >> I was at Ubiquiti's conference. I don't disagree with what you're >> saying. Ubiquiti's take on it seemed to be that 24 Ghz would likely >> never be used to the extent that 2.4 / 5.8 is. They are seeing 24 Ghz >> as only for backhaul - no connections to end users. I guess >> point-to-multipoint connections aren't permitted by the FCC for 24 >> Ghz. AirFiber appears to be fairly highly directional. It needs to >> be though, as each link uses 100 Mhz, and there's only 250 Mhz >> available @ 24 Ghz. >> >> It also sounded like there was a decent possibility of supporting >> licensed 21 / 25 Ghz spectrum with AirFiber in the future. >> >> Oliver > > I don't think it's an FCC issue so much as 24Ghz has so much fade tendency with atmospheric moisture that an omnidirectional antenna is about as effective as a resistor coupled to ground (i.e. dummy load). > > The only way you can get a signal to go any real distance at that frequency is to use a highly directional high-gain antenna at both ends. > > Owen > > > > From rodrick.brown at gmail.com Fri Mar 30 19:37:49 2012 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Fri, 30 Mar 2012 20:37:49 -0400 Subject: airFiber In-Reply-To: <3631ff80$65b2bbb3$4de71797$@com> References: <3631ff80$65b2bbb3$4de71797$@com> Message-ID: <5DB02571-0496-49DF-8C66-EE1BF69E2944@gmail.com> H. Hy Sent from my iPhone On Mar 29, 2012, at 2:01 PM, "Nick Olsen" wrote: > It will need perfect line of site. And won't deal with NLOS like most 2/5 > ghz gear can. It's 24ghz. > > They claim 15Km. Maybe in the desert. > > In any climate with rain, Like our's here in Florida even 2 miles is going > to be a stretch as 24ghz will rain fade easy. A great application for this > would be like between two buildings requiring highspeed backhaul. (Were > talking roof-top to roof-top of maybe a few thousand feet or more between > them. > > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Drew Weaver" > Sent: Thursday, March 29, 2012 1:27 PM > To: "Jared Mauch" , "Eugen Leitl" > Subject: RE: airFiber > > I've read that it requires perfect line of sight, which makes it sometimes > tricky. > > Thanks, > -Drew > > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Thursday, March 29, 2012 12:45 PM > To: Eugen Leitl > Cc: NANOG list > Subject: Re: airFiber > > On Thu, Mar 29, 2012 at 06:34:21PM +0200, Eugen Leitl wrote: >> >> Claim: 1.4 GBit/s over up to 13 km, 24 GHZ, @3 kUSD/link price point. >> >> http://www.ubnt.com/airfiber > > Yeah, I got this note the other day. I am very interested in hearing about > folks experience with this hardware once it ships. > > I almost posted it in the last-mile thread. Even compared to other > hardware in the space the price-performance of it for the bitrate is > amazing. > > I also recommend watching the video they posted: > > http://www.ubnt.com/themes/ubiquiti/air-fiber-video.html > > You are leaving out that it's an unlicensed band, so you can use this to > have a decent backhaul to your house just by rigging it yourself on each > end. > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared at puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > > From bzs at world.std.com Fri Mar 30 19:40:06 2012 From: bzs at world.std.com (Barry Shein) Date: Fri, 30 Mar 2012 20:40:06 -0400 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120330204119.GC23534@nntp.AegisInfoSys.com> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> Message-ID: <20342.21094.541311.963187@world.std.com> Just curious, what's the source of this uunet announcement (as in a link or cite, not "uunet!")? On March 30, 2012 at 16:41 henry at AegisInfoSys.com (Henry Yen) wrote: > uunet/vzb "will terminate its United States Newsreader and Newsfeed > services on March 31, 2012, with no plans to offer a replacement, and > any content/data remaining after that date will be unrecoverably deleted". > > does anyone on NANOG have any thoughtful comments on this? > > -- > Henry Yen Aegis Information Systems, Inc. > Senior Systems Programmer Hicksville, New York > 1-800-AEGIS-00 (800-234-4700) > -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From thomas.mangin at exa-networks.co.uk Fri Mar 30 19:43:40 2012 From: thomas.mangin at exa-networks.co.uk (Thomas Mangin) Date: Sat, 31 Mar 2012 01:43:40 +0100 Subject: French Regulator to ask all your information about your Peering In-Reply-To: <4F762A21.7080907@init7.net> References: <4F762A21.7080907@init7.net> Message-ID: Hi Fredy, On 30 Mar 2012, at 22:48, Fredy Kuenzler wrote: > Now, obviously, the French regulator sees the trouble and trys to understand > and 'regulate' it the way they do it usually. From our perspective certainly > not a good way, but why blaming the regulator? Blame those which made it all > happen! Read: the restrictive incumbents which put obstacles in the way of > everyone else. I wish the world was so simple .. There is reasons why incumbents do not peer. Each time I had the time to seat with one of their peering coordinator, I always got a good reason to why they did what they did. I do not always agree with all of them but most of the time I could not fail their logic. I am quite exasperated by the number of networks who believe they have a god given right to free peering (and this goes from small content with no backbone cost but lots of traffic to network which are seen as T1), perhaps Peering sould be called it "limited cross-transit contract with equal billing on each side " (ie: it is not free the invoice just contra themselves), even if it is a mouthful, it may better explain why it is not a right. And I agree with Raphael that once the asset are listed, it is sooo tempting to TAX the very profitable Internet industry. I am already hearing the **AA asking for an income per Mb of transfer to compensate for the piracy the ISP are sooo clearly accomplice of ( Time to add bandwidth to the list on http://en.wikipedia.org/wiki/Private_copying_levy ). Peering is an "abnormality" which regulators will have much need of help to understand and not destroy. As the thread names him, time to employ so more lobbyist to help Malcolm making sure they are kept at bay. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jeroen at mompl.net Fri Mar 30 19:57:19 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 30 Mar 2012 17:57:19 -0700 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <4F763AD7.30805@rancid.berkeley.edu> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> <4F763AD7.30805@rancid.berkeley.edu> Message-ID: <4F76566F.5020906@mompl.net> Michael Sinatra wrote: > active class newsgroups. As you can see from examples such as CS 61a ( > https://groups.google.com/group/ucb.class.cs61a/about?pli=1), Can someone help out mrshare? https://groups.google.com/group/ucb.class.cs61a/browse_frm/month/2010-08 The above link and this one are a fitting illustration of what has happened to usenet in the last decade and a half... > "systemy" network engineers out there. I enjoy running DNS, NTP, and > other system-based network services an much as I like configuring > routers. I think running USENET a while back had a lot to do with that. For the last 2 decades or so I have repeatedly tried to "get into" usenet. But every time I loose interest and give up. I am not entirely sure why because it can be a great source of information and to communicate. It's probably a combination of signal to noise ratio, epic flame wars, the user interface of many clients and the actual size (information overload ;-). But I am glad there exists something beyond "the web". Greetings, Jeroen -- Earthquake Magnitude: 5.2 Date: Friday, March 30, 2012 19:51:04 UTC Location: Bougainville region, Papua New Guinea Latitude: -6.6076; Longitude: 154.5824 Depth: 45.70 km From mfidelman at meetinghouse.net Fri Mar 30 20:34:16 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 30 Mar 2012 21:34:16 -0400 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D75160@RWC-MBX1.corp.seven.com> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> <65CCB887-E0BF-42F9-95E7-691208BE9E63@virtuaprise.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D75160@RWC-MBX1.corp.seven.com> Message-ID: <4F765F18.60806@meetinghouse.net> George Bonser wrote: >> No comment just a question... Why did it take so long? >> >> All good things must come to an end. and for NNTP that end was when >> web based Forums software and P2P was invented. Seriously does anyone >> still use UUCP for email? I thought it should have died when pr0n and >> w4rez took it over (in the late 90's).. but that ended up fueling the >> need :) Who is the Kim Dotcom of usenet? Lets bust him and move on. >> >> -Scott > I think there is still a place for things like NNTP and UUCP but maybe not as they were used in the past. Private NNTP groups could be used to create discussion boards or even a coordination system for emergency response with each jurisdiction having its own group hierarchy. UUCP could be used to move mail and "news" between locations via telephone dial if the conventional internet is broken. UUCP has the advantage of moving email for entire domains rather than simply a user. It could be a good emergency backup or used in places where Internet connectivity is spotty/denied but telephone service is available. > How many of you realize that JOPES (Joint Operation Planning and Execution System), used by the Pentagon for command and control at the Joint Chiefs level, uses classified newsgroups for distributing operations plans and orders? -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mfidelman at meetinghouse.net Fri Mar 30 20:36:53 2012 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 30 Mar 2012 21:36:53 -0400 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: References: <201203302203.q2UM3wCg002284@aurora.sol.net> Message-ID: <4F765FB5.4020206@meetinghouse.net> Jon Lewis wrote: > On Fri, 30 Mar 2012, Joe Greco wrote: > >> Those of us still doing work with USENET know that it isn't dead, far >> from it, but we're aware that there's a certain amount of illicit >> traffic. > > A certain amount? Even years and years ago, when I last ran a server, > I'd wager porn and warez was statistically "all" of the traffic. > >> It's kind of like the way that pr0n and w4rez dominate all the Internet, >> but this doesn't seem to faze Internet network operators. > > Perhaps because the pr0n and w4rez are just bits on the wire for most > operators, not terabytes of disk space on servers we own. Yeah.. but that's like saying video is all there is on the Internet. I don't know about the rest of you, but I exchange a LOT more email every day that the number of videos I watch, but... the bandwidth involved in all that email pretty trivial, even counting all the list traffic going through our list manager. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From mysidia at gmail.com Fri Mar 30 21:48:58 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 30 Mar 2012 21:48:58 -0500 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: References: <201203302203.q2UM3wCg002284@aurora.sol.net> Message-ID: On Fri, Mar 30, 2012 at 6:31 PM, Jon Lewis wrote: > Perhaps because the pr0n and w4rez are just bits on the wire for most > operators, not terabytes of disk space on servers we own. pr0n, w4rez, and other large binaries encoded with UUENCODE are easy to identify and block. It's not pr0n that's killing Usenet, the problem is spam junk mail chain letters E-mail address harvesters (where you get bombarded with direct-emailed crap if you dare post a message to USENET). And the like. The advantage 'forum sites' have is, you don't reveal your e-mail address to the public when posting. And automated spam sending can be mitigated through the use of CAPTCHAs. --- -JH From jgreco at ns.sol.net Fri Mar 30 22:06:21 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 30 Mar 2012 22:06:21 -0500 (CDT) Subject: uunet ends newsfeed/newsreader in US In-Reply-To: Message-ID: <201203310306.q2V36Lo8005084@aurora.sol.net> > On Fri, 30 Mar 2012, Joe Greco wrote: > > Those of us still doing work with USENET know that it isn't dead, far > > from it, but we're aware that there's a certain amount of illicit > > traffic. > > A certain amount? Even years and years ago, when I last ran a server, > I'd wager porn and warez was statistically "all" of the traffic. That clearly explains why glorb.com, a text-only transit site, is currently rated fifth. http://top1000.anthologeek.net/ > > It's kind of like the way that pr0n and w4rez dominate all the Internet, > > but this doesn't seem to faze Internet network operators. > > Perhaps because the pr0n and w4rez are just bits on the wire for most > operators, not terabytes of disk space on servers we own. Oddly enough, I'd think that "bits on the wire" are kind of expensive. Ports, circuits, etc. and those are on routers you own and circuits you lease. I can pick up a 4TB hard drive for $229. And that's currently an inflated price; back in September, 3TB drives were around $100. With traffic rates steady around 6TB/day for the past few years, IIRC, it isn't too fantastically expensive to store two weeks of binaries. Certainly cheaper than your average Cisco router. ... 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 henry at AegisInfoSys.com Fri Mar 30 22:15:58 2012 From: henry at AegisInfoSys.com (Henry Yen) Date: Fri, 30 Mar 2012 23:15:58 -0400 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20342.21094.541311.963187@world.std.com> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> <20342.21094.541311.963187@world.std.com> Message-ID: <20120331031558.GA10191@nntp.AegisInfoSys.com> On Fri, Mar 30, 2012 at 20:40:06PM -0400, Barry Shein wrote: > Just curious, what's the source of this uunet announcement (as in a > link or cite, not "uunet!")? > > On March 30, 2012 at 16:41 henry at AegisInfoSys.com (Henry Yen) wrote: > > uunet/vzb "will terminate its United States Newsreader and Newsfeed > > services on March 31, 2012, with no plans to offer a replacement, and > > any content/data remaining after that date will be unrecoverably deleted". it was a written letter to (some or all) transit customers of verizonbusiness. no, the word "uunet" isn't in there, but that's how i think of them, even before wcom and mci (and metro fiber). i was more interested in comments regarding the feed (nntp) side rather than the reader (lotsa choices, including gated feeds, dejanews/google, etc.). -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York 1-800-AEGIS-00 (800-234-4700) From gbonser at seven.com Fri Mar 30 22:57:44 2012 From: gbonser at seven.com (George Bonser) Date: Sat, 31 Mar 2012 03:57:44 +0000 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <4F765F18.60806@meetinghouse.net> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> <65CCB887-E0BF-42F9-95E7-691208BE9E63@virtuaprise.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D75160@RWC-MBX1.corp.seven.com> <4F765F18.60806@meetinghouse.net> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D75214@RWC-MBX1.corp.seven.com> > How many of you realize that JOPES (Joint Operation Planning and > Execution System), used by the Pentagon for command and control at the > Joint Chiefs level, uses classified newsgroups for distributing > operations plans and orders? > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > Seems perfectly reasonable to me. The NNTP protocol can be used for lots of things and not just public newsgroup discussions. For a company that has a lot of offices distributed around the world there could be many applications for it. It would also be pretty handy for emergency response for major natural disasters, too, for asynchronous communications between people, departments, etc. It lends itself easily to the forming of ad hoc teams and there is even access control possibilities with various groups of users having access to various hierarchies. It is a great tool that can be used for a lot of things without having to re-invent the wheel for collaboration, information sharing, etc. There's nothing obsolete about the NNTP protocol. Usenet might be obsolete, but NNTP can be quite useful. From jcdill.lists at gmail.com Fri Mar 30 23:45:28 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 30 Mar 2012 21:45:28 -0700 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120330215549.68551.qmail@joyce.lan> References: <20120330215549.68551.qmail@joyce.lan> Message-ID: <4F768BE8.1060604@gmail.com> On 30/03/12 2:55 PM, John Levine wrote: >>> I thought it should have died when pr0n and >>> w4rez took it over (in the late 90's).. > Many of the tech groups remain quite healthy. I still moderate > comp.compilers which gets about 100 posts/month. I'm on a handful of not-tech discussion groups which are still fairly active. However, one of them is busy dying as most of the discussion traffic moved to a Facebook group. (I'm also on a number of mailing lists that are quickly dying as most of their traffic is also moving to Facebook groups.) We had a thread a few weeks ago in one group after an ISP announced they were dropping usenet, and customers of that ISP were being pointed to aioe and eternal-september.org as alternates (for text-only newsgroups). jc From jcdill.lists at gmail.com Fri Mar 30 23:47:51 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 30 Mar 2012 21:47:51 -0700 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: References: <201203302203.q2UM3wCg002284@aurora.sol.net> Message-ID: <4F768C77.9040606@gmail.com> On 30/03/12 7:48 PM, Jimmy Hess wrote: > E-mail address harvesters (where you get bombarded with direct-emailed > crap if you dare post a message to USENET). I've been posting with a real gmail address for years, and google does an amazing job with filtering out the resulting spam, with very few false positives (mostly badly designed marketing email from companies I've opted n to receive marketing email from, and whose spam-trapped messages are no real loss). jc From johnl at iecc.com Sat Mar 31 01:55:48 2012 From: johnl at iecc.com (John R. Levine) Date: 31 Mar 2012 08:55:48 +0200 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: References: <201203302203.q2UM3wCg002284@aurora.sol.net> Message-ID: > It's not pr0n that's killing Usenet, the problem is spam > junk mail, chain letters I gather you haven't looked at usenet for a long time. The spam and chain letters have followed the crowd. I can't remember the last time I saw a chain letter, and there's surprisingly little spam. > E-mail address harvesters (where you get bombarded with direct-emailed > crap if you dare post a message to USENET). Spam sucks, but I've been posting to usenet with my real unmunged email address since 1981 and my inbox remains entirely usable. The idea that the way to avoid spam is to hide from spammers is so 1990s. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From mdr at tesp.com Sat Mar 31 01:58:46 2012 From: mdr at tesp.com (Michael Rathbun) Date: Fri, 30 Mar 2012 23:58:46 -0700 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: References: <201203302203.q2UM3wCg002284@aurora.sol.net> Message-ID: On 31 Mar 2012 08:55:48 +0200, "John R. Levine" wrote: >Spam sucks, but I've been posting to usenet with my real unmunged email >address since 1981 and my inbox remains entirely usable. The idea that >the way to avoid spam is to hide from spammers is so 1990s. So desu, ne. From landonstewart at gmail.com Sat Mar 31 02:10:23 2012 From: landonstewart at gmail.com (Landon Stewart) Date: Sat, 31 Mar 2012 00:10:23 -0700 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: References: <201203302203.q2UM3wCg002284@aurora.sol.net> Message-ID: <20120331071023.GA88878@Tesla.local> On 31 Mar 2012 08:55:48 +0200, "John R. Levine" wrote: >Spam sucks, but I've been posting to usenet with my real unmunged email >address since 1981 and my inbox remains entirely usable. The idea that >the way to avoid spam is to hide from spammers is so 1990s. LOL yer not kidding. https://www.google.ca/search?sourceid=chrome&ie=UTF-8&q=%22johnl%40iecc.com%22 --> About 60,800 results (0.27 seconds) -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": www.superb.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: not available URL: From marshall.eubanks at gmail.com Sat Mar 31 03:40:59 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Sat, 31 Mar 2012 04:40:59 -0400 Subject: airFiber In-Reply-To: <3631ff80$65b2bbb3$4de71797$@com> References: <3631ff80$65b2bbb3$4de71797$@com> Message-ID: On Thu, Mar 29, 2012 at 2:01 PM, Nick Olsen wrote: > It will need perfect line of site. And won't deal with NLOS like most 2/5 > ghz gear can. It's 24ghz. > At least on the East Coast, it would be best to install it during the summer. Put it up in winter, and any leaves that sprout in the path will likely cause a failure come spring. (And, if you're brought in to trouble-shoot a broken link, and the local techs swear that all the gear checks out fine, demand to go up on the roof and look down the line of sight first. It is satisfying to fix things without having to actually touch the equipment.) Regards Marshall > They claim 15Km. Maybe in the desert. > > In any climate with rain, Like our's here in Florida even 2 miles is going > to be a stretch as 24ghz will rain fade easy. A great application for this > would be like between two buildings requiring highspeed backhaul. (Were > talking roof-top to roof-top of maybe a few thousand feet or more between > them. > > Nick Olsen > Network Operations (855) FLSPEED ?x106 > > ---------------------------------------- > ?From: "Drew Weaver" > Sent: Thursday, March 29, 2012 1:27 PM > To: "Jared Mauch" , "Eugen Leitl" > Subject: RE: airFiber > > I've read that it requires perfect line of sight, which makes it sometimes > tricky. > > Thanks, > -Drew > > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Thursday, March 29, 2012 12:45 PM > To: Eugen Leitl > Cc: NANOG list > Subject: Re: airFiber > > On Thu, Mar 29, 2012 at 06:34:21PM +0200, Eugen Leitl wrote: >> >> Claim: 1.4 GBit/s over up to 13 km, 24 GHZ, @3 kUSD/link price point. >> >> http://www.ubnt.com/airfiber > > Yeah, I got this note the other day. ?I am very interested in hearing about > folks experience with this hardware once it ships. > > I almost posted it in the last-mile thread. ?Even compared to other > hardware in the space the price-performance of it for the bitrate is > amazing. > > I also recommend watching the video they posted: > > http://www.ubnt.com/themes/ubiquiti/air-fiber-video.html > > You are leaving out that it's an unlicensed band, so you can use this to > have a decent backhaul to your house just by rigging it yourself on each > end. > > - Jared > > -- > Jared Mauch ?| pgp key available via finger from jared at puck.nether.net > clue++; ? ? ?| http://puck.nether.net/~jared/ ?My statements are only > mine. > > From marshall.eubanks at gmail.com Sat Mar 31 04:05:46 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Sat, 31 Mar 2012 05:05:46 -0400 Subject: Attack on the DNS ? Message-ID: Anyone seen signs of this attack actually occurring ? http://www.nytimes.com/2012/03/31/technology/with-advance-warning-bracing-for-attack-on-internet-by-anonymous.html?_r=1 The message called it Operation Global Blackout, and rallied Anonymous supporters worldwide to attack the Domain Name System, which converts human-friendly domain names like google.com into numeric addresses that are more useful for computers. It declared when the attack would be carried out: March 31. And it detailed exactly how: by bombarding the Domain Name System with junk traffic in an effort to overwhelm it altogether. Regards Marshall From sh.vahabzadeh at gmail.com Sat Mar 31 04:38:49 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sat, 31 Mar 2012 14:08:49 +0430 Subject: Outdoor Wireless Access Point Message-ID: Hi there, I asked for a wireless solution for a university, in which they want indoor wireless solution for more than 5 building (at least two floor) and outdoor wireless solution for near 160m*280m garden. As I look for maps we need at least 3 or 4 outdoor radio, I think in these networks the best solution is to have only one SSID in whole network to give mobility for the network, is this called ad-hoc? or it has an other name? I do not know if I could ask question clearly or not, suppose we have 4 radio but only one SSID is broadcasting and when you are near the radio is near to you you will get service from that one, as this solution must be implement for indoor ones too. And if there is any good company which can both indoor and outdoor solution and they have shipping to Iran too or reseller in Iran please give me the url. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From sthaug at nethelp.no Sat Mar 31 05:01:33 2012 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 31 Mar 2012 12:01:33 +0200 (CEST) Subject: Attack on the DNS ? In-Reply-To: References: Message-ID: <20120331.120133.74748382.sthaug@nethelp.no> > Anyone seen signs of this attack actually occurring ? > > http://www.nytimes.com/2012/03/31/technology/with-advance-warning-bracing-for-attack-on-internet-by-anonymous.html?_r=1 >From my vantage point in Oslo, Norway, there is no sign of any attack occurring. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From smutt at depht.com Sat Mar 31 05:12:27 2012 From: smutt at depht.com (Andrew McConachie) Date: Sat, 31 Mar 2012 13:12:27 +0300 Subject: airFiber In-Reply-To: References: <3631ff80$65b2bbb3$4de71797$@com> Message-ID: Is this any different than what GigaBeam tried before they went bankrupt. http://www.globenewswire.com/newsroom/news.html?d=177145 Their website only shows a control panel login now so I think they've gone completely out of business. The only reason I know about them is because one of my customers used two of their radios for a p2p 1G link and it was a disaster. The Gigabeam radios tried to transparently act as L1 devices. They were just converting optical energy to radio energy. They didn't act as bridges. So if you plugged a switch into either end each switch would think it had an L1 connection to the other switch. It would work with certain optics and certain firmware versions of certain switches. But if you changed anything you might get link and you might not. I hope these Ubiquity devices actually maintain link even if the radio connection goes down. On Sat, Mar 31, 2012 at 11:40 AM, Marshall Eubanks wrote: > On Thu, Mar 29, 2012 at 2:01 PM, Nick Olsen wrote: >> It will need perfect line of site. And won't deal with NLOS like most 2/5 >> ghz gear can. It's 24ghz. >> > > At least on the East Coast, it would be best to install it during the > summer. Put it up in winter, and any leaves that sprout in the path > will likely cause a failure come spring. (And, if you're brought in to > trouble-shoot a broken link, and the local techs swear that all the > gear checks out fine, demand to go up on the roof and look down the > line of sight first. It is satisfying to fix things without having to > actually touch the equipment.) > > Regards > Marshall > >> They claim 15Km. Maybe in the desert. >> >> In any climate with rain, Like our's here in Florida even 2 miles is going >> to be a stretch as 24ghz will rain fade easy. A great application for this >> would be like between two buildings requiring highspeed backhaul. (Were >> talking roof-top to roof-top of maybe a few thousand feet or more between >> them. >> >> Nick Olsen >> Network Operations (855) FLSPEED ?x106 >> >> ---------------------------------------- >> ?From: "Drew Weaver" >> Sent: Thursday, March 29, 2012 1:27 PM >> To: "Jared Mauch" , "Eugen Leitl" >> Subject: RE: airFiber >> >> I've read that it requires perfect line of sight, which makes it sometimes >> tricky. >> >> Thanks, >> -Drew >> >> -----Original Message----- >> From: Jared Mauch [mailto:jared at puck.nether.net] >> Sent: Thursday, March 29, 2012 12:45 PM >> To: Eugen Leitl >> Cc: NANOG list >> Subject: Re: airFiber >> >> On Thu, Mar 29, 2012 at 06:34:21PM +0200, Eugen Leitl wrote: >>> >>> Claim: 1.4 GBit/s over up to 13 km, 24 GHZ, @3 kUSD/link price point. >>> >>> http://www.ubnt.com/airfiber >> >> Yeah, I got this note the other day. ?I am very interested in hearing about >> folks experience with this hardware once it ships. >> >> I almost posted it in the last-mile thread. ?Even compared to other >> hardware in the space the price-performance of it for the bitrate is >> amazing. >> >> I also recommend watching the video they posted: >> >> http://www.ubnt.com/themes/ubiquiti/air-fiber-video.html >> >> You are leaving out that it's an unlicensed band, so you can use this to >> have a decent backhaul to your house just by rigging it yourself on each >> end. >> >> - Jared >> >> -- >> Jared Mauch ?| pgp key available via finger from jared at puck.nether.net >> clue++; ? ? ?| http://puck.nether.net/~jared/ ?My statements are only >> mine. >> >> > From bortzmeyer at nic.fr Sat Mar 31 05:45:37 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 31 Mar 2012 12:45:37 +0200 Subject: Attack on the DNS ? In-Reply-To: <17943_1333190624_4F76DFE0_17943_10732_1_CAJNg7V+6JWwhvVfbrpXvx_Ex-o1vHfSpmHksBA+2mUrPFELvJA@mail.gmail.com> References: <17943_1333190624_4F76DFE0_17943_10732_1_CAJNg7V+6JWwhvVfbrpXvx_Ex-o1vHfSpmHksBA+2mUrPFELvJA@mail.gmail.com> Message-ID: <20120331104537.GA16283@sources.org> On Sat, Mar 31, 2012 at 05:05:46AM -0400, Marshall Eubanks wrote a message of 17 lines which said: > Anyone seen signs of this attack actually occurring ? For serious information about this issue, see: https://www.dns-oarc.net/wiki/mitigating-dns-denial-of-service-attacks http://www.cricketondns.com/post.cfm/could-a-ddos-attack-against-the-roots-succeed I do not repost here the various real-rime monitoring systems (which show no attack on the root name servers) because these systems will probably be the first victims of the attack, with all the people using them to watch the end of the world :-) From rubensk at gmail.com Sat Mar 31 08:02:41 2012 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 31 Mar 2012 10:02:41 -0300 Subject: airFiber In-Reply-To: <20120329163421.GS14482@leitl.org> References: <20120329163421.GS14482@leitl.org> Message-ID: On Thu, Mar 29, 2012 at 1:34 PM, Eugen Leitl wrote: > > Claim: 1.4 GBit/s over up to 13 km, 24 GHZ, @3 kUSD/link price point. > > http://www.ubnt.com/airfiber Claims are actually "Up to 1.4 Gbps" and "Up to 13 km"; those two conditions probably cannot be satisfied together. 1.4 Gbps is actually 700 Mbps per direction. Modulations are 64 QAM, 16 QAM and QPSK (all MIMO) and QPSK (SISO), so we can guess the throughput of each data rate as: 64QAM MIMO - 720 Mbps (changed from 700 Mbps for numerical convenience) 16QAM MIMO - 480 Mbps QPSK MIMO - 240 Mbps QPSK SISO - 120 Mbps Rubens From ml at kenweb.org Sat Mar 31 08:14:46 2012 From: ml at kenweb.org (ML) Date: Sat, 31 Mar 2012 09:14:46 -0400 Subject: airFiber In-Reply-To: References: <3631ff80$65b2bbb3$4de71797$@com> Message-ID: <4F770346.9070609@kenweb.org> On 3/31/2012 6:12 AM, Andrew McConachie wrote: > Is this any different than what GigaBeam tried before they went bankrupt. > http://www.globenewswire.com/newsroom/news.html?d=177145 > > Their website only shows a control panel login now so I think they've > gone completely out of business. The only reason I know about them is > because one of my customers used two of their radios for a p2p 1G link > and it was a disaster. The Gigabeam radios tried to transparently act > as L1 devices. They were just converting optical energy to radio > energy. They didn't act as bridges. So if you plugged a switch into > either end each switch would think it had an L1 connection to the > other switch. > > It would work with certain optics and certain firmware versions of > certain switches. But if you changed anything you might get link and > you might not. > > I hope these Ubiquity devices actually maintain link even if the radio > connection goes down. > Often such a feature is an option within the radio configuration. Where wired side link follows wireless link. To me that never seemed like a good idea because I need to get into the radio during a wireless link-down situation. Maybe if there was an OOB ethernet port it could work but I haven't seen them on any radio I've touched. From faisal at snappydsl.net Sat Mar 31 08:41:23 2012 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Sat, 31 Mar 2012 09:41:23 -0400 Subject: Outdoor Wireless Access Point In-Reply-To: References: Message-ID: I understand Ubiquity gear is very common, in use and available in Iran ... Look at their unifi product line. Faisal On Mar 31, 2012, at 5:38 AM, Shahab Vahabzadeh wrote: > Hi there, > I asked for a wireless solution for a university, in which they want indoor > wireless solution for more than 5 building (at least two floor) and outdoor > wireless solution for near 160m*280m garden. > As I look for maps we need at least 3 or 4 outdoor radio, I think in these > networks the best solution is to have only one SSID in whole network to > give mobility for the network, is this called ad-hoc? or it has an other > name? > I do not know if I could ask question clearly or not, suppose we have 4 > radio but only one SSID is broadcasting and when you are near the radio is > near to you you will get service from that one, as this solution must be > implement for indoor ones too. > And if there is any good company which can both indoor and outdoor solution > and they have shipping to Iran too or reseller in Iran please give me the > url. > Thanks > > -- > Regards, > Shahab Vahabzadeh, Network Engineer and System Administrator > > Cell Phone: +1 (415) 871 0742 > PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 > From streiner at cluebyfour.org Sat Mar 31 09:16:26 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 31 Mar 2012 10:16:26 -0400 (EDT) Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <201203310306.q2V36Lo8005084@aurora.sol.net> References: <201203310306.q2V36Lo8005084@aurora.sol.net> Message-ID: On Fri, 30 Mar 2012, Joe Greco wrote: > Oddly enough, I'd think that "bits on the wire" are kind of expensive. > Ports, circuits, etc. and those are on routers you own and circuits you > lease. > > I can pick up a 4TB hard drive for $229. And that's currently an > inflated price; back in September, 3TB drives were around $100. With > traffic rates steady around 6TB/day for the past few years, IIRC, it > isn't too fantastically expensive to store two weeks of binaries. > Certainly cheaper than your average Cisco router. I would agree. When I still worked for an ISP, we outsourced our way out of the NNTP business around 2001 or so. Disk was much more expensive at that time, as was bandwidth. While I was successful in the mandate I got from the CEO in 1997 ("Our news server sucks. I want you to make it kick ass.") and got our feeder up into the 300 range on the Freenix top 1000, it became apparent pretty quickly that the amount of money we were spending on bandwidth to sling all of that NNTP traffic around the net, and the $$ we would've had to spend on a larger disk array to keep retention times on the warez/por--- er... 'alt.binaries.*' groups would have been impossible to justify. Like most ISPs, we didn't charge a separate fee for access to the news server, so it was essentially a non-revenue service. Sure, there were a very small handful of die-hard news users who bought their service from us solely because our news server was good, but there were not enough of those users to justify the continued expense of running it, so we got out of that game. I think we outsourced to Remarq, or whatever their name was before it became Remarq, and as far as I knew, some of the die-hard users didn't know the difference, or didn't care enough to switch providers. jms From matthew at matthew.at Sat Mar 31 09:33:56 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 31 Mar 2012 07:33:56 -0700 Subject: airFiber In-Reply-To: <4F770346.9070609@kenweb.org> References: <3631ff80$65b2bbb3$4de71797$@com> <4F770346.9070609@kenweb.org> Message-ID: <4F7715D4.3040307@matthew.at> On 3/31/2012 6:14 AM, ML wrote: > > Often such a feature is an option within the radio configuration. > Where wired side > link follows wireless link. To me that never seemed like a good idea > because I need > to get into the radio during a wireless link-down situation. Maybe if > there was > an OOB ethernet port it could work but I haven't seen them on any > radio I've touched. > The Exalt radios, both licensed and unlicensed, have an OOB port. Quite handy for exactly this reason. I've had one of their EX-5r-c GigE pairs running at full rate on a 14 mile path for years now with no problems except when the garbage truck parks in front of the path briefly once a week. Matthew Kaufman From tal at whatexit.org Sat Mar 31 09:34:17 2012 From: tal at whatexit.org (Tom Limoncelli) Date: Sat, 31 Mar 2012 10:34:17 -0400 Subject: RFC 2410: NULL is not a joke (nor an April Fools joke) Message-ID: In 2007 when Peter H. Salus and I published all the April Fools RFCs in one book we also included the poetry RFCs and the funny RFCs published outside of April Fools timeframe. Speaking of which... we included "RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec" because, well, I thought it was funny. Specifying an encryption scheme for IPsec that does not encrypt the bytes is, well, funny. It turns out it wasn't published as a joke. Oops. No offense meant to the authors R. Glenn and S. Kent. Nobody pointed this out to me until years after the book was printed. Sadly because this book is printed on dead trees we can't "take it back". We don't have a new edition that includes the 2008-2013 RFCs but those are pretty easy to find online. The book does include some commentary that isn't available on-line including forewords by Mike O'Dell, Scott Bradner, and Brad Templeton. I re-read them today and was impressed at how they have stood the test of time. More about the book here: http://rfchumor.com/ Order it on Amazon here: http://www.amazon.com/o/ASIN/1573980420/tomontime-20 Tom Limoncelli -- http://EverythingSysadmin.com? -- my blog http://www.TomOnTime.com?-- my videos From ml at kenweb.org Sat Mar 31 09:48:11 2012 From: ml at kenweb.org (ML) Date: Sat, 31 Mar 2012 10:48:11 -0400 Subject: Outdoor Wireless Access Point In-Reply-To: References: Message-ID: <4F77192B.3030709@kenweb.org> On 3/31/2012 9:41 AM, Faisal Imtiaz wrote: > I understand Ubiquity gear is very common, in use and available in Iran ... > Look at their unifi product line. > > Faisal > > On Mar 31, 2012, at 5:38 AM, Shahab Vahabzadeh wrote: > >> Hi there, >> I asked for a wireless solution for a university, in which they want indoor >> wireless solution for more than 5 building (at least two floor) and outdoor >> wireless solution for near 160m*280m garden. >> As I look for maps we need at least 3 or 4 outdoor radio, I think in these >> networks the best solution is to have only one SSID in whole network to >> give mobility for the network, is this called ad-hoc? or it has an other >> name? >> I do not know if I could ask question clearly or not, suppose we have 4 >> radio but only one SSID is broadcasting and when you are near the radio is >> near to you you will get service from that one, as this solution must be >> implement for indoor ones too. >> And if there is any good company which can both indoor and outdoor solution >> and they have shipping to Iran too or reseller in Iran please give me the >> url. >> Thanks >> >> -- >> Regards, >> Shahab Vahabzadeh, Network Engineer and System Administrator >> >> Cell Phone: +1 (415) 871 0742 >> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 >> As far as I know Ubiquiti's UniFi product doesn't yet have a single SSID across multiple APs. Ruckus does have indoor and outdoor APs that when used in conjuction with their ZoneDirector product will provide a seemless SSID. I do not know if it is available in Iran though. From mloftis at wgops.com Sat Mar 31 09:48:43 2012 From: mloftis at wgops.com (Michael Loftis) Date: Sat, 31 Mar 2012 08:48:43 -0600 Subject: airFiber In-Reply-To: <4F770346.9070609@kenweb.org> References: <3631ff80$65b2bbb3$4de71797$@com> <4F770346.9070609@kenweb.org> Message-ID: On Sat, Mar 31, 2012 at 7:14 AM, ML wrote: > Often such a feature is an option within the radio configuration. Where > wired side > link follows wireless link. ?To me that never seemed like a good idea > because I need > to get into the radio during a wireless link-down situation. ?Maybe if there > was > an OOB ethernet port it could work but I haven't seen them on any radio I've > touched. > These have an 100MB OOB management port, a 1GigE port, and a RJ45 for a speaker/tone device for aiding alignment. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From rsk at gsp.org Sat Mar 31 10:49:22 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 31 Mar 2012 11:49:22 -0400 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: References: <201203302203.q2UM3wCg002284@aurora.sol.net> Message-ID: <20120331154922.GA26765@gsp.org> On Fri, Mar 30, 2012 at 09:48:58PM -0500, Jimmy Hess wrote: > E-mail address harvesters (where you get bombarded with direct-emailed > crap if you dare post a message to USENET). Insignificant: email address harvesting activity, in toto, on Usenet, is tiny compared to that conducted elsewhere. (A few moments' thought will suggest why.) > The advantage 'forum sites' have is, you don't reveal your e-mail > address to the public when posting. That's a bug, not a feature. And "forum sites" lack the far more important features that I enumerated in another message in this thread. > And automated spam sending can be mitigated through the use of CAPTCHAs. Captchas have been quite, quite thoroughly beaten for some time. ---rsk p.s. Before anyone says "but *my* captchas appear to be working", let me suggest this exchange as guidance: "Londo, they could've killed me!" "Nonsense, you are not important enough to kill." From blake at beamspeed.com Sat Mar 31 11:53:35 2012 From: blake at beamspeed.com (Blake Covarrubias) Date: Sat, 31 Mar 2012 09:53:35 -0700 Subject: airFiber In-Reply-To: <4F770346.9070609@kenweb.org> References: <3631ff80$65b2bbb3$4de71797$@com> <4F770346.9070609@kenweb.org> Message-ID: <0044DB8C-2393-4D97-90B8-D90F8755A8E7@beamspeed.com> > Often such a feature is an option within the radio configuration. Where wired side > link follows wireless link. To me that never seemed like a good idea because I need > to get into the radio during a wireless link-down situation. Maybe if there was > an OOB ethernet port it could work but I haven't seen them on any radio I've touched. I have Trango, DragonWave, Motorola & SAF Tehnika PTP gear in my network. All of them have OOB Ethernet. This feature is common, if not standard, for modern microwave backhaul. -- Blake Covarrubias From jmaslak at antelope.net Sat Mar 31 11:56:12 2012 From: jmaslak at antelope.net (Joel Maslak) Date: Sat, 31 Mar 2012 10:56:12 -0600 Subject: Outdoor Wireless Access Point In-Reply-To: References: Message-ID: <9DC0FE19-8CCC-45DE-8F94-F4E6618E58AE@antelope.net> On Mar 31, 2012, at 3:38 AM, Shahab Vahabzadeh wrote: > As I look for maps we need at least 3 or 4 outdoor radio, I think in these > networks the best solution is to have only one SSID in whole network to > give mobility for the network, is this called ad-hoc? or it has an other > name? No, it's still infrastructure mode, not ad-hoc. Ad-hoc means "no access point". All you need to do is set the APs up to use the same SSID and authentication methods, keys, etc. It's pretty simple and can even be done with consumer gear (with less stable performance of course). If you don't put the APs all on the same layer 3 LAN (same subnet), you'll need some sort of controller-based solutions so that a user's IP address still makes sense to their computer when they move from one AP to another. If you can keep all the APs on one subnet, you won't need that. It gets a bit more complex if you are using radio to link buildings together and/or backhaul to the access point. There's plenty of good references on the internet. Note that the wireless handoffs aren't perfect on basic 802.11 gear. Your laptop might not pick the best AP if it can hear multiple APs. And you might lose a few packets when you hand-off between APs, but it's typically no big deal. Your ssh session would stay connected across those hand-offs just fine. If you plan on doing VoIP on the wireless, it gets more complex yet - you have to worry about the time it takes handoffs and that can be more complex. You have to implement WMM and DSCP. You need to worry about low-speed users (1mbps, 2mbps, etc) on the same link. It's a lot harder to build a VoIP wireless solution than a web browsing wireless solution, but still plentty possible to do without expensive equipment. In summary: you probably should find a guide on how to build wireless networks, preferably a vendor agnostic one. You will either be the hero of your organization or the enemy, depending on how well your network works. From maxsec at gmail.com Sat Mar 31 12:02:25 2012 From: maxsec at gmail.com (Martin Hepworth) Date: Sat, 31 Mar 2012 18:02:25 +0100 Subject: Outdoor Wireless Access Point In-Reply-To: <4F77192B.3030709@kenweb.org> References: <4F77192B.3030709@kenweb.org> Message-ID: On Saturday, 31 March 2012, ML wrote: > On 3/31/2012 9:41 AM, Faisal Imtiaz wrote: > >> I understand Ubiquity gear is very common, in use and available in Iran >> ... >> Look at their unifi product line. >> >> Faisal >> >> On Mar 31, 2012, at 5:38 AM, Shahab Vahabzadeh >> wrote: >> >> Hi there, >>> I asked for a wireless solution for a university, in which they want >>> indoor >>> wireless solution for more than 5 building (at least two floor) and >>> outdoor >>> wireless solution for near 160m*280m garden. >>> As I look for maps we need at least 3 or 4 outdoor radio, I think in >>> these >>> networks the best solution is to have only one SSID in whole network to >>> give mobility for the network, is this called ad-hoc? or it has an other >>> name? >>> I do not know if I could ask question clearly or not, suppose we have 4 >>> radio but only one SSID is broadcasting and when you are near the radio >>> is >>> near to you you will get service from that one, as this solution must be >>> implement for indoor ones too. >>> And if there is any good company which can both indoor and outdoor >>> solution >>> and they have shipping to Iran too or reseller in Iran please give me the >>> url. >>> Thanks >>> >>> -- >>> Regards, >>> Shahab Vahabzadeh, Network Engineer and System Administrator >>> >>> Cell Phone: +1 (415) 871 0742 >>> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 >>> >>> As far as I know Ubiquiti's UniFi product doesn't yet have a single > SSID across multiple APs. > Ruckus does have indoor and outdoor APs that when used in conjuction with > their > ZoneDirector product will provide a seemless SSID. I do not know if it is > available in Iran though. > > Yes it does and can have a guest SSID as well along with hand off to a ticket server http://www.ubnt.com/unifi Check out the specs Nice and cheap compared to others on the market too -- Martin -- -- Martin Hepworth Oxford, UK From oliver at g.garraux.net Sat Mar 31 12:09:56 2012 From: oliver at g.garraux.net (Oliver Garraux) Date: Sat, 31 Mar 2012 13:09:56 -0400 Subject: Outdoor Wireless Access Point In-Reply-To: <4F77192B.3030709@kenweb.org> References: <4F77192B.3030709@kenweb.org> Message-ID: > As far as I know Ubiquiti's UniFi product doesn't yet have a single SSID > across multiple APs. Unifi does use the same SSID's across many AP's. It actually does that by default, unless you specifically disable an SSID on a particular AP. Oliver From sh.vahabzadeh at gmail.com Sat Mar 31 12:17:02 2012 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Sat, 31 Mar 2012 21:47:02 +0430 Subject: Outdoor Wireless Access Point In-Reply-To: <9DC0FE19-8CCC-45DE-8F94-F4E6618E58AE@antelope.net> References: <9DC0FE19-8CCC-45DE-8F94-F4E6618E58AE@antelope.net> Message-ID: Yes Its VoIP over wireless, mostly this university need this wireless network for their professions and students which carry their IP Phones and I care about this. Thanks On Sat, Mar 31, 2012 at 9:26 PM, Joel Maslak wrote: > On Mar 31, 2012, at 3:38 AM, Shahab Vahabzadeh > wrote: > > > As I look for maps we need at least 3 or 4 outdoor radio, I think in > these > > networks the best solution is to have only one SSID in whole network to > > give mobility for the network, is this called ad-hoc? or it has an other > > name? > > No, it's still infrastructure mode, not ad-hoc. > > Ad-hoc means "no access point". > > All you need to do is set the APs up to use the same SSID and > authentication methods, keys, etc. It's pretty simple and can even be done > with consumer gear (with less stable performance of course). If you don't > put the APs all on the same layer 3 LAN (same subnet), you'll need some > sort of controller-based solutions so that a user's IP address still makes > sense to their computer when they move from one AP to another. If you can > keep all the APs on one subnet, you won't need that. > > It gets a bit more complex if you are using radio to link buildings > together and/or backhaul to the access point. There's plenty of good > references on the internet. > > Note that the wireless handoffs aren't perfect on basic 802.11 gear. Your > laptop might not pick the best AP if it can hear multiple APs. And you > might lose a few packets when you hand-off between APs, but it's typically > no big deal. Your ssh session would stay connected across those hand-offs > just fine. > > If you plan on doing VoIP on the wireless, it gets more complex yet - you > have to worry about the time it takes handoffs and that can be more > complex. You have to implement WMM and DSCP. You need to worry about > low-speed users (1mbps, 2mbps, etc) on the same link. It's a lot harder to > build a VoIP wireless solution than a web browsing wireless solution, but > still plentty possible to do without expensive equipment. > > In summary: you probably should find a guide on how to build wireless > networks, preferably a vendor agnostic one. You will either be the hero of > your organization or the enemy, depending on how well your network works. -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From cfillekes at gmail.com Sat Mar 31 13:12:32 2012 From: cfillekes at gmail.com (C. A. Fillekes) Date: Sat, 31 Mar 2012 13:12:32 -0500 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <4F76566F.5020906@mompl.net> References: <20120330204119.GC23534@nntp.AegisInfoSys.com> <4F763AD7.30805@rancid.berkeley.edu> <4F76566F.5020906@mompl.net> Message-ID: USENET is definitely not dead. I wrote a search engine and aggregator for multipart articles posted to USENET binary groups over the course of a year and a half at the largest providor of USENET services in the world -- just a couple years ago. The data rates of incoming articles was just staggering...and growing by the day. One of the members of my development team on the USENET binary search engine project had been a principal at UUNET, so I do have a pretty good idea what happened to that outfit, organisationally. The details are unimportant. I do not think that the closing of a service that's undergone multiple acquisitions by actual competitors is at all surprising. Did the closing of Alta Vista a couple years ago after its acquisition by Yahoo! spell the death of internet search? No. From jvanoppen at spectrumnet.us Sat Mar 31 13:21:57 2012 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Sat, 31 Mar 2012 18:21:57 +0000 Subject: airFiber In-Reply-To: References: <3631ff80$65b2bbb3$4de71797$@com> Message-ID: We actually have a lot of the old gigabeam radios in service, they are faster than the published specs of the airfiber links (1G full duplex vs 750 mbit/sec fd) and lower latency due to their very simplistic design. To be honest, from a network engineering standpoint, the gigabeams were conveninet as path issues would show up as ethernet errors that can be used to trigger reroutes or other events. That being said, we did not have a large variety of switches as the microwave side of our house is made up entirely of just a couple of cisco models. The gigabeams also have a pure OOB management setup. John From adrian.minta at gmail.com Sat Mar 31 13:26:25 2012 From: adrian.minta at gmail.com (Adrian Minta) Date: Sat, 31 Mar 2012 21:26:25 +0300 Subject: Attack on the DNS ? In-Reply-To: References: Message-ID: <4F774C51.3000805@gmail.com> We already have this type of attack in Bucharest/Romania since last Friday. The targets where IP's of some local webhosters, but at one moment we event saw IP's from Go Daddy. Tcpdump will show something like: 11:10:41.447079 IP target > open_resolver_ip.53: 80+ [1au] ANY? isc.org. (37) 11:10:41.447082 IP target > open_resolver_ip.53: 59147+ [1au] ANY? isc.org. (37) 11:10:41.447084 IP target > open_resolver_ip.53: 13885+ [1au] ANY? isc.org. (37) After one week the attack has been mostly mitigated, and the remaining open resolvers are probably windows servers. Apparently in bill'g world is impossible to restrict the recursion. From jared at puck.nether.net Sat Mar 31 14:18:42 2012 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 31 Mar 2012 15:18:42 -0400 Subject: Outdoor Wireless Access Point In-Reply-To: References: <4F77192B.3030709@kenweb.org> Message-ID: <03CC35C2-4909-44B4-9F1B-F6B4097020E7@puck.nether.net> Another +1 on unifi. Very happy with price and performance. Jared Mauch On Mar 31, 2012, at 1:09 PM, Oliver Garraux wrote: >> As far as I know Ubiquiti's UniFi product doesn't yet have a single SSID >> across multiple APs. > > Unifi does use the same SSID's across many AP's. It actually does > that by default, unless you specifically disable an SSID on a > particular AP. > > Oliver From Valdis.Kletnieks at vt.edu Sat Mar 31 15:10:35 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 31 Mar 2012 16:10:35 -0400 Subject: Attack on the DNS ? In-Reply-To: Your message of "Sat, 31 Mar 2012 05:05:46 -0400." References: Message-ID: <66524.1333224635@turing-police.cc.vt.edu> On Sat, 31 Mar 2012 05:05:46 -0400, Marshall Eubanks said: > Anyone seen signs of this attack actually occurring ? > > http://www.nytimes.com/2012/03/31/technology/with-advance-warning-bracing-for-attack-on-internet-by-anonymous.html?_r=1 "Those preparations turned into a fast-track, multimillion-dollar global effort to beef up the Domain Name System. They offer a glimpse into the largely unknown forces that keep the Internet running in the face of unpredictable, potentially devastating threats." Was there *really* that much of a reaction to *this* threat, over and above the continual 24x7x365 ongoing effort to add resiliency and mitigation to the DNS? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From ml at kenweb.org Sat Mar 31 15:22:30 2012 From: ml at kenweb.org (ML) Date: Sat, 31 Mar 2012 16:22:30 -0400 Subject: Outdoor Wireless Access Point In-Reply-To: References: <4F77192B.3030709@kenweb.org> Message-ID: <4F776786.1050607@kenweb.org> On 3/31/2012 1:09 PM, Oliver Garraux wrote: >> As far as I know Ubiquiti's UniFi product doesn't yet have a single SSID >> across multiple APs. > Unifi does use the same SSID's across many AP's. It actually does > that by default, unless you specifically disable an SSID on a > particular AP. > > Oliver > Well I know UBNT is always improving their firmware so good. A year back I got the impression their software didn't support roaming and wireless clients would see multiple SSIDs with the same name instead of just one. From sthaug at nethelp.no Sat Mar 31 15:28:17 2012 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 31 Mar 2012 22:28:17 +0200 (CEST) Subject: Attack on the DNS ? In-Reply-To: <4F774C51.3000805@gmail.com> References: <4F774C51.3000805@gmail.com> Message-ID: <20120331.222817.74728386.sthaug@nethelp.no> > We already have this type of attack in Bucharest/Romania since last > Friday. The targets where IP's of some local webhosters, but at one > moment we event saw IP's from Go Daddy. > Tcpdump will show something like: > 11:10:41.447079 IP target > open_resolver_ip.53: 80+ [1au] ANY? isc.org. > (37) > 11:10:41.447082 IP target > open_resolver_ip.53: 59147+ [1au] ANY? > isc.org. (37) > 11:10:41.447084 IP target > open_resolver_ip.53: 13885+ [1au] ANY? > isc.org. (37) > > After one week the attack has been mostly mitigated, and the remaining > open resolvers are probably windows servers. Apparently in bill'g world > is impossible to restrict the recursion. This is a spoofed source amplification/reflection attack, and is really going on all the time. It has nothing to do with any possible Anonymous attack on the root name servers. ANY queries for isc.org and ripe.net are popular (ietf.org has also been seen), since they give a potentially large amplification factor. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From johnl at iecc.com Sat Mar 31 15:36:52 2012 From: johnl at iecc.com (John Levine) Date: 31 Mar 2012 20:36:52 -0000 Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D75214@RWC-MBX1.corp.seven.com> Message-ID: <20120331203652.5282.qmail@joyce.lan> >Seems perfectly reasonable to me. The NNTP protocol can be used for >lots of things and not just public newsgroup discussions. For a company >that has a lot of offices distributed around the world there could be >many applications for it. Microsoft uses it for support of their semi-public product betas. I think they also use it for internal support. R's, John From tvhawaii at shaka.com Sat Mar 31 16:18:56 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 31 Mar 2012 11:18:56 -1000 Subject: uunet ends newsfeed/newsreader in US References: <20120331203652.5282.qmail@joyce.lan> Message-ID: John Levine wrote: > Microsoft uses it for support of their semi-public product betas. I > think they also use it for internal support. > > R's, > John I just did a quick count and there are ~460 microsoft.public newsgroups. --Michael From streiner at cluebyfour.org Sat Mar 31 16:23:12 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 31 Mar 2012 17:23:12 -0400 (EDT) Subject: uunet ends newsfeed/newsreader in US In-Reply-To: <20120331203652.5282.qmail@joyce.lan> References: <20120331203652.5282.qmail@joyce.lan> Message-ID: On Sat, 31 Mar 2012, John Levine wrote: >> Seems perfectly reasonable to me. The NNTP protocol can be used for >> lots of things and not just public newsgroup discussions. For a company >> that has a lot of offices distributed around the world there could be >> many applications for it. > > Microsoft uses it for support of their semi-public product betas. I > think they also use it for internal support. We used it at work for many years for that same purpose, however all of those support functions were migrated to mailing lists over the past few years, and the news server itself was finally de-commissioned last year. jms From lowen at pari.edu Sat Mar 31 17:03:15 2012 From: lowen at pari.edu (Lamar Owen) Date: Sat, 31 Mar 2012 18:03:15 -0400 Subject: Attack on the DNS ? In-Reply-To: <20120331.222817.74728386.sthaug@nethelp.no> References: Message-ID: <201203311803.15339.lowen@pari.edu> On Saturday, March 31, 2012 04:28:17 PM sthaug at nethelp.no wrote: > ANY queries for isc.org and ripe.net are popular (ietf.org has also been > seen), since they give a potentially large amplification factor. FWIW, saw ANY queries at a rate of 10 per second from one IP to a DNS server today, all for isc.org. Saw a few hundred more for tmss.trendmicro.com from a different IP. Other popular names include plus.google.com, maps.google.com, and play.google.com. (all denied by that particular server, which is patched against such). Anyone know if there's a project to track popular amplification names? :-) From network.ipdog at gmail.com Sat Mar 31 17:48:37 2012 From: network.ipdog at gmail.com (Network IP Dog) Date: Sat, 31 Mar 2012 15:48:37 -0700 Subject: Outdoor Wireless Access Point In-Reply-To: References: Message-ID: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> Hi...How do I do it! I'm utterly amazed how many people give away free consultant work. We need to keep people working... not giving it away. Ethics... Security... etc... Does the university give away free diploma's? I don't think so. Must be another copy & paste e&^%$#?r too! Google is your friend... ;^) Cheers! Ephesians 4:32 & Cheers!!! A password is like a... toothbrush ;^) Choose a good one, change it regularly and don't share it. -----Original Message----- From: Shahab Vahabzadeh [mailto:sh.vahabzadeh at gmail.com] Sent: Saturday, March 31, 2012 2:39 AM To: nanog at nanog.org Subject: Outdoor Wireless Access Point Hi there, I asked for a wireless solution for a university, in which they want indoor wireless solution for more than 5 building (at least two floor) and outdoor wireless solution for near 160m*280m garden. As I look for maps we need at least 3 or 4 outdoor radio, I think in these networks the best solution is to have only one SSID in whole network to give mobility for the network, is this called ad-hoc? or it has an other name? I do not know if I could ask question clearly or not, suppose we have 4 radio but only one SSID is broadcasting and when you are near the radio is near to you you will get service from that one, as this solution must be implement for indoor ones too. And if there is any good company which can both indoor and outdoor solution and they have shipping to Iran too or reseller in Iran please give me the url. Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From Valdis.Kletnieks at vt.edu Sat Mar 31 18:49:08 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 31 Mar 2012 19:49:08 -0400 Subject: Outdoor Wireless Access Point In-Reply-To: Your message of "Sat, 31 Mar 2012 15:48:37 -0700." <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> References: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> Message-ID: <74945.1333237748@turing-police.cc.vt.edu> On Sat, 31 Mar 2012 15:48:37 -0700, Network IP Dog said: > I'm utterly amazed how many people give away free consultant work. A lot of us are quite busy with $DAYJOB and not in a position to take on a consulting engagement - and there's no good micropayment infrastructure to deal with 20-minute consulting gigs anyway. So we give away 5 minute chunks of our time for the benefit of the networking community. It's a large chunk of what makes 'best common practices' evolve. (Hint - that consultant you hired? How much of *their* knowledge did they aquire from other people's free advice?) And those of us who *do* go looking for consulting gigs often need to market ourselves as somebody clued. You read NANOG for a while, you get a good idea of who is clued and who isn't. And thus you decide who gets the gig. > Google is your friend... ;^) http://www.xckd.com/979/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From charles-lists at knownelement.com Sat Mar 31 19:35:05 2012 From: charles-lists at knownelement.com (Charles N Wyble) Date: Sat, 31 Mar 2012 19:35:05 -0500 Subject: ipv6 classful addressing with mesh? Message-ID: <4F77A2B9.2000801@knownelement.com> So I came across this post the other day and wanted to see what folks think about it. https://plus.google.com/u/0/109418153881180057361/posts/AvjZbbK6T7X Here is the relevant portion: *Got anything more specific than that to go on?* Actually, yes. Although I still want community feedback on how the idea can be improved. Most mesh systems have pretty arbitrary ways of handing out IP addresses, so I say, put a little logic into 'em, in a consistent way that works well for routing between networks and across the existing internet. An IPv6 address is composed of 8 chunks, each of which is 4 hex digits long. The first chunk should be something arbitrary but unclaimed - anybody know if 00fd is taken? - which is used consistently to indicate that this is a mesh-global address. The next two chunks are the longitude and latitude, respectively, in whatever precision a chunk affords across its respective scope. These first three chunks make up the network prefix that defines one network as distinct from another. How much geographical accuracy does this imply? Just enough to indicate where the "heart" of a network is, or was traditionally. A chunk can represent any number from 0-65534, because it can represent up to 65535 unique numbers and we start at 0. So, longitude can be expressed as a number of degrees "moved east" of the prime meridian from 0-360. This means the difference between each integer in a longitude chunk is 360?/65535, or .005493?. At the equator, where a degree represents the longest distance, that works out to about .4 miles [1]. For any other latitude, however, precision is better than that. Latitude, which goes from -90 to +90, can be represented as a 0-180 number where the equator is at 90, which works out to .002747? precision. So, competing networks in the same area can have slightly different network prefixes, while still each being more or less accurate (because networks are big and amorphous) while the precision isn't enough to pinpoint any individual node of the network, which I'd say is a happy medium. Longitude comes first for easier routing, since inter-network "send it east or send it west" questions seem more likely to me to come up for most switches based on the geography of the continents and the nature of the existing backbone ring of the internet. The remaining chunks can be chosen according to whatever algorithm the network administrators feel like. "Idiot devices" that aren't consciously part of the mesh will generally just put up and shut up with whatever DHCP gives them anyways, so that's not too concerning. If you decide to use client MAC address as part of it, that only leaves chunk 4 left to be set, and you can use the first four digits of the md5 hash of the MAC for that if you need something arbitrary yet deterministic. Every network can have its gateways to the corporate internet, and be accessible from the outside through them. That way, you can have inter-mesh communication over existing internet in a lightweight way: your packet routes to a gateway in your network, then across the tubes, through a gateway at the destination network, and to the ultimate destination. No packet encapsulation, no complex routing bullshit, just point A to point B. That's a simplistic overview, of course. It doesn't include shortcuts like nodes that act as part of multiple, neighboring networks, thus acting as gateways between the two. It doesn't consider IPv4 requests and service, which will probably require an AYIYA-based tunnel negotiation between the client and a gateway. But as a basic pattern, it provides consistency and efficiency between independent networks, which as far as I can see, is a vast deal more important than making one mesh to rule them all. I'm not sure what to make of it. Seems like someone trying to re establish classful addressing and not understanding routing, subnets, managed networks etc. From os10rules at gmail.com Sat Mar 31 20:09:56 2012 From: os10rules at gmail.com (Greg Ihnen) Date: Sat, 31 Mar 2012 20:39:56 -0430 Subject: Attack on the DNS ? In-Reply-To: <20120331.222817.74728386.sthaug@nethelp.no> References: <4F774C51.3000805@gmail.com> <20120331.222817.74728386.sthaug@nethelp.no> Message-ID: <1E6E6FF1-098B-4CAF-81AF-74C2D49A6A9C@gmail.com> I manage a tiny network in the Amazon, a satellite internet connection and decent sized wireless network. All of my users started complaining yesterday about lost connectivity except for Skype. I had no problems. I checked from the users' computers and could not resolve domain names (when Skype connects and nothing else does it's always been a DNS issue). After much troubleshooting I finally fired up Wireshark and saw that the DNS servers (or someone appearing to have their IP addresses) were replying to our queries with "no such name". The reason I was having no problems is I'm using OpenDNS' DNSCrypt. With DNSCrypt on we have no problems. With good old fashioned unencrypted DNS (Googles, OpenDNS', our ISPs) we're barely able to communicate. Is DNS traffic being directed to bogus servers? Are the real servers being overloaded? Am I seeing the results of some kind of DDOS mitigation technique? Is anyone else seeing this? Greg Ihnen From os10rules at gmail.com Sat Mar 31 20:23:54 2012 From: os10rules at gmail.com (Greg Ihnen) Date: Sat, 31 Mar 2012 20:53:54 -0430 Subject: Attack on the DNS ? In-Reply-To: <20120331.222817.74728386.sthaug@nethelp.no> References: <4F774C51.3000805@gmail.com> <20120331.222817.74728386.sthaug@nethelp.no> Message-ID: <0870866E-4C0D-47F1-8794-2F7900A23FBC@gmail.com> I manage a tiny network in the Amazon, a satellite internet connection and decent sized wireless network. All of my users started complaining yesterday about lost connectivity except for Skype. I had no problems. I checked from the users' computers and could not resolve domain names (when Skype connects and nothing else does it's always been a DNS issue). After much troubleshooting I finally fired up Wireshark and saw that the DNS servers (or someone appearing to have their IP addresses) were replying to our queries with "no such name". The reason I was having no problems is I'm using OpenDNS' DNSCrypt. With DNSCrypt on we have no problems. With good old fashioned unencrypted DNS (Googles, OpenDNS', our ISPs) we're barely able to communicate. Is DNS traffic being directed to bogus servers? Are the real servers being overloaded? Am I seeing the results of some kind of DDOS mitigation technique? Is anyone else seeing this? Greg Ihnen From os10rules at gmail.com Sat Mar 31 20:30:32 2012 From: os10rules at gmail.com (Greg Ihnen) Date: Sat, 31 Mar 2012 21:00:32 -0430 Subject: Attack on the DNS ? In-Reply-To: <20120331.222817.74728386.sthaug@nethelp.no> References: <4F774C51.3000805@gmail.com> <20120331.222817.74728386.sthaug@nethelp.no> Message-ID: <0BEE9226-A2DF-4963-8396-4EB1E8002C2A@gmail.com> I manage a tiny network in the Amazon, a satellite internet connection and decent sized wireless network. All of my users started complaining yesterday about lost connectivity except for Skype. I had no problems. I checked from the users' computers and could not resolve domain names (when Skype connects and nothing else does it's always been a DNS issue). After much troubleshooting I finally fired up Wireshark and saw that the DNS servers (or someone appearing to have their IP addresses) were replying to our queries with "no such name". The reason I was having no problems is I'm using OpenDNS' DNSCrypt. With DNSCrypt on we have no problems. With good old fashioned unencrypted DNS (Googles, OpenDNS', our ISPs) we're barely able to communicate. Is DNS traffic being directed to bogus servers? Are the real servers being overloaded? Am I seeing the results of some kind of DDOS mitigation technique? Is anyone else seeing this? Greg Ihnen From Valdis.Kletnieks at vt.edu Sat Mar 31 20:47:35 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 31 Mar 2012 21:47:35 -0400 Subject: ipv6 classful addressing with mesh? In-Reply-To: Your message of "Sat, 31 Mar 2012 19:35:05 -0500." <4F77A2B9.2000801@knownelement.com> References: <4F77A2B9.2000801@knownelement.com> Message-ID: <79298.1333244855@turing-police.cc.vt.edu> On Sat, 31 Mar 2012 19:35:05 -0500, Charles N Wyble said: > How much geographical accuracy does this imply? Just enough to indicate > where the "heart" of a network is, or was traditionally. A chunk can > represent any number from 0-65534, because it can represent up to 65535 > unique numbers and we start at 0. So, longitude can be expressed as a > number of degrees "moved east" of the prime meridian from 0-360. This > means the difference between each integer in a longitude chunk is > 360?/65535, or .005493?. At the equator, where a degree represents the > longest distance, that works out to about .4 miles [1]. For any other > latitude, however, precision is better than that. Latitude, which goes > from -90 to +90, can be represented as a 0-180 number where the equator > is at 90, which works out to .002747? precision. I'll bite. Is 60 Hudson 0.4 miles wide? > I'm not sure what to make of it. Seems like someone trying to re > establish classful addressing and not understanding routing, subnets, > managed networks etc. No, it's somebody trying to re-invent geographical routing and not understanding yadda yadda yadda. The traceroute from my apartment to my office, a 20 minute bike ride iin the real world: traceroute -A 192.70.187.198 traceroute to 192.70.187.198 (192.70.187.198), 30 hops max, 60 byte packets 1 192.168.2.1 (192.168.2.1) [AS8151/AS28513] 1.491 ms 1.452 ms 3.909 ms 2 71.62.120.1 (71.62.120.1) [AS21508] 18.133 ms 18.203 ms 37.221 ms 3 te-8-2-ur01.blacksburg.va.richmond.comcast.net (68.85.71.97) [AS20214] 18.002 ms 17.986 ms 17.959 ms 4 te-8-3-ar01.staunton.va.richmond.comcast.net (69.139.165.161) [AS33287] 21.101 ms 21.075 ms 21.047 ms 5 te-8-1-ar01.chesterfield.va.richmond.comcast.net (68.86.173.165) [AS21508] 29.087 ms 29.089 ms 29.029 ms 6 te-0-1-0-0-cr01.charlotte.nc.ibone.comcast.net (68.86.91.113) [AS7922] 38.882 ms 46.911 ms 46.916 ms 7 pos-3-14-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.85.213) [AS7922] 43.328 ms 45.617 ms 45.602 ms 8 nyc-e5.nyc.us.net.dtag.de (68.86.88.186) [AS7922] 45.585 ms 45.563 ms 45.540 ms 9 te4-2.ccr01.atl02.atlas.cogentco.com (154.54.10.233) [AS174] 42.049 ms 42.978 ms 42.959 ms 10 te0-0-0-1.ccr21.atl01.atlas.cogentco.com (154.54.0.165) [AS174] 41.061 ms 41.088 ms 41.097 ms 11 te0-5-0-7.ccr21.dca01.atlas.cogentco.com (154.54.42.193) [AS174] 40.750 ms te0-0-0-7.ccr21.dca01.atlas.cogentco.com (154.54.28.213) [AS174] 40.914 ms te0-0-0-3.ccr21.dca01.atlas.cogentco.com (154.54.28.201) [AS174] 40.878 ms 12 te0-1-0-5.ccr21.iad02.atlas.cogentco.com (154.54.2.50) [AS174] 40.638 ms te0-1-0-1.ccr21.iad02.atlas.cogentco.com (154.54.26.130) [AS174] 40.195 ms te0-3-0-5.ccr21.iad02.atlas.cogentco.com (154.54.41.230) [AS174] 43.299 ms 13 38.127.193.146 (38.127.193.146) [AS174] 43.281 ms 43.171 ms 43.208 ms 14 isb-7606-1.vl155.cns.vt.edu (192.70.187.148) [AS1312] 48.902 ms * * Quite the little trip - north to Staunton, south to Atlanta, north to DC, south to B'burg again, and I dunno WHAT happened at hop 8. :) Every single person who suggests geographically-based routing or addressing fails to understand that there's no cable connecting AS21508 to AS1312. And there's likely to never be one (we invited all the local providers to peer, several did accept because it lowered their upstream transit costs, Comcast apparently didn't see the added complexity as being worth the infinitesmal savings it would get them at their Cogent interconnect). So sending packets to 21508 because it's geographically "close" and hoping it will get to 1312 (or vice versa) is a fool's errand. And if you're not basing routing decisions based on the geographic address, who *cares* if the address reflects location? At that point, you're much better off basing my IP address off the fact that I'm a Comcast customer and Comcast probably knows how to get packets to me. I'll overlook the little detail that trying to use latitude and longitude as the basis for IPv6 addresses ends up wasting literally an entire Pacific's worth of address space. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From apishdadi at gmail.com Sat Mar 31 22:30:10 2012 From: apishdadi at gmail.com (Ameen Pishdadi) Date: Sat, 31 Mar 2012 22:30:10 -0500 Subject: Attack on the DNS ? In-Reply-To: <0BEE9226-A2DF-4963-8396-4EB1E8002C2A@gmail.com> References: <4F774C51.3000805@gmail.com> <20120331.222817.74728386.sthaug@nethelp.no> <0BEE9226-A2DF-4963-8396-4EB1E8002C2A@gmail.com> Message-ID: <9A386ED8-A3EF-442F-AAE7-2841582D03E0@gmail.com> Looks like your network has a user or two participating in this retarded attempt to drop the Internet. Thanks, Ameen Pishdadi On Mar 31, 2012, at 8:30 PM, Greg Ihnen wrote: > I manage a tiny network in the Amazon, a satellite internet connection and decent sized wireless network. > > All of my users started complaining yesterday about lost connectivity except for Skype. I had no problems. I checked from the users' computers and could not resolve domain names (when Skype connects and nothing else does it's always been a DNS issue). After much troubleshooting I finally fired up Wireshark and saw that the DNS servers (or someone appearing to have their IP addresses) were replying to our queries with "no such name". > > The reason I was having no problems is I'm using OpenDNS' DNSCrypt. With DNSCrypt on we have no problems. With good old fashioned unencrypted DNS (Googles, OpenDNS', our ISPs) we're barely able to communicate. > > Is DNS traffic being directed to bogus servers? Are the real servers being overloaded? Am I seeing the results of some kind of DDOS mitigation technique? > > Is anyone else seeing this? > > Greg Ihnen From hmurray at megapathdsl.net Sat Mar 31 23:11:49 2012 From: hmurray at megapathdsl.net (Hal Murray) Date: Sat, 31 Mar 2012 21:11:49 -0700 Subject: Outdoor Wireless Access Point Message-ID: <20120401041149.E2C43800037@ip-64-139-1-69.sjc.megapath.net> > Hi...How do I do it! > I'm utterly amazed how many people give away free consultant work. > We need to keep people working... not giving it away. > Ethics... Security... etc... > Does the university give away free diploma's? I don't think so. I don't expect a free diploma, but many universities are offering free internet videos of various classes. If you want a sample, here are a few good starting points: http://ocw.mit.edu/ http://oyc.yale.edu/ http://webcast.berkeley.edu/ -- These are my opinions, not necessarily my employer's. I hate spam. From nanog at studio442.com.au Sat Mar 31 23:53:51 2012 From: nanog at studio442.com.au (Julien Goodwin) Date: Sun, 01 Apr 2012 14:53:51 +1000 Subject: Outdoor Wireless Access Point In-Reply-To: <74945.1333237748@turing-police.cc.vt.edu> References: <4f7789d3.c70eb60a.1cc5.7ef6@mx.google.com> <74945.1333237748@turing-police.cc.vt.edu> Message-ID: <4F77DF5F.8070800@studio442.com.au> On 01/04/12 09:49, Valdis.Kletnieks at vt.edu wrote: > On Sat, 31 Mar 2012 15:48:37 -0700, Network IP Dog said: >> I'm utterly amazed how many people give away free consultant work. > > A lot of us are quite busy with $DAYJOB and not in a position to take on a > consulting engagement - and there's no good micropayment infrastructure to deal > with 20-minute consulting gigs anyway. So we give away 5 minute chunks of our > time for the benefit of the networking community. It's a large chunk of what > makes 'best common practices' evolve. (Hint - that consultant you hired? How > much of *their* knowledge did they aquire from other people's free advice?) Also if it's something that makes you go "huh, good question" the time spent to research it can often pay off later (several times now I've spent hours thinking over a list question, and had something similar asked of me in my day job only a few days or weeks later). From psirt at cisco.com Wed Mar 28 11:27:54 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 28 Mar 2012 18:27:54 +0200 (CEST) Subject: Cisco Security Advisory: Cisco IOS Software Command Authorization Bypass Message-ID: <201203281220068.cisco-sa-20120328-pai@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco IOS Software Command Authorization Bypass Advisory ID: cisco-sa-20120328-pai Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= A vulnerability exists in the Cisco IOS Software that may allow a remote application or device to exceed its authorization level when authentication, authorization, and accounting (AAA) authorization is used. This vulnerability requires that the HTTP or HTTPS server is enabled on the Cisco IOS device. Products that are not running Cisco IOS Software are not vulnerable. Cisco has released free software updates that address these vulnerabilities. The HTTP server may be disabled as a workaround for the vulnerability described in this advisory. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-pai Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar12.html Affected Products ================= Vulnerable Products +------------------ Any device running Cisco IOS Software release after 12.2 that has an HTTP or HTTPS server configured is affected by this vulnerability if AAA authorization is used. To determine if an HTTP or HTTP server is configured with an HTTP or HTTPS server, issue the show ip http server status | include status command. The following example illustrates a Cisco IOS device with an HTTPS server enabled and the HTTP server disabled. Router> show ip http server status | include status HTTP server status: Disabled HTTP secure server status: Enabled To determine if AAA authorization is used, an administrator can log in to the device and issue the show run | include aaa authorization command in privileged EXEC mode. If there is an entry that shows aaa authorization commands, as shown in the following example, then AAA authorization is configured. Router# show run | include aaa authorization commands aaa authorization commands 0 default local group tacacs+ aaa authorization commands 1 default group tacacs+ aaa authorization commands 15 default local To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 15.0(1)M1 with an installed image name of C3900-UNIVERSALK9-M: Router> show version Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Wed 02-Dec-09 17:17 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS and NX-OS Software Reference Guide" at: http://www.cisco.com/web/about/security/intelligence/ios-ref.html Products Confirmed Not Vulnerable +-------------------------------- If you are not running Cisco IOS or IOS XE software, you are not affected by this vulnerability. Devices that are not using AAA authorization or that do not have an HTTP or HTTPS server configured are not affected by this vulnerability. Cisco IOS XR is not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Cisco IOS allows remote applications to administer and monitor devices running Cisco IOS Software over an HTTP or HTTPS connection. A vulnerability exists that may allow the Cisco IOS command authorization to be bypassed, allowing a remote, authenticated HTTP or HTTPS session to execute any Cisco IOS command that is configured for their authorization level. This vulnerability does not allow unauthenticated access; a valid username and password are required to successfully exploit this vulnerability. Additionally, the vulnerability does not allow a user to execute commands that are not configured for their privilege level. The HTTP server is enabled by default for cluster configurations and on the following Cisco switches: Catalyst 3700 series, Catalyst 3750 series, Catalyst 3550 series, Catalyst 3560 series, and Catalyst 2950 series. More information on AAA authorization can be found at: http://www.cisco.com/en/US/docs/ios/12_2t/secure/command/reference/sftauth.html Releases of Cisco IOS Software after release 12.2 are potentially vulnerable. Please refer to the release table below for more information. This vulnerability is documented as Cisco Bug ID CSCtr91106 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2012-0384. Vulnerability Scoring Details ============================= Cisco has scored the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this security advisory is in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps organizations determine the urgency and priority of a response. Cisco has provided a base and temporal score. Customers can also compute environmental scores that help determine the impact of the vulnerability in their own networks. Cisco has provided additional information regarding CVSS at the following link: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to compute the environmental impact for individual networks at the following link: http://intellishield.cisco.com/security/alertmanager/cvss * Command Authorization Fails for commands delivered over HTTP CVSS Base Score - 8.5 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 7.0 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may allow the Cisco IOS command authorization to be bypassed, allowing a remote, authenticated HTTP or HTTPS session to execute any Cisco IOS command that is configured for its authorization level. Software Versions and Fixes =========================== When considering software upgrades, customers are advised to consult the Cisco Security Advisories and Responses archive at: http://www.cisco.com/go/psirt and review subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should ensure that the devices to be upgraded contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers. Cisco IOS Software +----------------- Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release column. The First Fixed Release for All Advisories in the March 2012 Bundled Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. The Cisco IOS Software Checker allows customers to search for Cisco Security Advisories that address specific Cisco IOS Software releases. This tool is available on the Cisco Security Intelligence Operations (SIO) portal at: http://tools.cisco.com/security/center/selectIOSVersion.x +------------------------------------------+ | Major | Availability of | | Release | Repaired Releases | |------------+-----------------------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 12.0-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------------------------------------| | There are no affected 12.0 based | | releases | |------------------------------------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 12.2-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------+--------------+--------------| | | | Vulnerable; | | 12.2 | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2B | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2BC | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2BW | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2BX | Not | First fixed | | | vulnerable | in Release | | | | 12.2SB | |------------+--------------+--------------| | | | Vulnerable; | | 12.2BY | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2BZ | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2CX | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2CY | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2CZ | Not | First fixed | | | vulnerable | in Release | | | | 12.0S | |------------+--------------+--------------| | | | Vulnerable; | | 12.2DA | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2DD | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2DX | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2EU | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | Vulnerable; | | | | contact your | | | | support | | | | organization | Vulnerable; | | | per the | contact your | | | instructions | support | | | in Obtaining | organization | | | Fixed | per the | | 12.2EW | Software | instructions | | | section of | in Obtaining | | | this | Fixed | | | advisory. | Software | | | Releases up | section of | | | to and | this | | | including | advisory. | | | 12.2(20)EWA4 | | | | are not | | | | vulnerable. | | |------------+--------------+--------------| | | Vulnerable; | | | | contact your | | | | support | | | | organization | Vulnerable; | | | per the | contact your | | | instructions | support | | | in Obtaining | organization | | | Fixed | per the | | 12.2EWA | Software | instructions | | | section of | in Obtaining | | | this | Fixed | | | advisory. | Software | | | Releases up | section of | | | to and | this | | | including | advisory. | | | 12.2(20)EWA4 | | | | are not | | | | vulnerable. | | |------------+--------------+--------------| | | Vulnerable; | | | | First fixed | | | | in Release | | | | 15.0SE | Vulnerable; | | 12.2EX | Releases up | First fixed | | | to and | in Release | | | including | 15.0SE | | | 12.2(25)EX1 | | | | are not | | | | vulnerable. | | |------------+--------------+--------------| | 12.2EY | 12.2(52)EY4 | 12.2(52)EY4 | | | 12.2(58)EY2 | | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2EZ | First fixed | First fixed | | | in Release | in Release | | | 15.0SE | 15.0SE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2FX | First fixed | First fixed | | | in Release | in Release | | | 12.2SE | 15.0SE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2FY | First fixed | First fixed | | | in Release | in Release | | | 15.0SE | 15.0SE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2FZ | First fixed | First fixed | | | in Release | in Release | | | 12.2SE | 15.0SE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2IRA | First fixed | First fixed | | | in Release | in Release | | | 12.2SRD | 12.2SRE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2IRB | First fixed | First fixed | | | in Release | in Release | | | 12.2SRD | 12.2SRE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2IRC | First fixed | First fixed | | | in Release | in Release | | | 12.2SRD | 12.2SRE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2IRD | First fixed | First fixed | | | in Release | in Release | | | 12.2SRD | 12.2SRE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2IRE | First fixed | First fixed | | | in Release | in Release | | | 12.2SRD | 12.2SRE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2IRF | First fixed | First fixed | | | in Release | in Release | | | 12.2SRD | 12.2SRE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.2IRG | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2IRH | 12.2(33)IRH1 | instructions | | | | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2IXA | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2IXB | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2IXC | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2IXD | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2IXE | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2IXF | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2IXG | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2IXH | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | 12.2JA | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | 12.2JK | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | | | Vulnerable; | | 12.2MB | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2MC | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2MRA | First fixed | First fixed | | | in Release | in Release | | | 12.2SRD | 12.2SRE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.2MRB | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | | Releases | | | | prior to | | | | 12.2(30)S | | | | are | | | | vulnerable; | | | Not | Releases | | 12.2S | vulnerable | 12.2(30)S | | | | and later | | | | are not | | | | vulnerable. | | | | First fixed | | | | in Release | | | | 12.0S | |------------+--------------+--------------| | 12.2SB | 12.2(33)SB12 | 12.2(33)SB12 | |------------+--------------+--------------| | | | Vulnerable; | | 12.2SBC | Not | First fixed | | | vulnerable | in Release | | | | 12.2SRE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SCA | First fixed | First fixed | | | in Release | in Release | | | 12.2SCE | 12.2SCE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SCB | First fixed | First fixed | | | in Release | in Release | | | 12.2SCE | 12.2SCE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SCC | First fixed | First fixed | | | in Release | in Release | | | 12.2SCE | 12.2SCE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SCD | First fixed | First fixed | | | in Release | in Release | | | 12.2SCE | 12.2SCE | |------------+--------------+--------------| | 12.2SCE | 12.2(33)SCE5 | 12.2(33)SCE6 | |------------+--------------+--------------| | 12.2SCF | 12.2(33)SCF2 | 12.2(33)SCF2 | |------------+--------------+--------------| | | | | | 12.2SE | 12.2(55)SE5 | 12.2(55)SE5 | | | | * | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SEA | First fixed | First fixed | | | in Release | in Release | | | 12.2SE | 15.0SE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SEB | First fixed | First fixed | | | in Release | in Release | | | 12.2SE | 15.0SE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SEC | First fixed | First fixed | | | in Release | in Release | | | 12.2SE | 15.0SE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SED | First fixed | First fixed | | | in Release | in Release | | | 12.2SE | 15.0SE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SEE | First fixed | First fixed | | | in Release | in Release | | | 12.2SE | 15.0SE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SEF | First fixed | First fixed | | | in Release | in Release | | | 12.2SE | 15.0SE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SEG | First fixed | First fixed | | | in Release | in Release | | | 15.0SE | 15.0SE | |------------+--------------+--------------| | | 12.2(53)SG7; | 12.2(53)SG7; | | 12.2SG | Available on | Available on | | | 07-MAY-12 | 07-MAY-12 | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | Vulnerable; | per the | | 12.2SGA | First fixed | instructions | | | in Release | in Obtaining | | | 12.2SG | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | 12.2SL | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SM | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SO | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.2SQ | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SRA | First fixed | First fixed | | | in Release | in Release | | | 12.2SRD | 12.2SRE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SRB | First fixed | First fixed | | | in Release | in Release | | | 12.2SRD | 12.2SRE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2SRC | First fixed | First fixed | | | in Release | in Release | | | 12.2SRD | 12.2SRE | |------------+--------------+--------------| | | | Vulnerable; | | 12.2SRD | 12.2(33)SRD8 | First fixed | | | | in Release | | | | 12.2SRE | |------------+--------------+--------------| | 12.2SRE | 12.2(33)SRE6 | 12.2(33)SRE6 | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.2STE | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | 12.2SU | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Releases up | | | | to and | | 12.2SV | Not | including | | | vulnerable | 12.2(18)SV2 | | | | are not | | | | vulnerable. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SVA | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SVC | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SVD | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SVE | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | 12.2SW | Not | First fixed | | | vulnerable | in Release | | | | 12.4T | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SX | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SXA | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SXB | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SXD | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SXE | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2SXF | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.2SXH | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | 12.2SXI | 12.2(33)SXI9 | 12.2(33)SXI9 | |------------+--------------+--------------| | 12.2SXJ | 12.2(33)SXJ2 | 12.2(33)SXJ2 | |------------+--------------+--------------| | | 12.2(50)SY2; | | | | Available on | | | | 11-JUN-12 | | | | Releases up | 12.2(50)SY2; | | 12.2SY | to and | Available on | | | including | 11-JUN-12 | | | 12.2(14)SY5 | | | | are not | | | | vulnerable. | | |------------+--------------+--------------| | | | Vulnerable; | | 12.2SZ | Not | First fixed | | | vulnerable | in Release | | | | 12.0S | |------------+--------------+--------------| | | | Vulnerable; | | 12.2T | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2TPC | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XA | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XB | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XC | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XD | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XE | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XF | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XG | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XH | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XI | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XJ | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XK | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XL | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XM | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | Please see | Please see | | 12.2XNA | Cisco IOS-XE | Cisco IOS-XE | | | Software | Software | | | Availability | Availability | |------------+--------------+--------------| | | Please see | Please see | | 12.2XNB | Cisco IOS-XE | Cisco IOS-XE | | | Software | Software | | | Availability | Availability | |------------+--------------+--------------| | | Please see | Please see | | 12.2XNC | Cisco IOS-XE | Cisco IOS-XE | | | Software | Software | | | Availability | Availability | |------------+--------------+--------------| | | Please see | Please see | | 12.2XND | Cisco IOS-XE | Cisco IOS-XE | | | Software | Software | | | Availability | Availability | |------------+--------------+--------------| | | Please see | Please see | | 12.2XNE | Cisco IOS-XE | Cisco IOS-XE | | | Software | Software | | | Availability | Availability | |------------+--------------+--------------| | | Please see | Please see | | 12.2XNF | Cisco IOS-XE | Cisco IOS-XE | | | Software | Software | | | Availability | Availability | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | Vulnerable; | per the | | 12.2XO | First fixed | instructions | | | in Release | in Obtaining | | | 12.2SG | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XQ | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Releases | | | | prior to | | | | 12.2(15)XR | | | | are | | | | vulnerable; | | | Not | Releases | | 12.2XR | vulnerable | 12.2(15)XR | | | | and later | | | | are not | | | | vulnerable. | | | | First fixed | | | | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XS | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XT | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XU | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XV | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2XW | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.2YA | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2YC | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2YD | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2YE | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2YK | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2YO | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | First fixed | | | | in Release | | | | 15.0M | | 12.2YP | Not | Releases up | | | vulnerable | to and | | | | including | | | | 12.2(8)YP | | | | are not | | | | vulnerable. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2YT | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2YW | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2YX | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2YY | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2YZ | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2ZA | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2ZB | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2ZC | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2ZD | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | 12.2ZE | Not | First fixed | | | vulnerable | in Release | | | | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.2ZH | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2ZJ | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2ZP | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2ZU | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | 12.2ZX | Not | First fixed | | | vulnerable | in Release | | | | 12.2SRE | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2ZY | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 12.2ZYA | Not | instructions | | | vulnerable | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 12.3-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3 | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3B | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3BC | First fixed | First fixed | | | in Release | in Release | | | 12.2SCE | 12.2SCE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3BW | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3JA | First fixed | First fixed | | | in Release | in Release | | | 12.4JA | 12.4JA | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.3JEA | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.3JEB | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.3JEC | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.3JED | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3JK | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.3JL | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | 12.3JX | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3T | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.3TPC | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | 12.3VA | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XA | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.3XB | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XC | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XD | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XE | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.3XF | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XG | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XI | First fixed | First fixed | | | in Release | in Release | | | 12.2SB | 12.2SRE | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XJ | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XK | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XL | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XQ | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XR | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XU | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 12.4T | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XW | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XX | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XY | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3XZ | First fixed | First fixed | | | in Release | in Release | | | 12.4 | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YD | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YF | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YG | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YI | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YJ | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YK | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YM | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YQ | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YS | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YT | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YU | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3YX | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.3YZ | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.3ZA | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 12.4-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------+--------------+--------------| | | 12.4(25g); | Vulnerable; | | 12.4 | Available on | First fixed | | | 19-SEP-12 | in Release | | | | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4GC | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | 12.4(23c)JA4 | | | | 12.4(25d) | 12.4(23c) | | 12.4JA | JA2; | JA412.4(25e) | | | Available on | JA | | | 01-AUG-12 | | | | 12.4(25e)JA | | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4JAX | First fixed | First fixed | | | in Release | in Release | | | 12.4JA | 12.4JA | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4JDA | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4JDC | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4JDD | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4JDE | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4JHA | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4JHB | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4JHC | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4JK | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4JL | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4JX | First fixed | First fixed | | | in Release | in Release | | | 12.4JA | 12.4JA | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4JY | First fixed | First fixed | | | in Release | in Release | | | 12.4JA | 12.4JA | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4JZ | First fixed | First fixed | | | in Release | in Release | | | 12.4JA | 12.4JA | |------------+--------------+--------------| | | 12.4(22)MD3; | 12.4(22)MD3; | | 12.4MD | Available on | Available on | | | 30-MAR-12 | 30-MAR-12 | |------------+--------------+--------------| | 12.4MDA | 12.4(24) | 12.4(24) | | | MDA11 | MDA11 | |------------+--------------+--------------| | 12.4MDB | 12.4(24) | 12.4(24) | | | MDB5a | MDB5a | |------------+--------------+--------------| | 12.4MDC | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4MR | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4MRA | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4MRB | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | | Vulnerable; | | 12.4SW | 12.4(15)SW8a | First fixed | | | | in Release | | | | 15.0M | |------------+--------------+--------------| | | 12.4(15)T17 | 12.4(15)T17 | | 12.4T | 12.4(24)T7 | 12.4(24)T7 | | | | | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XA | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XB | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 12.4T | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XC | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XD | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XE | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XF | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XG | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XJ | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XK | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4XL | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XM | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4XN | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4XP | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XQ | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XR | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 12.4T | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XT | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4XV | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XW | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XY | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4XZ | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 12.4YA | First fixed | First fixed | | | in Release | in Release | | | 12.4T | 15.0M | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4YB | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 12.4YD | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | 12.4YE | 12.4(24)YE3d | 12.4(24)YE3d | |------------+--------------+--------------| | 12.4YG | 12.4(24)YG4 | 12.4(24)YG4 | |------------+--------------+--------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 15.0-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------+--------------+--------------| | 15.0M | 15.0(1)M8 | 15.0(1)M8 | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 15.0MR | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 15.0MRA | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | | 15.0(1)S5 | 15.0(1)S5 | | | Cisco IOS XE | Cisco IOS XE | | | devices: | devices: | | 15.0S | Please see | Please see | | | Cisco IOS XE | Cisco IOS XE | | | Software | Software | | | Availability | Availability | |------------+--------------+--------------| | 15.0SA | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | | 15.0(1)SE1 | | | 15.0SE | 15.0(2)SE; | 15.0(1)SE1 | | | Available on | | | | 06-AUG-12 | | |------------+--------------+--------------| | | 15.0(2)SG2 | 15.0(2)SG2 | | | Cisco IOS XE | Cisco IOS XE | | | devices: | devices: | | 15.0SG | Please see | Please see | | | Cisco IOS XE | Cisco IOS XE | | | Software | Software | | | Availability | Availability | |------------+--------------+--------------| | 15.0SY | 15.0(1)SY1 | 15.0(1)SY1 | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 15.0XA | First fixed | First fixed | | | in Release | in Release | | | 15.1T | 15.1T | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | First fixed | First fixed | | | in Release | in Release | | | 15.0SG Cisco | 15.0SG Cisco | | 15.0XO | IOS XE | IOS XE | | | devices: | devices: | | | Please see | Please see | | | Cisco IOS XE | Cisco IOS XE | | | Software | Software | | | Availability | Availability | |------------+--------------+--------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 15.1-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------+--------------+--------------| | 15.1EY | 15.1(2)EY1a | 15.1(2)EY2 | |------------+--------------+--------------| | 15.1GC | 15.1(2)GC2 | 15.1(2)GC2 | |------------+--------------+--------------| | | 15.1(4)M2 | 15.1(4)M4; | | 15.1M | | Available on | | | | 30-MAR-12 | |------------+--------------+--------------| | | | Vulnerable; | | | | contact your | | | | support | | | | organization | | | | per the | | 15.1MR | 15.1(1)MR3 | instructions | | | | in Obtaining | | | | Fixed | | | | Software | | | | section of | | | | this | | | | advisory. | |------------+--------------+--------------| | | 15.1(3)S2 | 15.1(3)S2 | | | Cisco IOS XE | Cisco IOS XE | | | devices: | devices: | | 15.1S | Please see | Please see | | | Cisco IOS XE | Cisco IOS XE | | | Software | Software | | | Availability | Availability | |------------+--------------+--------------| | 15.1SG | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | | contact your | contact your | | | support | support | | | organization | organization | | | per the | per the | | 15.1SNG | instructions | instructions | | | in Obtaining | in Obtaining | | | Fixed | Fixed | | | Software | Software | | | section of | section of | | | this | this | | | advisory. | advisory. | |------------+--------------+--------------| | 15.1SNH | Not | Not | | | vulnerable | vulnerable | |------------+--------------+--------------| | | 15.1(1)T4 | | | | 15.1(2)T5; | | | 15.1T | Available on | 15.1(3)T3 | | | 27-APR-12 | | | | 15.1(3)T3 | | |------------+--------------+--------------| | | Vulnerable; | Vulnerable; | | 15.1XB | First fixed | First fixed | | | in Release | in Release | | | 15.1T | 15.1T | |------------+--------------+--------------| | | | First Fixed | | | | Release for | | | | All | | | | Advisories | | Affected | First Fixed | in the March | | 15.2-Based | Release | 2012 Cisco | | Releases | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |------------+--------------+--------------| | 15.2GC | 15.2(1)GC1 | 15.2(1)GC2 | |------------+--------------+--------------| | | 15.2(1)S1 | 15.2(1)S1 | | | Cisco IOS XE | Cisco IOS XE | | | devices: | devices: | | 15.2S | Please see | Please see | | | Cisco IOS XE | Cisco IOS XE | | | Software | Software | | | Availability | Availability | |------------+--------------+--------------| | | | 15.2(1) | | | 15.2(1)T1 | T215.2(2) | | 15.2T | 15.2(2)T | T115.2(3)T; | | | 15.2(2)T1 | Available on | | | | 30-MAR-12 | +------------------------------------------+ * Cisco Catalyst 3550 Series Switches support the Internet Key Exchange (IKE) feature and are vulnerable to Cisco bug ID CSCts38429 when the devices are running Layer 3 images; however, this product reached the End of Software Maintenance milestone. Cisco 3550 Series SMI Switches that are running Layer 2 images do not support IKE and are not vulnerable. No other Cisco devices that run 12.2SE-based software are vulnerable. Cisco IOS XE Software +-------------------- Cisco IOS XE Software is affected by the vulnerability that is disclosed in this document. +---------------------------------------+ | | | First Fixed | | | | Release for | | | | All | | Cisco | | Advisories | | IOS XE | First Fixed | in the March | | Software | Release | 2012 Cisco | | Release | | IOS Software | | | | Security | | | | Advisory | | | | Bundled | | | | Publication | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 2.1.x | migrate to | migrate to | | | 3.1.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 2.2.x | migrate to | migrate to | | | 3.1.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 2.3.x | migrate to | migrate to | | | 3.1.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 2.4.x | migrate to | migrate to | | | 3.1.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 2.5.x | migrate to | migrate to | | | 3.1.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 2.6.x | migrate to | migrate to | | | 3.1.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | | | Vulnerable; | | 3.1.xS | 3.1.2S | migrate to | | | | 3.4.2S or | | | | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 3.1.xSG | migrate to | migrate to | | | 3.2.2SG or | 3.2.2SG or | | | later. | later. | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 3.2.xS | migrate to | migrate to | | | 3.4.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | 3.2.xSG | 3.2.2SG | 3.2.2SG | |----------+-------------+--------------| | | Vulnerable; | Vulnerable; | | 3.3.xS | migrate to | migrate to | | | 3.4.2S or | 3.4.2S or | | | later. | later. | |----------+-------------+--------------| | 3.2.xSG | Not | Not | | | vulnerable | vulnerable | |----------+-------------+--------------| | 3.4.xS | 3.4.2S | 3.4.2S | |----------+-------------+--------------| | 3.5.xS | 3.5.1S | 3.5.1S | |----------+-------------+--------------| | 3.6.xS | Not | Not | | | vulnerable | vulnerable | +---------------------------------------+ For a mapping of Cisco IOS XE Software releases to Cisco IOS Software releases, refer to Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and Cisco IOS XE 3SG Release Notes. Cisco IOS XR Software +-------------------- Cisco IOS XR Software is not affected by any of the vulnerabilities disclosed in the March 2012 Cisco IOS Software Security Advisory Bundled Publication. Workarounds =========== If the HTTP and HTTPS servers are not required, they may be disabled with the commands no ip http server and no ip http secure-server. However, if web services are required, a feature was introduced in 12.3(14)T and later in which selective HTTP and HTTPS services could be enabled or disabled. The WEB_EXEC service provides a facility to configure the device and retrieve the current state of the device from remote clients. It is possible to disable the WEB_EXEC service while still leaving other HTTP services active. If an installation does not require the use of the WEB_EXEC service, then it may be disabled using the following procedure: 1. Verify the list of all session modules. Router# show ip http server session-module HTTP server application session modules: Session module Name Handle Status Secure-status Description HTTP_IFS 1 Active Active HTTP based IOS File Server HOME_PAGE 2 Active Active IOS Homepage Server QDM 3 Active Active QOS Device Manager Server QDM_SA 4 Active Active QOS Device Manager Signed Applet Server WEB_EXEC 5 Active Active HTTP based IOS EXEC Server IXI 6 Active Active IOS XML Infra Application Server IDCONF 7 Active Active IDCONF HTTP(S) Server XSM 8 Active Active XML Session Manager VDM 9 Active Active VPN Device Manager Server XML_Api 10 Active Active XML Api ITS 11 Active Active IOS Telephony Service ITS_LOCDIR 12 Active Active ITS Local Directory Search CME_SERVICE_URL 13 Active Active CME Service URL CME_AUTH_SRV_LOGIN 14 Active Active CME Authentication Server IPS_SDEE 15 Active Active IOS IPS SDEE Server tti-petitioner 16 Active Active TTI Petitioner 2. Create a list of session modules that are required, in this example it would be everything other than WEB_EXEC. Router# configuration terminal Router(config)# ip http session-module-list exclude_webexec HTTP_IFS,HOME_PAGE,QDM,QDM_SA,IXI,IDCONF,XSM,VDM,XML_Api, ITS,ITS_LOCDIR,CME_SERVICE_URL,CME_AUTH_SRV_LOGIN,IPS_SDEE,tti-petitioner 3. Selectively enable HTTP/HTTPS applications that will service incoming HTTP requests from remote clients. Router(config)# ip http active-session-modules exclude_webexec Router(config)# ip http secure-active-session-modules exclude_webexec Router(config)# exit 4. Verify the list of all session modules, and ensure WEB_EXEC is not active. Router# show ip http server session-module HTTP server application session modules: Session module Name Handle Status Secure-status Description HTTP_IFS 1 Active Active HTTP based IOS File Server HOME_PAGE 2 Active Active IOS Homepage Server QDM 3 Active Active QOS Device Manager Server QDM_SA 4 Active Active QOS Device Manager Signed Applet Server WEB_EXEC 5 Inactive Inactive HTTP based IOS EXEC Server IXI 6 Active Active IOS XML Infra Application Server IDCONF 7 Active Active IDCONF HTTP(S) Server XSM 8 Active Active XML Session Manager VDM 9 Active Active VPN Device Manager Server XML_Api 10 Active Active XML Api ITS 11 Active Active IOS Telephony Service ITS_LOCDIR 12 Active Active ITS Local Directory Search CME_SERVICE_URL 13 Active Active CME Service URL CME_AUTH_SRV_LOGIN 14 Active Active CME Authentication Server IPS_SDEE 15 Active Active IOS IPS SDEE Server tti-petitioner 16 Active Active TTI Petitioner For further information on the selective enabling of applications using an HTTP or secure HTTP server, consult the Cisco IOS network management configuration guide, release 12.4T, at: http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_http_app_enable.html If the HTTP server and WEB_EXEC service are required, it is a recommended best practice to limit which hosts may access the HTTP server to allow only trusted sources. An access list can be applied to the HTTP server to limit which hosts are permitted access. To apply an access list to the HTTP server, use the following command in global configuration mode: ip http access-class {access-list-number | access-list-name}. The following example shows an access list that allows only trusted hosts to access the Cisco IOS HTTP server: ip access-list standard 20 permit 192.168.1.0 0.0.0.255 remark "Above is a trusted subnet" remark "Add further trusted subnets or hosts below" ! (Note: all other access implicitly denied) ! (Apply the access-list to the http server) ip http access-class 20 For additional information on configuring the Cisco IOS HTTP server, consult Using the Cisco Web Browser User Interface. Obtaining Fixed Software ======================== Cisco has released free software updates that addresses the vulnerability described in this advisory. Prior to deploying software, customers are advised to consult their maintenance providers or check the software for feature set compatibility and known issues that are specific to their environments. Customers may only install and expect support for feature sets they have purchased. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as set forth at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, upgrades should be obtained through the Software Center on Cisco.com at: http://www.cisco.com Customers Using Third-Party Support Organizations +------------------------------------------------ Customers with Cisco products that are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers, should contact that organization for assistance with the appropriate course of action. The effectiveness of any workaround or fix depends on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Because of the variety of affected products and releases, customers should consult their service providers or support organizations to ensure that any applied workaround or fix is the most appropriate in the intended network before it is deployed Customers Without Service Contracts +---------------------------------- Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC): * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade. Customers without service contracts should request free upgrades through the TAC. Refer to Cisco Worldwide Contacts at: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, instructions, and e-mail addresses for support in various languages. Exploitation and Public Announcements ===================================== The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory. This vulnerability was reported to Cisco TAC by customers observing the vulnerability during the normal operation of their devices. Status of This Notice: Final THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco Security Intelligence Operations at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-pai Additionally, a text version of this advisory is clear signed with the Cisco PSIRT PGP key and circulated among the following e-mail addresses: * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk Future updates of this advisory, if any, will reside on Cisco.com but may not be announced on mailing lists. Users can monitor this advisory's URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2012-March-28 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information about reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco is available on Cisco.com at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This web page includes instructions for press inquiries regarding Cisco Security Advisories. All Cisco Security Advisories are available at: http://www.cisco.com/go/psirt +-------------------------------------------------------------------- Copyright 2010-2012 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (SunOS) iFcDBQFPcfB+QXnnBKKRMNARCG0KAP98319EAgChMCfxp4K0GXiscRX+fBEv/3NF +CJDx7WA5gD+IcSwDBmEjesJmNj3GyxbjQ9f1WX7jFpUvy81HYDOqko= =vGZr -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 28 11:20:57 2012 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 28 Mar 2012 12:20:57 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Multicast Source Discovery Protocol Vulnerability Message-ID: <201203281220068.cisco-sa-20120328-msdp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco IOS Software Multicast Source Discovery Protocol Vulnerability Advisory ID: cisco-sa-20120328-msdp Revision 1.0 For Public Release 2012 March 28 16:00 UTC (GMT) +-------------------------------------------------------------------- Summary ======= A vulnerability in the Multicast Source Discovery Protocol (MSDP) implementation of Cisco IOS Software and Cisco IOS XE Software could allow a remote, unauthenticated attacker to cause a reload of an affected device. Repeated attempts to exploit this vulnerability could result in a sustained denial of service (DoS) condition. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-msdp Note: The March 28, 2012, Cisco IOS Software Security Advisory bundled publication includes nine Cisco Security Advisories. Each advisory lists the Cisco IOS Software releases that correct the vulnerability or vulnerabilities detailed in the advisory as well as the Cisco IOS Software releases that correct all vulnerabilities in the March 2012 bundled publication. Individual publication links are in "Cisco Event Response: Semi-Annual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar12.html Affected Products ================= Vulnerable Products +------------------ The following products are affected by this vulnerability: + Cisco IOS Software + Cisco IOS XE Software To determine whether a Cisco IOS or Cisco IOS XE Software release is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(20)T with an installed image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team Additional information about Cisco IOS Software release naming conventions is available in the White Paper: Cisco IOS and NX-OS Software Reference Guide Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS XR Software is not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= MSDP is the protocol used to connect multiple Protocol Independent Multicast sparse mode (PIM-SM) domains. MSDP allows multicast sources for a group to be known to all rendezvous points (RPs) in different domains. An RP runs MSDP over TCP to discover multicast sources. An RP in a PIM-SM domain has an MSDP peering relationship with MSDP-enabled routers in another domain. The peering relationship occurs over a TCP connection, where primarily a list of sources sending to multicast groups is exchanged. The TCP connections between RPs are achieved by the underlying routing system. The receiving RP uses the source lists to establish a source path. The purpose of this topology is to have domains discover multicast sources in other domains. If the multicast sources are of interest to a domain that has receivers, multicast data is delivered over the normal, source-tree building mechanism in PIM-SM. An MSDP packet containing encapsulated Internet Group Management Protocol (IGMP) data, received from an external MSDP-configured peer router, can cause an affected device to reload. This vulnerability can only be exploited if the router is explicitly joined to the multicast group. The MSDP packet destination address is a unicast address and can be addressed to any IP address on the affected device, including loopback addresses. Transit traffic will not trigger this vulnerability. A vulnerable interface configuration contains an explicitly joined multicast group. Some example configurations that permit exploitation of this vulnerability are: !--- Interface configured for SAP Listener Support (a common multicast group) interface GigabitEthernet0/0 ip address 192.168.0.1 255.255.255.0 ip pim sparse-mode ip sap listen !--- Interface configured to join a multicast group interface GigabitEthernet0/0 ip address 192.168.0.1 255.255.255.0 ip pim sparse-mode ip igmp join-group 224.2.127.254 You can also use the "show igmp interface" command to determine if an interface is joined to a multicast group. RouterA#show ip igmp interface GigabitEthernet0/0 is up, line protocol is up Internet address is 192.168.0.1/24 IGMP is enabled on interface Current IGMP host version is 2 Current IGMP router version is 2 IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query count is 2 Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 2 joins, 0 leaves Multicast routing is disabled on interface Multicast TTL threshold is 0 Multicast groups joined by this system (number of users): 224.2.127.254(2) 239.255.255.255(1) This vulnerability is documented in Cisco bug ID CSCtr28857. This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2012-0382. Vulnerability Scoring Details ============================= Cisco has scored the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this security advisory is in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps organizations determine the urgency and priority of a response. Cisco has provided a base and temporal score. Customers can also compute environmental scores that help determine the impact of the vulnerability in their own networks. Cisco has provided additional information regarding CVSS at the following link: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to compute the environmental impact for individual networks at the following link: http://intellishield.cisco.com/security/alertmanager/cvss * CSCtr28857 ("MSDP-peered Router joined to a multicast group may crash") CVSS Base Score - 7.1 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Workaround Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability may cause the affected device to reload. Repeated exploitation may result in a sustained DoS condition. Software Versions and Fixes =========================== When considering software upgrades, customers are advised to consult the Cisco Security Advisories and Responses archive at http://www.cisco.com/go/psirt and review subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should ensure that the devices to be upgraded contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers. Cisco IOS Software +----------------- Each row of the following Cisco IOS Software table corresponds to a Cisco IOS Software train. If a particular train is vulnerable, the earliest releases that contain the fix are listed in the First Fixed Release column. The First Fixed Release for All Advisories in the March 2012 Bundled Publication column lists the earliest possible releases that correct all the published vulnerabilities in the Cisco IOS Software Security Advisory bundled publication. Cisco recommends upgrading to the latest available release, where possible. The Cisco IOS Software Checker allows customers to search for Cisco Security Advisories that address specific Cisco IOS Software releases. This tool is available on the Cisco Security Intelligence Operations (SIO) portal at: http://tools.cisco.com/security/center/selectIOSVersion.x +------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+-----------------------------------------------| | | | First Fixed Release | | Affected | | for All Advisories in | | 12.0-Based | First Fixed Release | the March 2012 Cisco | | Releases | | IOS Software Security | | | | Advisory Bundled | | | | Publication | |------------+-----------------------+-----------------------| | 12.0S | 12.0(33)S10 | 12.0(33)S10 | |------------+-----------------------+-----------------------| | 12.0SY | 12.0(32)SY15 | 12.0(32)SY15 | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.0SZ | fixed in Release | fixed in Release | | | 12.0S | 12.0S | |------------+-----------------------+-----------------------| | | | First Fixed Release | | Affected | | for All Advisories in | | 12.2-Based | First Fixed Release | the March 2012 Cisco | | Releases | | IOS Software Security | | | | Advisory Bundled | | | | Publication | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2 | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2B | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2BC | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2BW | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2BX | fixed in Release | fixed in Release | | | 12.2SB | 12.2SB | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2BY | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2BZ | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2CX | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2CY | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2CZ | fixed in Release | fixed in Release | | | 12.0S | 12.0S | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2DA | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2DD | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2DX | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2EU | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2EW | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2EWA | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2EX | fixed in Release | fixed in Release | | | 15.0SE | 15.0SE | |------------+-----------------------+-----------------------| | 12.2EY | 12.2(52)EY4 | 12.2(52)EY4 | | | 12.2(58)EY2 | | |------------+-----------------------+-----------------------| | | Releases prior to | | | | 12.2(53)EZ are | | | | vulnerable; Releases | Vulnerable; First | | 12.2EZ | 12.2(53)EZ and later | fixed in Release | | | are not vulnerable. | 15.0SE | | | First fixed in | | | | Release 15.0SE | | |------------+-----------------------+-----------------------| | | | Vulnerable; First | | 12.2FX | Not vulnerable | fixed in Release | | | | 15.0SE | |------------+-----------------------+-----------------------| | | | Vulnerable; First | | 12.2FY | Not vulnerable | fixed in Release | | | | 15.0SE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2FZ | fixed in Release | fixed in Release | | | 12.2SE | 15.0SE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2IRA | fixed in Release | fixed in Release | | | 12.2SRE | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2IRB | fixed in Release | fixed in Release | | | 12.2SRE | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2IRC | fixed in Release | fixed in Release | | | 12.2SRE | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2IRD | fixed in Release | fixed in Release | | | 12.2SRE | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2IRE | fixed in Release | fixed in Release | | | 12.2SRE | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2IRF | fixed in Release | fixed in Release | | | 12.2SRE | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2IRG | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.2IRH | 12.2(33)IRH1 | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2IXA | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2IXB | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2IXC | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2IXD | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2IXE | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2IXF | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2IXG | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2IXH | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | 12.2JA | Not vulnerable | Not vulnerable | |------------+-----------------------+-----------------------| | 12.2JK | Not vulnerable | Not vulnerable | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2MB | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2MC | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2MRA | fixed in Release | fixed in Release | | | 12.2SRE | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2MRB | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Releases prior to | Releases prior to | | | 12.2(30)S are | 12.2(30)S are | | | vulnerable; Releases | vulnerable; Releases | | 12.2S | 12.2(30)S and later | 12.2(30)S and later | | | are not vulnerable. | are not vulnerable. | | | First fixed in | First fixed in | | | Release 12.0S | Release 12.0S | |------------+-----------------------+-----------------------| | 12.2SB | 12.2(33)SB12 | 12.2(33)SB12 | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SBC | fixed in Release | fixed in Release | | | 12.2SB | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SCA | fixed in Release | fixed in Release | | | 12.2SCE | 12.2SCE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SCB | fixed in Release | fixed in Release | | | 12.2SCE | 12.2SCE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SCC | fixed in Release | fixed in Release | | | 12.2SCE | 12.2SCE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SCD | fixed in Release | fixed in Release | | | 12.2SCE | 12.2SCE | |------------+-----------------------+-----------------------| | 12.2SCE | 12.2(33)SCE5 | 12.2(33)SCE6 | |------------+-----------------------+-----------------------| | 12.2SCF | 12.2(33)SCF2 | 12.2(33)SCF2 | |------------+-----------------------+-----------------------| | 12.2SE | 12.2(55)SE5 | | | | | 12.2(55)SE5 * | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SEA | fixed in Release | fixed in Release | | | 12.2SE | 15.0SE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SEB | fixed in Release | fixed in Release | | | 12.2SE | 15.0SE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SEC | fixed in Release | fixed in Release | | | 12.2SE | 15.0SE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SED | fixed in Release | fixed in Release | | | 12.2SE | 15.0SE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SEE | fixed in Release | fixed in Release | | | 12.2SE | 15.0SE | |------------+-----------------------+-----------------------| | | | Vulnerable; First | | 12.2SEF | Not vulnerable | fixed in Release | | | | 15.0SE | |------------+-----------------------+-----------------------| | | Releases prior to | | | | 12.2(25)SEG4 are | | | | vulnerable; Releases | Vulnerable; First | | 12.2SEG | 12.2(25)SEG4 and | fixed in Release | | | later are not | 15.0SE | | | vulnerable. First | | | | fixed in Release | | | | 15.0SE | | |------------+-----------------------+-----------------------| | | 12.2(53)SG7; | 12.2(53)SG7; | | 12.2SG | Available on | Available on | | | 07-MAY-12 | 07-MAY-12 | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SGA | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | 12.2SL | Not vulnerable | Not vulnerable | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SM | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SO | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SQ | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SRA | fixed in Release | fixed in Release | | | 12.2SRE | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SRB | fixed in Release | fixed in Release | | | 12.2SRE | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SRC | fixed in Release | fixed in Release | | | 12.2SRE | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SRD | fixed in Release | fixed in Release | | | 12.2SRE | 12.2SRE | |------------+-----------------------+-----------------------| | 12.2SRE | 12.2(33)SRE5 | 12.2(33)SRE6 | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.2STE | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SU | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Releases up to and | Releases up to and | | 12.2SV | including 12.2(18)SV2 | including 12.2(18)SV2 | | | are not vulnerable. | are not vulnerable. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SVA | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SVC | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SVD | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SVE | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SW | fixed in Release | fixed in Release | | | 12.4SW | 12.4T | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SX | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SXA | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SXB | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SXD | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SXE | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SXF | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2SXH | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | 12.2SXI | 12.2(33)SXI9 | 12.2(33)SXI9 | |------------+-----------------------+-----------------------| | 12.2SXJ | 12.2(33)SXJ2 | 12.2(33)SXJ2 | |------------+-----------------------+-----------------------| | | 12.2(50)SY2; | 12.2(50)SY2; | | 12.2SY | Available on | Available on | | | 11-JUN-12 | 11-JUN-12 | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2SZ | fixed in Release | fixed in Release | | | 12.0S | 12.0S | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2T | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2TPC | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XA | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XB | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XC | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XD | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XE | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XF | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XG | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XH | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XI | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XJ | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XK | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XL | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XM | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Please see Cisco | Please see Cisco | | 12.2XNA | IOS-XE Software | IOS-XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | | Please see Cisco | Please see Cisco | | 12.2XNB | IOS-XE Software | IOS-XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | | Please see Cisco | Please see Cisco | | 12.2XNC | IOS-XE Software | IOS-XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | | Please see Cisco | Please see Cisco | | 12.2XND | IOS-XE Software | IOS-XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | | Please see Cisco | Please see Cisco | | 12.2XNE | IOS-XE Software | IOS-XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | | Please see Cisco | Please see Cisco | | 12.2XNF | IOS-XE Software | IOS-XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2XO | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XQ | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Releases prior to | Releases prior to | | | 12.2(15)XR are | 12.2(15)XR are | | | vulnerable; Releases | vulnerable; Releases | | 12.2XR | 12.2(15)XR and later | 12.2(15)XR and later | | | are not vulnerable. | are not vulnerable. | | | First fixed in | First fixed in | | | Release 12.4 | Release 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XS | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XT | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XU | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XV | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2XW | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2YA | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2YC | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2YD | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2YE | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2YK | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2YO | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | | fixed in Release 12.4 | fixed in Release | | 12.2YP | Releases up to and | 15.0M | | | including 12.2(8)YP | Releases up to and | | | are not vulnerable. | including 12.2(8)YP | | | | are not vulnerable. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2YT | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2YW | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2YX | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2YY | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2YZ | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2ZA | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2ZB | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2ZC | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2ZD | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2ZE | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2ZH | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2ZJ | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2ZP | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2ZU | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.2ZX | fixed in Release | fixed in Release | | | 12.2SB | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2ZY | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.2ZYA | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | | First Fixed Release | | Affected | | for All Advisories in | | 12.3-Based | First Fixed Release | the March 2012 Cisco | | Releases | | IOS Software Security | | | | Advisory Bundled | | | | Publication | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3 | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3B | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3BC | fixed in Release | fixed in Release | | | 12.2SCE | 12.2SCE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3BW | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Releases prior to | | | | 12.3(4)JA2 are | | | | vulnerable; Releases | Vulnerable; First | | 12.3JA | 12.3(4)JA2 and later | fixed in Release | | | are not vulnerable. | 12.4JA | | | Migrate to any | | | | release in 12.4JA | | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.3JEA | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.3JEB | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.3JEC | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.3JED | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | Releases up to and | | | | including 12.3(2)JK3 | | | | are not vulnerable. | Vulnerable; First | | 12.3JK | Releases 12.3(8)JK1 | fixed in Release | | | and later are not | 15.0M | | | vulnerable. First | | | | fixed in Release 12.4 | | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.3JL | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | 12.3JX | Not vulnerable | Not vulnerable | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3T | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.3TPC | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | 12.3VA | Not vulnerable | Not vulnerable | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XA | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.3XB | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XC | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XD | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XE | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.3XF | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XG | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XI | fixed in Release | fixed in Release | | | 12.2SB | 12.2SRE | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XJ | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XK | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XL | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XQ | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XR | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XU | fixed in Release | fixed in Release | | | 12.4T | 12.4T | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XW | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XX | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XY | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3XZ | fixed in Release 12.4 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YD | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YF | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YG | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YI | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YJ | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YK | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YM | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YQ | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YS | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YT | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YU | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3YX | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.3YZ | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.3ZA | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | | First Fixed Release | | Affected | | for All Advisories in | | 12.4-Based | First Fixed Release | the March 2012 Cisco | | Releases | | IOS Software Security | | | | Advisory Bundled | | | | Publication | |------------+-----------------------+-----------------------| | | 12.4(25g); Available | Vulnerable; First | | 12.4 | on 19-SEP-12 | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.4GC | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | 12.4JA | Not vulnerable | 12.4(23c)JA4 | | | | 12.4(25e)JA | |------------+-----------------------+-----------------------| | | | Vulnerable; First | | 12.4JAX | Not vulnerable | fixed in Release | | | | 12.4JA | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.4JDA | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.4JDC | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.4JDD | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.4JDE | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.4JHA | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.4JHB | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.4JHC | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.4JK | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 12.4JL | Not vulnerable | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | | Vulnerable; First | | 12.4JX | Not vulnerable | fixed in Release | | | | 12.4JA | |------------+-----------------------+-----------------------| | | | Vulnerable; First | | 12.4JY | Not vulnerable | fixed in Release | | | | 12.4JA | |------------+-----------------------+-----------------------| | | | Vulnerable; First | | 12.4JZ | Not vulnerable | fixed in Release | | | | 12.4JA | |------------+-----------------------+-----------------------| | | 12.4(24)MD7; | 12.4(22)MD3; | | 12.4MD | Available on | Available on | | | 29-Jun-12 | 30-MAR-12 | |------------+-----------------------+-----------------------| | 12.4MDA | 12.4(24)MDA11 | 12.4(24)MDA11 | |------------+-----------------------+-----------------------| | 12.4MDB | 12.4(24)MDB5a | 12.4(24)MDB5a | |------------+-----------------------+-----------------------| | 12.4MDC | Not vulnerable | Not vulnerable | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.4MR | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.4MRA | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4MRB | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | | Vulnerable; First | | 12.4SW | 12.4(15)SW8a | fixed in Release | | | | 15.0M | |------------+-----------------------+-----------------------| | | 12.4(15)T17 | 12.4(15)T17 | | 12.4T | 12.4(24)T7 | 12.4(24)T7 | | | | | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XA | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XB | fixed in Release | fixed in Release | | | 12.4T | 12.4T | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XC | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XD | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XE | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XF | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XG | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XJ | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XK | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.4XL | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XM | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.4XN | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.4XP | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XQ | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XR | fixed in Release | fixed in Release | | | 12.4T | 12.4T | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XT | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.4XV | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XW | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XY | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4XZ | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 12.4YA | fixed in Release | fixed in Release | | | 12.4T | 15.0M | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.4YB | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 12.4YD | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | 12.4YE | 12.4(24)YE3d | 12.4(24)YE3d | |------------+-----------------------+-----------------------| | 12.4YG | 12.4(24)YG4 | 12.4(24)YG4 | |------------+-----------------------+-----------------------| | | | First Fixed Release | | Affected | | for All Advisories in | | 15.0-Based | First Fixed Release | the March 2012 Cisco | | Releases | | IOS Software Security | | | | Advisory Bundled | | | | Publication | |------------+-----------------------+-----------------------| | 15.0M | 15.0(1)M8 | 15.0(1)M8 | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 15.0MR | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 15.0MRA | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | | 15.0(1)S5 | 15.0(1)S5 | | | Cisco IOS XE devices: | Cisco IOS XE devices: | | 15.0S | Please see Cisco IOS | Please see Cisco IOS | | | XE Software | XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | 15.0SA | Not vulnerable | Not vulnerable | |------------+-----------------------+-----------------------| | | 15.0(1)SE1 | | | 15.0SE | 15.0(2)SE; Available | 15.0(1)SE1 | | | on 06-AUG-12 | | |------------+-----------------------+-----------------------| | | 15.0(2)SG2 | 15.0(2)SG2 | | | Cisco IOS XE devices: | Cisco IOS XE devices: | | 15.0SG | Please see Cisco | Please see Cisco | | | IOS-XE Software | IOS-XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | 15.0SY | Not vulnerable | 15.0(1)SY1 | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 15.0XA | fixed in Release | fixed in Release | | | 15.1T | 15.1T | |------------+-----------------------+-----------------------| | | Cisco IOS XE devices: | Cisco IOS XE devices: | | 15.0XO | Please see Cisco | Please see Cisco | | | IOS-XE Software | IOS-XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | | | First Fixed Release | | Affected | | for All Advisories in | | 15.1-Based | First Fixed Release | the March 2012 Cisco | | Releases | | IOS Software Security | | | | Advisory Bundled | | | | Publication | |------------+-----------------------+-----------------------| | 15.1EY | 15.1(2)EY1a | 15.1(2)EY2 | |------------+-----------------------+-----------------------| | 15.1GC | 15.1(2)GC2 | 15.1(2)GC2 | |------------+-----------------------+-----------------------| | 15.1M | 15.1(4)M2 | 15.1(4)M4; Available | | | 15.1(4)M3a | on 30-MAR-12 | |------------+-----------------------+-----------------------| | | | Vulnerable; contact | | | | your support | | | | organization per the | | 15.1MR | 15.1(1)MR3 | instructions in | | | | Obtaining Fixed | | | | Software section of | | | | this advisory. | |------------+-----------------------+-----------------------| | | 15.1(3)S1 | 15.1(3)S2 | | | Cisco IOS XE devices: | Cisco IOS XE devices: | | 15.1S | Please see Cisco IOS | Please see Cisco IOS | | | XE Software | XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | | Not vulnerable | Not vulnerable | | | Cisco IOS XE devices: | Cisco IOS XE devices: | | 15.1SG | Please see Cisco IOS | Please see Cisco IOS | | | XE Software | XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | | Vulnerable; contact | Vulnerable; contact | | | your support | your support | | | organization per the | organization per the | | 15.1SNG | instructions in | instructions in | | | Obtaining Fixed | Obtaining Fixed | | | Software section of | Software section of | | | this advisory. | this advisory. | |------------+-----------------------+-----------------------| | 15.1SNH | Not vulnerable | Not vulnerable | |------------+-----------------------+-----------------------| | | 15.1(1)T5; Available | | | | on 18-MAY-12 | | | 15.1T | 15.1(2)T5; Available | 15.1(3)T3 | | | on 27-APR-12 | | | | 15.1(3)T3 | | |------------+-----------------------+-----------------------| | | Vulnerable; First | Vulnerable; First | | 15.1XB | fixed in Release | fixed in Release | | | 15.1T | 15.1T | |------------+-----------------------+-----------------------| | | | First Fixed Release | | Affected | | for All Advisories in | | 15.2-Based | First Fixed Release | the March 2012 Cisco | | Releases | | IOS Software Security | | | | Advisory Bundled | | | | Publication | |------------+-----------------------+-----------------------| | 15.2GC | 15.2(1)GC1 | 15.2(1)GC2 | |------------+-----------------------+-----------------------| | | Not vulnerable | 15.2(1)S1 | | | Cisco IOS XE devices: | Cisco IOS XE devices: | | 15.2S | Please see Cisco IOS | Please see Cisco IOS | | | XE Software | XE Software | | | Availability | Availability | |------------+-----------------------+-----------------------| | | 15.2(1)T1 | 15.2(1)T2 | | 15.2T | 15.2(2)T | 15.2(2)T1 | | | 15.2(2)T1 | 15.2(3)T; Available | | | | on 30-MAR-12 | +------------------------------------------------------------+ * Cisco Catalyst 3550 Series Switches support the Internet Key Exchange (IKE) feature and are vulnerable to Cisco bug ID CSCts38429 when the devices are running Layer 3 images; however, this product reached the End of Software Maintenance milestone. Cisco 3550 Series SMI Switches that are running Layer 2 images do not support IKE and are not vulnerable. No other Cisco devices that run 12.2SE-based software are vulnerable. Cisco IOS XE Software +-------------------- Cisco IOS XE Software is affected by the vulnerability that is disclosed in this document. +------------------------------------------------------------+ | Cisco IOS | | First Fixed Release for All | | XE | First Fixed | Advisories in the March 2012 | | Software | Release | Cisco IOS Software Security | | Release | | Advisory Bundled Publication | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.1.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.1S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.2.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.1S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.3.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.1S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.4.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.1S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.5.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.1S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 2.6.x | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.1S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 3.1.xS | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.1S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 3.1.xSG | migrate to | Vulnerable; migrate to 3.2.2SG | | | 3.2.2SG or | or later. | | | later. | | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 3.2.xS | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.1S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | 3.2.xSG | 3.2.2SG | 3.2.2SG | |-----------+--------------+---------------------------------| | | Vulnerable; | | | 3.3.xS | migrate to | Vulnerable; migrate to 3.4.2S | | | 3.4.1S or | or later. | | | later. | | |-----------+--------------+---------------------------------| | 3.3.xSG | Not | Not Vulnerable | | | Vulnerable | | |-----------+--------------+---------------------------------| | 3.4.xS | 3.4.1S | 3.4.2S | |-----------+--------------+---------------------------------| | 3.5.xS | Not | 3.5.1S | | | vulnerable | | |-----------+--------------+---------------------------------| | 3.6.xS | Not | Not vulnerable | | | vulnerable | | +------------------------------------------------------------+ For a mapping of Cisco IOS XE Software releases to Cisco IOS Software releases, refer to Cisco IOS XE 2 Release Notes, Cisco IOS XE 3S Release Notes, and Cisco IOS XE 3SG Release Notes. Cisco IOS XR Software +-------------------- Cisco IOS XR Software is not affected by any of the vulnerabilities disclosed in the March 2012 Cisco IOS Software Security Advisory Bundled Publication. Workarounds =========== Customers with an MSDP-configured router who do not require membership to multicast groups can remove the "ip sap listen" or "ip igmp join-group " commands on the router interface as a workaround. For example: RouterA#conf t RouterA(config)# interface GigabitEthernet0/0 RouterA(config-if)# no ip sap listen RouterA(config-if)# no ip igmp join-group 224.2.127.254 interface GigabitEthernet0/0 ip address 192.168.0.1 255.255.255.0 ip pim sparse-mode To determine if a router is configured for MSDP peers, run the command "show ip msdp peer" at the router command prompt: RouterA# show ip msdp peer MSDP Peer 192.168.0.2 (?), AS 100 Connection status: State: Up, Resets: 0, Connection source: none configured Uptime(Downtime): 01:23:42, Messages sent/received: 25/24 Output messages discarded: 0 Connection and counters cleared 01:15:14 ago SA Filtering: Input (S,G) filter: none, route-map: none Input RP filter: none, route-map: none Output (S,G) filter: none, route-map: none Output RP filter: none, route-map: none SA-Requests: Input filter: none Peer ttl threshold: 0 SAs learned from this peer: 0 Input queue size: 0, Output queue size: 0 Message counters: RPF Failure count: 0 SA Messages in/out: 13/8 SA Requests in: 0 SA Responses out: 0 Data Packets in/out: 7/8 To remove an untrusted MSDP peer from your configuration, use the "no ip msdp peer

" or "ip msdp default-peer " command on the router configuration interface. RouterA(config)# no ip msdp peer 192.168.0.2 interface GigabitEthernet0/0 ip address 192.168.0.1 255.255.255.0 ip pim sparse-mode Obtaining Fixed Software ======================== Cisco has released free software updates that address the vulnerability|vulnerabilities described in this advisory. Prior to deploying software, customers are advised to consult their maintenance providers or check the software for feature set compatibility and known issues that are specific to their environments. Customers may only install and expect support for feature sets they have purchased. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as set forth at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, upgrades should be obtained through the Software Center on Cisco.com at http://www.cisco.com. Customers Using Third-Party Support Organizations +------------------------------------------------ Customers with Cisco products that are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers, should contact that organization for assistance with the appropriate course of action. The effectiveness of any workaround or fix depends on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Because of the variety of affected products and releases, customers should consult their service providers or support organizations to ensure that any applied workaround or fix is the most appropriate in the intended network before it is deployed. Customers Without Service Contracts +---------------------------------- Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco Technical Assistance Center (TAC): * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade. Customers without service contracts should request free upgrades through the TAC. Refer to Cisco Worldwide Contacts at http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, instructions, and e-mail addresses for support in various languages. Exploitation and Public Announcements ===================================== The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory. This vulnerability was found during the troubleshooting of customer service requests. Status of This Notice: Final ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco Security Intelligence Operations at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-msdp Additionally, a text version of this advisory is clear signed with the Cisco PSIRT PGP key and circulated among the following e-mail addresses: * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk Future updates of this advisory, if any, will reside on Cisco.com but may not be announced on mailing lists. Users can monitor this advisory's URL for any updates. Revision History ================ +------------------------------------------------------------+ | Revision 1.0 | 2012-March-28 | Initial public release | +------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information about reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco is available on Cisco.com at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This web page includes instructions for press inquiries regarding Cisco Security Advisories. All Cisco Security Advisories are available at http://www.cisco.com/go/psirt. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iF4EAREIAAYFAk9xNOEACgkQQXnnBKKRMND6JgD/TLEfBY6XfhL7hpQW01gFYpBT sO8HTYkhaAOnkwSN/psBAIOin3zSOfsxb42tDq57ub1MvMM7zk28YqWG2V3y6p7G =Ja0H -----END PGP SIGNATURE-----