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 v