From andy at nosignal.org Mon Mar 1 05:06:56 2010 From: andy at nosignal.org (Andy Davidson) Date: Mon, 01 Mar 2010 11:06:56 +0000 Subject: RIPE NCC Position On The ITU IPv6 Group In-Reply-To: <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> Message-ID: <4B8B9FD0.4010302@nosignal.org> On 26/02/2010 22:59, Bill Stewart wrote to nanog: > Maybe I'm dense, but I don't see the problem. The ITU is magic. I am no expert, but I am aware that sometimes the ITU decision making processes leads to member states having to adopt those decisions as telecoms law. I would not want to replace the very good address policy that I follow today with laws and procedures that look like the ones used for telephone numbers. This is a very real danger. That governments can form telecoms law, leads me to the conclusion that we can have an RIR led addressing structure *or* a government one, and not both. > One of the great things about IPv6's address space being > mindbogglingly large is that there's plenty of it to experiment with. No. My IPv6 network is production now. As are the IPv6 networks of many other people on the list. Please don't do experiments with addressing policy, such behaviour tends to leave a nasty legacy. On 01/03/2010 08:55, Arjan van der Oest wrote to members-discuss: > Competition is not a bad thing. Competition would be if I could approach the NCC or Pepsi Cola for my integers for use on the internet. It is not competition if the government makes me ask them for some integers. Andy From andy at nosignal.org Mon Mar 1 08:07:41 2010 From: andy at nosignal.org (Andy Davidson) Date: Mon, 01 Mar 2010 14:07:41 +0000 Subject: RIPE NCC Position On The ITU IPv6 Group In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> <4B8B9FD0.4010302@nosignal.org> Message-ID: <4B8BCA2D.3000505@nosignal.org> On 01/03/2010 14:04, Arjan van der Oest wrote: > Andy wrote: >>> Competition is not a bad thing. >> Competition would be if I could approach the NCC or Pepsi Cola for my >> integers for use on the internet. It is not competition if the >> government makes me ask them for some integers. > Assuming that ITU would become a nationwide alternative RIR, you still > have the choice to approach NCC, wouldn't you? Why would this automatically be the case ? If governments were required to distribute addresses via the national regulator, then the freedom of choice would NOT be the case. > Not sure if Pepsi would be the right comparison for the ITU ;-) My point entirely. :-) Andy From jon at fido.net Mon Mar 1 08:07:50 2010 From: jon at fido.net (Jon Morby | fido) Date: Mon, 1 Mar 2010 14:07:50 +0000 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> <4B8B9FD0.4010302@nosignal.org> Message-ID: On 1 Mar 2010, at 14:04, Arjan van der Oest wrote: > Andy wrote: > >>> Competition is not a bad thing. > >> Competition would be if I could approach the NCC or Pepsi Cola for my >> integers for use on the internet. It is not competition if the >> government makes me ask them for some integers. > > Assuming that ITU would become a nationwide alternative RIR, you still > have the choice to approach NCC, wouldn't you? > > Not sure if Pepsi would be the right comparison for the ITU ;-) > Oh I don't know ... the whole concept leaves a nasty taste in my mouth ... :) > -- > Met vriendelijke groet / Kind Regards, > Worldmax Operations B.V. > > Arjan van der Oest > Network Design Engineer > > T.: +31 (0) 88 001 7912 > F.: +31 (0) 88 001 7902 > M.: +31 (0) 6 10 62 58 46 > > E.: arjan.van.der.oest at worldmax.nl > W.:www.worldmax.nl > W.:www.aerea.nl > GPG: https://keyserver.pgp.com/ (Key ID: 07286F78, fingerprint: 2E9F > 3AE2 0A8B 7579 75A9 169F 5D9E 5312 0728 6F78) > > Internet communications are not secure; therefore, the integrity of this e-mail cannot be guaranteed following transmission on the Internet. This e-mail may contain confidential information. If you have received this e-mail in error, please notify the sender and erase this e-mail. Use of this e-mail by any person other than the addressee is strictly forbidden. This e-mail is believed to be free of any virus that might adversely affect the addressee's computer system; however, no responsibility is accepted for any loss or damage arising in any way from its use. All the preceding disclaimers also apply to any possible attachments to this e-mail. > > ---- > If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ > First click on General and then click on Edit. > At the bottom of the Page you can add or remove addresses. Regards, Jon Morby FidoNet Registration Services Ltd web: www.fido.net tel: +44 (0) 845 004 3050 fax: +44 (0) 845 004 3051 From cmaurand at xyonet.com Mon Mar 1 08:21:33 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Mon, 01 Mar 2010 09:21:33 -0500 Subject: Comcast IPv6 Trials Update In-Reply-To: References: Message-ID: <4B8BCD6D.8040107@xyonet.com> Can anyone recommend a decent book on IPV6? Most of what I find on the net don't explain things very well. thanks, Curtis On 2/28/2010 2:08 PM, John Jason Brzozowski wrote: > Mike, > > Are you looking for something specific on www.comcast6.net? We will likely > be making some content updates in the not too distant future and over time > as the trials progress and evolve. If there is something specific you would > like to see send me your suggestions. > > Thanks, > > John > > > On 2/26/10 1:15 PM, "Michael Greb" wrote: > > >> Received this message today. They haven't updated the >> site yet. >> >> Mike >> >> Begin forwarded message: >> >> >>> An Important Message From Comcast >>> >>> Dear Comcast Customer, >>> >>> Thank you for volunteering to participate in Comcast's IPv6 trials! I wanted >>> to provide you with a quick update on what our next steps are and when you >>> can expect to hear from us again. >>> >>> As you know, we have four trials described at http://www.comcast6.net. We're >>> in detailed planning on the first three: 6RD, plus native dual-stack for >>> residential and for commercial customers. We expect each of these to start >>> sometime within the next 90 days or so. >>> >>> 6RD Trial: >>> We anticipate having customers from around our network, not limited to any >>> specific areas, participate. We will start the trial on a very small scale >>> and then progressively increase the number of participants. We plan to ship a >>> new home gateway device to each trial participant. >>> >>> Residential Native Dual-Stack Trial: >>> This trial will be limited to a few areas in our network. We are in the midst >>> of determining precisely what those areas will be, based on where we have >>> volunteers and where the infrastructure will be ready. If trial participants >>> do not have an IPv6-capable home gateway and cable modem, one will be >>> provided. >>> >>> Commercial Native Dual-Stack Trial: >>> This trial will be limited to a few areas in our network. We have tentatively >>> identified these trial areas and will soon be in touch with potential trial >>> users. >>> >>> Within approximately the next 30 days we will begin to contact some of our >>> volunteers regarding each of these trials, so expect to hear from us soon. >>> >>> Thanks again for your interest! >>> >>> Regards >>> Jason Livingood >>> Internet Systems Engineering >>> Comcast >>> >> >> > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > > From arjan.van.der.oest at worldmax.nl Mon Mar 1 08:24:23 2010 From: arjan.van.der.oest at worldmax.nl (Arjan van der Oest) Date: Mon, 1 Mar 2010 15:24:23 +0100 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group In-Reply-To: <4B8BCA2D.3000505@nosignal.org> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> <4B8B9FD0.4010302@nosignal.org> <4B8BCA2D.3000505@nosignal.org> Message-ID: Andy scribbled: >>>> Competition is not a bad thing. >>> Competition would be if I could approach the NCC or Pepsi Cola for my >>> integers for use on the internet. It is not competition if the >>> government makes me ask them for some integers. >> Assuming that ITU would become a nationwide alternative RIR, you still >> have the choice to approach NCC, wouldn't you? > >Why would this automatically be the case ? If governments were required >to distribute addresses via the national regulator, then the freedom of >choice would NOT be the case. True. Like I said in my initial reply to members-discuss (and while playing a devil's advocate role), I'm not entirely sure what it is that ITU is striving for : replacing IANA or just becoming a nationwide RIR. In the latter case this would not automatically mean (also assuming that local governments will not further interfere in this process) that ITU would be your one and only one-stop-shop for integers. But anyhow, don't get me wrong. I agree with all that has been said on why and how ITU is trying to get a grip on packet switched communication networks. My only point it that it might not be a bad idea to ponder on the subject of allowing competition between RIR's in the same geographical aerea and hence allow ITU to achieve the status of nationwide RIR. If Telco's want to request their IP's from ITU instead of RIPE, they have my utterly blessings... *zipping my Dr. Pepper* -- Met vriendelijke groet / Kind Regards, Worldmax Operations B.V. Arjan van der Oest Network Design Engineer T.: +31 (0) 88 001 7912 F.: +31 (0) 88 001 7902 M.: +31 (0) 6 10 62 58 46 E.: arjan.van.der.oest at worldmax.nl W.:www.worldmax.nl W.:www.aerea.nl GPG: https://keyserver.pgp.com/ (Key ID: 07286F78, fingerprint: 2E9F 3AE2 0A8B 7579 75A9 169F 5D9E 5312 0728 6F78) Internet communications are not secure; therefore, the integrity of this e-mail cannot be guaranteed following transmission on the Internet. This e-mail may contain confidential information. If you have received this e-mail in error, please notify the sender and erase this e-mail. Use of this e-mail by any person other than the addressee is strictly forbidden. This e-mail is believed to be free of any virus that might adversely affect the addressee's computer system; however, no responsibility is accepted for any loss or damage arising in any way from its use. All the preceding disclaimers also apply to any possible attachments to this e-mail. From bdfleming at kanren.net Mon Mar 1 08:27:48 2010 From: bdfleming at kanren.net (Brad Fleming) Date: Mon, 1 Mar 2010 08:27:48 -0600 Subject: Comcast IPv6 Trials Update In-Reply-To: <4B8BCD6D.8040107@xyonet.com> References: <4B8BCD6D.8040107@xyonet.com> Message-ID: <022D99E6-4201-4382-A5D7-50D635245C63@kanren.net> I found "Migrating to IPv6: A practical guide to implementing IPv6 in mobile and fixed networks" by Marc Blanchet very well written and "worth the price of admission". ISBN: 978-0471-49892-6 -- Brad Fleming On Mar 1, 2010, at 8:21 AM, Curtis Maurand wrote: > > Can anyone recommend a decent book on IPV6? Most of what I find on > the net don't explain things very well. > > thanks, > Curtis > > On 2/28/2010 2:08 PM, John Jason Brzozowski wrote: >> Mike, >> >> Are you looking for something specific on www.comcast6.net? We >> will likely >> be making some content updates in the not too distant future and >> over time >> as the trials progress and evolve. If there is something specific >> you would >> like to see send me your suggestions. >> >> Thanks, >> >> John >> >> >> On 2/26/10 1:15 PM, "Michael Greb" wrote: >> >> >>> Received this message today. They haven't updated the >>> site yet. >>> >>> Mike >>> >>> Begin forwarded message: >>> >>> >>>> An Important Message From Comcast >>>> >>>> Dear Comcast Customer, >>>> >>>> Thank you for volunteering to participate in Comcast's IPv6 >>>> trials! I wanted >>>> to provide you with a quick update on what our next steps are and >>>> when you >>>> can expect to hear from us again. >>>> >>>> As you know, we have four trials described at http://www.comcast6.net >>>> . We're >>>> in detailed planning on the first three: 6RD, plus native dual- >>>> stack for >>>> residential and for commercial customers. We expect each of these >>>> to start >>>> sometime within the next 90 days or so. >>>> >>>> 6RD Trial: >>>> We anticipate having customers from around our network, not >>>> limited to any >>>> specific areas, participate. We will start the trial on a very >>>> small scale >>>> and then progressively increase the number of participants. We >>>> plan to ship a >>>> new home gateway device to each trial participant. >>>> >>>> Residential Native Dual-Stack Trial: >>>> This trial will be limited to a few areas in our network. We are >>>> in the midst >>>> of determining precisely what those areas will be, based on where >>>> we have >>>> volunteers and where the infrastructure will be ready. If trial >>>> participants >>>> do not have an IPv6-capable home gateway and cable modem, one >>>> will be >>>> provided. >>>> >>>> Commercial Native Dual-Stack Trial: >>>> This trial will be limited to a few areas in our network. We have >>>> tentatively >>>> identified these trial areas and will soon be in touch with >>>> potential trial >>>> users. >>>> >>>> Within approximately the next 30 days we will begin to contact >>>> some of our >>>> volunteers regarding each of these trials, so expect to hear from >>>> us soon. >>>> >>>> Thanks again for your interest! >>>> >>>> Regards >>>> Jason Livingood >>>> Internet Systems Engineering >>>> Comcast >>>> >>> >>> >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski at cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> ========================================= >> >> >> > > > From John_Brzozowski at Cable.Comcast.com Mon Mar 1 08:37:03 2010 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Mon, 1 Mar 2010 09:37:03 -0500 Subject: Comcast IPv6 Trials Update Message-ID: <997BC128AE961E4A8B880CD7442D948010318495@NJCHLEXCMB01.cable.comcast.com> Did you check out IPv6 Essentials, 2nd edition by Siliva Hagen? ---------------- John 609-377-6594 ---------------- ----- Original Message ----- From: Brad Fleming To: Curtis Maurand Cc: nanog at nanog.org Sent: Mon Mar 01 09:27:48 2010 Subject: Re: Comcast IPv6 Trials Update I found "Migrating to IPv6: A practical guide to implementing IPv6 in mobile and fixed networks" by Marc Blanchet very well written and "worth the price of admission". ISBN: 978-0471-49892-6 -- Brad Fleming On Mar 1, 2010, at 8:21 AM, Curtis Maurand wrote: > > Can anyone recommend a decent book on IPV6? Most of what I find on > the net don't explain things very well. > > thanks, > Curtis > > On 2/28/2010 2:08 PM, John Jason Brzozowski wrote: >> Mike, >> >> Are you looking for something specific on www.comcast6.net? We >> will likely >> be making some content updates in the not too distant future and >> over time >> as the trials progress and evolve. If there is something specific >> you would >> like to see send me your suggestions. >> >> Thanks, >> >> John >> >> >> On 2/26/10 1:15 PM, "Michael Greb" wrote: >> >> >>> Received this message today. They haven't updated the >>> site yet. >>> >>> Mike >>> >>> Begin forwarded message: >>> >>> >>>> An Important Message From Comcast >>>> >>>> Dear Comcast Customer, >>>> >>>> Thank you for volunteering to participate in Comcast's IPv6 >>>> trials! I wanted >>>> to provide you with a quick update on what our next steps are and >>>> when you >>>> can expect to hear from us again. >>>> >>>> As you know, we have four trials described at http://www.comcast6.net >>>> . We're >>>> in detailed planning on the first three: 6RD, plus native dual- >>>> stack for >>>> residential and for commercial customers. We expect each of these >>>> to start >>>> sometime within the next 90 days or so. >>>> >>>> 6RD Trial: >>>> We anticipate having customers from around our network, not >>>> limited to any >>>> specific areas, participate. We will start the trial on a very >>>> small scale >>>> and then progressively increase the number of participants. We >>>> plan to ship a >>>> new home gateway device to each trial participant. >>>> >>>> Residential Native Dual-Stack Trial: >>>> This trial will be limited to a few areas in our network. We are >>>> in the midst >>>> of determining precisely what those areas will be, based on where >>>> we have >>>> volunteers and where the infrastructure will be ready. If trial >>>> participants >>>> do not have an IPv6-capable home gateway and cable modem, one >>>> will be >>>> provided. >>>> >>>> Commercial Native Dual-Stack Trial: >>>> This trial will be limited to a few areas in our network. We have >>>> tentatively >>>> identified these trial areas and will soon be in touch with >>>> potential trial >>>> users. >>>> >>>> Within approximately the next 30 days we will begin to contact >>>> some of our >>>> volunteers regarding each of these trials, so expect to hear from >>>> us soon. >>>> >>>> Thanks again for your interest! >>>> >>>> Regards >>>> Jason Livingood >>>> Internet Systems Engineering >>>> Comcast >>>> >>> >>> >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski at cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> ========================================= >> >> >> > > > From jon at fido.net Mon Mar 1 08:07:50 2010 From: jon at fido.net (Jon Morby | fido) Date: Mon, 1 Mar 2010 14:07:50 +0000 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> <4B8B9FD0.4010302@nosignal.org> Message-ID: On 1 Mar 2010, at 14:04, Arjan van der Oest wrote: > Andy wrote: > >>> Competition is not a bad thing. > >> Competition would be if I could approach the NCC or Pepsi Cola for my >> integers for use on the internet. It is not competition if the >> government makes me ask them for some integers. > > Assuming that ITU would become a nationwide alternative RIR, you still > have the choice to approach NCC, wouldn't you? > > Not sure if Pepsi would be the right comparison for the ITU ;-) > Oh I don't know ... the whole concept leaves a nasty taste in my mouth .... :) > -- > Met vriendelijke groet / Kind Regards, > Worldmax Operations B.V. > > Arjan van der Oest > Network Design Engineer > > T.: +31 (0) 88 001 7912 > F.: +31 (0) 88 001 7902 > M.: +31 (0) 6 10 62 58 46 > > E.: arjan.van.der.oest at worldmax.nl > W.:www.worldmax.nl > W.:www.aerea.nl > GPG: https://keyserver.pgp.com/ (Key ID: 07286F78, fingerprint: 2E9F > 3AE2 0A8B 7579 75A9 169F 5D9E 5312 0728 6F78) > > Internet communications are not secure; therefore, the integrity of this e-mail cannot be guaranteed following transmission on the Internet. This e-mail may contain confidential information. If you have received this e-mail in error, please notify the sender and erase this e-mail. Use of this e-mail by any person other than the addressee is strictly forbidden. This e-mail is believed to be free of any virus that might adversely affect the addressee's computer system; however, no responsibility is accepted for any loss or damage arising in any way from its use. All the preceding disclaimers also apply to any possible attachments to this e-mail. > > ---- > If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ > First click on General and then click on Edit. > At the bottom of the Page you can add or remove addresses. Regards, Jon Morby FidoNet Registration Services Ltd web: www.fido.net tel: +44 (0) 845 004 3050 fax: +44 (0) 845 004 3051 ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From arjan.van.der.oest at worldmax.nl Mon Mar 1 09:42:15 2010 From: arjan.van.der.oest at worldmax.nl (Arjan van der Oest) Date: Mon, 1 Mar 2010 16:42:15 +0100 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: References: Message-ID: CB3ROB scribbled: > let the riots commence 2.0.... Oh dear oh dear... >keep in mind, most telcos and ISPs (the founders and members of the >current IANA -> RIRS -> LIRs model resulting in a global internet which is >hard to censor) do not agree on this ITU proposal... I wonder who those ITU members are then? Are those all currently non-internet-offering telco's? > If we allow them to go forward, this WILL result in a "per country" > easy-to-filter internet in a few years when ipv6 is the only serious > protocol left. /me hands CB3ROB some tinfoil and mumbles : "believers, start your FOLDING!" > we only need to point out how easy it was for the DDR to simply route > all phonecalls to "the west" through a room where people monitored > telephone conversations, and this "country specific prefix" is just what > the ITU seems to want for the internet. Not comparing this to the former-DDR or Chinese situation (please refer to my tin-foil remark above) a per-country specific prefix is not necessarily a bad thing and may even have an upside. > In order to accomplish that they want to create their own address > registry, for now "secondary" to the ISP/telco run bottom-down RIR system > (RIPE,ARIN,APNIC,AFRINIC,APNIC) but ofcourse we can't expect it to take > long before repressive governments start to force "the internets" "in > their country" to use only the ITU registry... Why? > now -we- can always move our office to some other country and take our tax > money to some other resort, not a biggie, but don't come complaining to me > when germany at some point uses this to build their own chinese bigass > golden firewall with flames coming out of its ass to make it faster. Sven, I think several less-democratic nations have already proven that if they require total control of the internet within the boundaries of their country (sic) they can and will implement this anyhow. They don't require ITU nor the UN for this. They will just demand Cisco and Google to implement it and the corporate chiefs will just answer "How soon?"... > methods available to isps/telcos to stop this: > > - point out to governments that -we- own the internet You don't 'own' the internet, at most you own the infra within your own AS. At least you and others don't own my part of the internet :) >their economy runs >over it as a "courtesy" and that we can send them back to the stoneage at >any time we like by simply dropping 'their' traffic. Now that is a very smart thing to say. Another reason for the UN to gain total control... Go on, hand them more sticks. > (considering the fact that governments themselves are not capable of >running anything but a gray-cheese-with-a-dial telephone network Hm, I was under the impression that ARPANET was a government run network... > they need us, we don't need them If they install legislation that forbids anyone without a license to run a telecommunications network of ANY kind, surely you need them, with or without ITU and/or RIR's. > Ask not what you can do for your country, ask what has your country ever > done for you. Oh please Sven, let's not go there :) > we have the biggest stick in this matter. *bzzzz* Sorry, wrong again. The government ultimately draws the longest straw. Always... If they want to, they will. Now let's stop folding tin hats. -- Met vriendelijke groet / Kind Regards, Worldmax Operations B.V. Arjan van der Oest Network Design Engineer T.: +31 (0) 88 001 7912 F.: +31 (0) 88 001 7902 M.: +31 (0) 6 10 62 58 46 E.: arjan.van.der.oest at worldmax.nl W.:www.worldmax.nl W.:www.aerea.nl GPG: https://keyserver.pgp.com/ (Key ID: 07286F78, fingerprint: 2E9F 3AE2 0A8B 7579 75A9 169F 5D9E 5312 0728 6F78) Internet communications are not secure; therefore, the integrity of this e-mail cannot be guaranteed following transmission on the Internet. This e-mail may contain confidential information. If you have received this e-mail in error, please notify the sender and erase this e-mail. Use of this e-mail by any person other than the addressee is strictly forbidden. This e-mail is believed to be free of any virus that might adversely affect the addressee's computer system; however, no responsibility is accepted for any loss or damage arising in any way from its use. All the preceding disclaimers also apply to any possible attachments to this e-mail. From arjan.van.der.oest at worldmax.nl Mon Mar 1 09:42:15 2010 From: arjan.van.der.oest at worldmax.nl (Arjan van der Oest) Date: Mon, 1 Mar 2010 16:42:15 +0100 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: References: Message-ID: CB3ROB scribbled: > let the riots commence 2.0.... Oh dear oh dear... >keep in mind, most telcos and ISPs (the founders and members of the >current IANA -> RIRS -> LIRs model resulting in a global internet which is >hard to censor) do not agree on this ITU proposal... I wonder who those ITU members are then? Are those all currently non-internet-offering telco's? > If we allow them to go forward, this WILL result in a "per country" > easy-to-filter internet in a few years when ipv6 is the only serious > protocol left. /me hands CB3ROB some tinfoil and mumbles : "believers, start your FOLDING!" > we only need to point out how easy it was for the DDR to simply route > all phonecalls to "the west" through a room where people monitored > telephone conversations, and this "country specific prefix" is just what > the ITU seems to want for the internet. Not comparing this to the former-DDR or Chinese situation (please refer to my tin-foil remark above) a per-country specific prefix is not necessarily a bad thing and may even have an upside. > In order to accomplish that they want to create their own address > registry, for now "secondary" to the ISP/telco run bottom-down RIR system > (RIPE,ARIN,APNIC,AFRINIC,APNIC) but ofcourse we can't expect it to take > long before repressive governments start to force "the internets" "in > their country" to use only the ITU registry... Why? > now -we- can always move our office to some other country and take our tax > money to some other resort, not a biggie, but don't come complaining to me > when germany at some point uses this to build their own chinese bigass > golden firewall with flames coming out of its ass to make it faster. Sven, I think several less-democratic nations have already proven that if they require total control of the internet within the boundaries of their country (sic) they can and will implement this anyhow. They don't require ITU nor the UN for this. They will just demand Cisco and Google to implement it and the corporate chiefs will just answer "How soon?"... > methods available to isps/telcos to stop this: > > - point out to governments that -we- own the internet You don't 'own' the internet, at most you own the infra within your own AS. At least you and others don't own my part of the internet :) >their economy runs >over it as a "courtesy" and that we can send them back to the stoneage at >any time we like by simply dropping 'their' traffic. Now that is a very smart thing to say. Another reason for the UN to gain total control... Go on, hand them more sticks. > (considering the fact that governments themselves are not capable of >running anything but a gray-cheese-with-a-dial telephone network Hm, I was under the impression that ARPANET was a government run network... > they need us, we don't need them If they install legislation that forbids anyone without a license to run a telecommunications network of ANY kind, surely you need them, with or without ITU and/or RIR's. > Ask not what you can do for your country, ask what has your country ever > done for you. Oh please Sven, let's not go there :) > we have the biggest stick in this matter. *bzzzz* Sorry, wrong again. The government ultimately draws the longest straw. Always... If they want to, they will. Now let's stop folding tin hats. -- Met vriendelijke groet / Kind Regards, Worldmax Operations B.V. Arjan van der Oest Network Design Engineer T.: +31 (0) 88 001 7912 F.: +31 (0) 88 001 7902 M.: +31 (0) 6 10 62 58 46 E.: arjan.van.der.oest at worldmax.nl W.:www.worldmax.nl W.:www.aerea.nl GPG: https://keyserver.pgp.com/ (Key ID: 07286F78, fingerprint: 2E9F 3AE2 0A8B 7579 75A9 169F 5D9E 5312 0728 6F78) Internet communications are not secure; therefore, the integrity of this e-mail cannot be guaranteed following transmission on the Internet. This e-mail may contain confidential information. If you have received this e-mail in error, please notify the sender and erase this e-mail. Use of this e-mail by any person other than the addressee is strictly forbidden. This e-mail is believed to be free of any virus that might adversely affect the addressee's computer system; however, no responsibility is accepted for any loss or damage arising in any way from its use. All the preceding disclaimers also apply to any possible attachments to this e-mail. ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From awaite at tuenti.com Mon Mar 1 09:55:43 2010 From: awaite at tuenti.com (Adam Waite) Date: Mon, 01 Mar 2010 16:55:43 +0100 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: References: Message-ID: <4B8BE37F.8010705@tuenti.com> > Hm, I was under the impression that ARPANET was a government run > network... > > Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. ARPANET only lives on in reverse dns..... From awaite at tuenti.com Mon Mar 1 09:55:43 2010 From: awaite at tuenti.com (Adam Waite) Date: Mon, 01 Mar 2010 16:55:43 +0100 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: References: Message-ID: <4B8BE37F.8010705@tuenti.com> > Hm, I was under the impression that ARPANET was a government run > network... > > Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. ARPANET only lives on in reverse dns..... ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From jmamodio at gmail.com Mon Mar 1 10:08:10 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 1 Mar 2010 10:08:10 -0600 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <4B8843F4.9070108@foobar.org> <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> <4B8B9FD0.4010302@nosignal.org> <4B8BCA2D.3000505@nosignal.org> Message-ID: <202705b1003010808g42807573m7e45561c9ec9c0a2@mail.gmail.com> > But anyhow, don't get me wrong. I agree with all that has been said on > why and how ITU is trying to get a grip on packet switched communication > networks. My only point it that it might not be a bad idea to ponder on > the subject of allowing competition between RIR's in the same > geographical aerea and hence allow ITU to achieve the status of > nationwide RIR. That will be an extremely bad idea. ITU is aspiring to be a global RIR. Once upon a time since the network architecture/protocols/technology required the assignment/allocation of particular object identifiers that must be globally unique we had Jon Postel's authoritative notepad that later assumed the IANA name and became institutionalized as ICANNzilla. On the address space IANA delegates part of its authority to regional registries and even when there are some common practices and guidelines/policies, each registry establishes its own policies via a bottom-up policy development process for address allocation and how to deal with issues associated with this practice. Since there are requirements/policies associated, each RIR indirectly acts as a soft "regulator" by applying the terms and conditions and collecting fees. It is not a perfect "system" and if something is wrong with a particular RIR or policy that is what needs to be fixed, not create an alternative channel that intends to override the existing "authority" delegation tree by developing its own policies and trying to enforce them through national governments telecom regulations, which imho is what ITU is attempting to do. Basic example (bah very stupid one), Johnny SPAM-BoTnEt on country XX wants IP address space for his operations that in XX-land may not be considered illegal, when service providers direct him to the appropriate RIR there is a chance that the RIR will give a hard time to Johnny to get his address space due the obscurity of his operations that may be illegal in other countries within the region. Then Johnny will go to King of XX who will call his nephew at ITU to get the address space for poor Johnny. Not good. -J From awaite at tuenti.com Mon Mar 1 09:55:43 2010 From: awaite at tuenti.com (Adam Waite) Date: Mon, 01 Mar 2010 16:55:43 +0100 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: References: Message-ID: <4B8BE37F.8010705@tuenti.com> > Hm, I was under the impression that ARPANET was a government run > network... > > Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. ARPANET only lives on in reverse dns..... From arjan.van.der.oest at worldmax.nl Mon Mar 1 10:21:11 2010 From: arjan.van.der.oest at worldmax.nl (Arjan van der Oest) Date: Mon, 1 Mar 2010 17:21:11 +0100 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group In-Reply-To: <044331CC-C797-4E21-AD6F-E3534AD0AB62@me.com> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> <4B8B9FD0.4010302@nosignal.org> <4B8BCA2D.3000505@nosignal.org> <044331CC-C797-4E21-AD6F-E3534AD0AB62@me.com> Message-ID: Skeeve wrote: > Are you really serious about that? The issues seem to me much bigger than > competition though. Yes sir, in theory/conceptually. > The ITU - being an RIR wouldn't satisfy what it seems to setting out trying to > do. Making them an RIR under the current system seems pointless as they aren't > giving off much of a 'team player' vibe... more a fanatical religious > vibe.. They will just define their own policies - which in the end may have an > actual realised negative impact on the routing system - the details of which are > for a different discussion. Again: as long as they don't interfere with IANA and RIR's and assuming there is no aluminum hat conspiracy that tries to achieve world-domination-via-ipv6 I wish them all the best. If they wish to implement some ridiculous policies concerning the assignment of IPv6 space via the ITU, let them. The result will be that all the telco's and ISP's will continue to use the current RIR's and ITU will prove their existence is useless. > Given that the ITU, like the RIR, are a member driven system.... that to me > suggests that there are specific members who are pushing for this... I've heard > 'Syria' being tossed around as an agitator in this... but that there are other > supporters who are not happy with the US Government dominance/control of the > process. Which I can imagine, without the urge to start a political discussion here :) > But the RIR system has been running for a long time... and 'not badly' for the > most part.... so why do we really need to change anything? Why are people so scared of change? It's not a bad thing... > Really.. if there were MASSIVE problems with the RIR system, the members would > have kicked some ass a long time ago. Imho there is no massive problem with the RIR system, although there is always room for improvement. Again, my only point is: allocating space to ITU may settle whatever worries they have. I'm just trying to point out that competition (and change) are not a bad thing and I'm reluctant to start seeking conspiracies about world domination via ipv6. Let's see what it is ITU is *really* trying to get done, let's chat about it and then let's see what is wise. With all respect to Sven Kamphuis, that is exactly the reaction I would not see as the best towards the UN and ITU. Just my 2 cents -- Met vriendelijke groet / Kind Regards, Worldmax Operations B.V. Arjan van der Oest Network Design Engineer T.: +31 (0) 88 001 7912 F.: +31 (0) 88 001 7902 M.: +31 (0) 6 10 62 58 46 E.: arjan.van.der.oest at worldmax.nl W.:www.worldmax.nl W.:www.aerea.nl GPG: https://keyserver.pgp.com/ (Key ID: 07286F78, fingerprint: 2E9F 3AE2 0A8B 7579 75A9 169F 5D9E 5312 0728 6F78) Internet communications are not secure; therefore, the integrity of this e-mail cannot be guaranteed following transmission on the Internet. This e-mail may contain confidential information. If you have received this e-mail in error, please notify the sender and erase this e-mail. Use of this e-mail by any person other than the addressee is strictly forbidden. This e-mail is believed to be free of any virus that might adversely affect the addressee's computer system; however, no responsibility is accepted for any loss or damage arising in any way from its use. All the preceding disclaimers also apply to any possible attachments to this e-mail. From arjan.van.der.oest at worldmax.nl Mon Mar 1 10:21:11 2010 From: arjan.van.der.oest at worldmax.nl (Arjan van der Oest) Date: Mon, 1 Mar 2010 17:21:11 +0100 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group In-Reply-To: <044331CC-C797-4E21-AD6F-E3534AD0AB62@me.com> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <1267208530.26166.15.camel@ub-g-d2> <4B8843F4.9070108@foobar.org> <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> <4B8B9FD0.4010302@nosignal.org> <4B8BCA2D.3000505@nosignal.org> <044331CC-C797-4E21-AD6F-E3534AD0AB62@me.com> Message-ID: Skeeve wrote: > Are you really serious about that? The issues seem to me much bigger than > competition though. Yes sir, in theory/conceptually. > The ITU - being an RIR wouldn't satisfy what it seems to setting out trying to > do. Making them an RIR under the current system seems pointless as they aren't > giving off much of a 'team player' vibe... more a fanatical religious > vibe.. They will just define their own policies - which in the end may have an > actual realised negative impact on the routing system - the details of which are > for a different discussion. Again: as long as they don't interfere with IANA and RIR's and assuming there is no aluminum hat conspiracy that tries to achieve world-domination-via-ipv6 I wish them all the best. If they wish to implement some ridiculous policies concerning the assignment of IPv6 space via the ITU, let them. The result will be that all the telco's and ISP's will continue to use the current RIR's and ITU will prove their existence is useless. > Given that the ITU, like the RIR, are a member driven system.... that to me > suggests that there are specific members who are pushing for this... I've heard > 'Syria' being tossed around as an agitator in this... but that there are other > supporters who are not happy with the US Government dominance/control of the > process. Which I can imagine, without the urge to start a political discussion here :) > But the RIR system has been running for a long time... and 'not badly' for the > most part.... so why do we really need to change anything? Why are people so scared of change? It's not a bad thing... > Really.. if there were MASSIVE problems with the RIR system, the members would > have kicked some ass a long time ago. Imho there is no massive problem with the RIR system, although there is always room for improvement. Again, my only point is: allocating space to ITU may settle whatever worries they have. I'm just trying to point out that competition (and change) are not a bad thing and I'm reluctant to start seeking conspiracies about world domination via ipv6. Let's see what it is ITU is *really* trying to get done, let's chat about it and then let's see what is wise. With all respect to Sven Kamphuis, that is exactly the reaction I would not see as the best towards the UN and ITU. Just my 2 cents -- Met vriendelijke groet / Kind Regards, Worldmax Operations B.V. Arjan van der Oest Network Design Engineer T.: +31 (0) 88 001 7912 F.: +31 (0) 88 001 7902 M.: +31 (0) 6 10 62 58 46 E.: arjan.van.der.oest at worldmax.nl W.:www.worldmax.nl W.:www.aerea.nl GPG: https://keyserver.pgp.com/ (Key ID: 07286F78, fingerprint: 2E9F 3AE2 0A8B 7579 75A9 169F 5D9E 5312 0728 6F78) Internet communications are not secure; therefore, the integrity of this e-mail cannot be guaranteed following transmission on the Internet. This e-mail may contain confidential information. If you have received this e-mail in error, please notify the sender and erase this e-mail. Use of this e-mail by any person other than the addressee is strictly forbidden. This e-mail is believed to be free of any virus that might adversely affect the addressee's computer system; however, no responsibility is accepted for any loss or damage arising in any way from its use. All the preceding disclaimers also apply to any possible attachments to this e-mail. ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From drc at virtualized.org Mon Mar 1 10:59:13 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 1 Mar 2010 08:59:13 -0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: References: Message-ID: On Mar 1, 2010, at 7:42 AM, Arjan van der Oest wrote: >> keep in mind, most telcos and ISPs (the founders and members of the >> current IANA -> RIRS -> LIRs model resulting in a global internet which is >> hard to censor) do not agree on this ITU proposal... > > I wonder who those ITU members are then? Are those all currently > non-internet-offering telco's? Government departments/ministries? Even in the case of sector members, the folks who attend ITU generally are not the folks who attend RIR/NANOG meetings. > Not comparing this to the former-DDR or Chinese situation (please refer > to my tin-foil remark above) a per-country specific prefix is not > necessarily a bad thing and may even have an upside. There are, of course, plusses and minuses to country based allocations. On the plus side, it makes geo-location easier. On the minus side, it makes geo-location easier. It would also likely increase the number of routing prefixes announced by multi-nationals (not that this matters all that much in the grand scheme of things). It may also greatly simplify a return to the settlements-based regime that was the norm before around 1996 or so. However, I suspect the biggest change is that the moves where address policy is made away from the folks who are directly impacted by that policy (ISPs) to governments/PTTs. Please read some of the contributions at http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx and determine for yourself whether you think they would make good policies. >> In order to accomplish that they want to create their own address >> registry, for now "secondary" to the ISP/telco run bottom-down RIR system >> (RIPE,ARIN,APNIC,AFRINIC,APNIC) but ofcourse we can't expect it to take >> long before repressive governments start to force "the internets" "in >> their country" to use only the ITU registry... > > Why? Because they are repressive? > Now let's stop folding tin hats. It has been noted in the past that you're not necessarily paranoid if they really are out to get you. Regards, -drc From LarrySheldon at cox.net Mon Mar 1 11:04:19 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 01 Mar 2010 11:04:19 -0600 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <4B8BE37F.8010705@tuenti.com> References: <4B8BE37F.8010705@tuenti.com> Message-ID: <4B8BF393.40808@cox.net> On 3/1/2010 9:55 AM, Adam Waite wrote: > >> Hm, I was under the impression that ARPANET was a government run >> network... >> >> > Not since 1992......what you're looking for these days is NIPRnet and > SIPRnet, and ESnet, etc, etc, etc. > > ARPANET only lives on in reverse dns..... And that is only the TLD label. Is there still a DARPANET, ARPANET's successor? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jabley at hopcount.ca Mon Mar 1 11:18:51 2010 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 1 Mar 2010 12:18:51 -0500 Subject: 6to4 on Sprint Wireless Broadband In-Reply-To: <20100227151325.GB671@koltblut.setec.org> References: <20100227151325.GB671@koltblut.setec.org> Message-ID: <703905D8-29CB-4D62-AEC2-01412B69EA14@hopcount.ca> On 2010-02-27, at 10:13, Izaac wrote: > A few months ago, is appears that Sprint started dropping 6to4 > encapsulated packets. Egress is fine. Ingress silently drops. Anyone > see anything similar? Or am I the only guy crazy enough to be doing > this sort of thing in the first place? 6to4 is a method for tunnelling v6 over v4 without statically-configuring endpoints. The encapsulation used is protocol-41, i.e. the same as "tunnel mode ipv6ip" in IOS or "interfaces ip-a/b/c" in JUNOS. It seems unlikely that Spring has decided to block IPv4 packets with protocol 41 payload. What seems far more likely is that the relay routers used for return packets from the hosts you are trying to talk to are hitting a broken 6to4 relay router, and hence the return traffic is being (from your perspective) silently discarded. Joe From Valdis.Kletnieks at vt.edu Mon Mar 1 11:25:31 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 01 Mar 2010 12:25:31 -0500 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: Your message of "Mon, 01 Mar 2010 16:42:15 +0100." References: Message-ID: <10497.1267464331@localhost> On Mon, 01 Mar 2010 16:42:15 +0100, Arjan van der Oest said: > > (considering the fact that governments themselves are not capable of > >running anything but a gray-cheese-with-a-dial telephone network > > Hm, I was under the impression that ARPANET was a government run > network... I would not be surprised if some of the bigger providers now have bigger networks in their test labs than the ARPANET/MILNET combo was - ISTR it was on the order of 4,000 total nodes in the 1984 era. I remember being surprised when my then-current employer joined both networks that the 3,000+ nodes on Bitnet and the size of the Arpa/Mil aggregate being comparable (and Bitnet may have been even bigger at some points). And let's face it - the Arpa/Milnet was a test network, not a production network. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ron at nosc.mil Mon Mar 1 11:49:50 2010 From: ron at nosc.mil (Ron Broersma) Date: Mon, 1 Mar 2010 09:49:50 -0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <10497.1267464331@localhost> References: <10497.1267464331@localhost> Message-ID: On Mar 1, 2010, at 9:25 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 01 Mar 2010 16:42:15 +0100, Arjan van der Oest said: > >>> (considering the fact that governments themselves are not capable of >>> running anything but a gray-cheese-with-a-dial telephone network >> >> Hm, I was under the impression that ARPANET was a government run >> network... > > And let's face it - the Arpa/Milnet was a test network, not a production > network. It may have started as a research network, but was very much used for production activities by late 70's and early 80's. --Ron (Site coordinator for Arpanet IMP #3) From Paul.Martin at viatel.com Mon Mar 1 12:23:53 2010 From: Paul.Martin at viatel.com (Martin, Paul) Date: Mon, 1 Mar 2010 18:23:53 -0000 Subject: Comcast IPv6 Trials Update In-Reply-To: <997BC128AE961E4A8B880CD7442D948010318495@NJCHLEXCMB01.cable.comcast.com> References: <997BC128AE961E4A8B880CD7442D948010318495@NJCHLEXCMB01.cable.comcast.com> Message-ID: <6E91D15697439543A9636FCA11BDA1C511235470@eghexch01.viatel.local> I've just bought "IPv6 Essentials", however it turned out to be the 1st edition, hopefully there won't be too many differences. I'm also going to go through this PDF on the Cisco website that should put a practical face on the book, which seems very theoretical on a quick flick through ... http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/12_4/ipv6_1 2_4_book.pdf -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski at Cable.Comcast.com] Sent: 01 March 2010 14:37 To: bdfleming at kanren.net; cmaurand at xyonet.com Cc: nanog at nanog.org Subject: Re: Comcast IPv6 Trials Update Did you check out IPv6 Essentials, 2nd edition by Siliva Hagen? ---------------- John 609-377-6594 ---------------- ----- Original Message ----- From: Brad Fleming To: Curtis Maurand Cc: nanog at nanog.org Sent: Mon Mar 01 09:27:48 2010 Subject: Re: Comcast IPv6 Trials Update I found "Migrating to IPv6: A practical guide to implementing IPv6 in mobile and fixed networks" by Marc Blanchet very well written and "worth the price of admission". ISBN: 978-0471-49892-6 -- Brad Fleming On Mar 1, 2010, at 8:21 AM, Curtis Maurand wrote: > > Can anyone recommend a decent book on IPV6? Most of what I find on > the net don't explain things very well. > > thanks, > Curtis > > On 2/28/2010 2:08 PM, John Jason Brzozowski wrote: >> Mike, >> >> Are you looking for something specific on www.comcast6.net? We >> will likely >> be making some content updates in the not too distant future and >> over time >> as the trials progress and evolve. If there is something specific >> you would >> like to see send me your suggestions. >> >> Thanks, >> >> John >> >> >> On 2/26/10 1:15 PM, "Michael Greb" wrote: >> >> >>> Received this message today. They haven't updated the >>> site yet. >>> >>> Mike >>> >>> Begin forwarded message: >>> >>> >>>> An Important Message From Comcast >>>> >>>> Dear Comcast Customer, >>>> >>>> Thank you for volunteering to participate in Comcast's IPv6 >>>> trials! I wanted >>>> to provide you with a quick update on what our next steps are and >>>> when you >>>> can expect to hear from us again. >>>> >>>> As you know, we have four trials described at http://www.comcast6.net >>>> . We're >>>> in detailed planning on the first three: 6RD, plus native dual- >>>> stack for >>>> residential and for commercial customers. We expect each of these >>>> to start >>>> sometime within the next 90 days or so. >>>> >>>> 6RD Trial: >>>> We anticipate having customers from around our network, not >>>> limited to any >>>> specific areas, participate. We will start the trial on a very >>>> small scale >>>> and then progressively increase the number of participants. We >>>> plan to ship a >>>> new home gateway device to each trial participant. >>>> >>>> Residential Native Dual-Stack Trial: >>>> This trial will be limited to a few areas in our network. We are >>>> in the midst >>>> of determining precisely what those areas will be, based on where >>>> we have >>>> volunteers and where the infrastructure will be ready. If trial >>>> participants >>>> do not have an IPv6-capable home gateway and cable modem, one >>>> will be >>>> provided. >>>> >>>> Commercial Native Dual-Stack Trial: >>>> This trial will be limited to a few areas in our network. We have >>>> tentatively >>>> identified these trial areas and will soon be in touch with >>>> potential trial >>>> users. >>>> >>>> Within approximately the next 30 days we will begin to contact >>>> some of our >>>> volunteers regarding each of these trials, so expect to hear from >>>> us soon. >>>> >>>> Thanks again for your interest! >>>> >>>> Regards >>>> Jason Livingood >>>> Internet Systems Engineering >>>> Comcast >>>> >>> >>> >> ========================================= >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski at cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> ========================================= >> >> >> > > > For more information about the Viatel Group, please visit www.viatel.com VTL (UK) Limited Registered in England and Wales Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR Company Registration No: 04287100 VAT Registration Number: 781 4991 88 THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this e-mail is prohibited, and you should delete this e-mail from your system. This message has been scanned for viruses and spam by Viatel MailControl - www.viatel.com From owen at delong.com Mon Mar 1 12:40:22 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Mar 2010 02:40:22 +0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: References: Message-ID: <541B85C5-1FB0-4D20-B62A-15D4222E4E78@delong.com> On Mar 1, 2010, at 11:42 PM, Arjan van der Oest wrote: > CB3ROB scribbled: > >> let the riots commence 2.0.... > > Oh dear oh dear... > >> keep in mind, most telcos and ISPs (the founders and members of the >> current IANA -> RIRS -> LIRs model resulting in a global internet which > is >> hard to censor) do not agree on this ITU proposal... > > I wonder who those ITU members are then? Are those all currently > non-internet-offering telco's? > The voting members of the ITU are national governments. The telcos get to speak at some ITU sessions and get to attend most of them, but, they don't generally get to vote as I understand it. >> If we allow them to go forward, this WILL result in a "per country" >> easy-to-filter internet in a few years when ipv6 is the only serious >> protocol left. > > /me hands CB3ROB some tinfoil and mumbles : "believers, start your > FOLDING!" > >> we only need to point out how easy it was for the DDR to simply route >> all phonecalls to "the west" through a room where people monitored >> telephone conversations, and this "country specific prefix" is just > what >> the ITU seems to want for the internet. > > Not comparing this to the former-DDR or Chinese situation (please refer > to my tin-foil remark above) a per-country specific prefix is not > necessarily a bad thing and may even have an upside. > Care to explain what that could possibly be? (I simply don't see an upside to making it easy to censor the internet by national identity). >> In order to accomplish that they want to create their own address >> registry, for now "secondary" to the ISP/telco run bottom-down RIR > system >> (RIPE,ARIN,APNIC,AFRINIC,APNIC) but ofcourse we can't expect it to > take >> long before repressive governments start to force "the internets" "in >> their country" to use only the ITU registry... > > Why? > Because such is the nature of repressive governments? >> now -we- can always move our office to some other country and take our > tax >> money to some other resort, not a biggie, but don't come complaining > to me >> when germany at some point uses this to build their own chinese bigass > >> golden firewall with flames coming out of its ass to make it faster. > > Sven, I think several less-democratic nations have already proven that > if they require total control of the internet within the boundaries of > their country (sic) they can and will implement this anyhow. They don't > require ITU nor the UN for this. They will just demand Cisco and Google > to implement it and the corporate chiefs will just answer "How soon?"... > In fact, so far, said countries have had only minimal success with this approach. Look at the tunneling out of Iran during the recent events and the amount of "unauthorized" information which made it out to the world via the internet. In general, the current internet regards censorship as damage and routes around it. Giving repressive regimes the ability to know that all the addresses they want to allow to communicate are in a defined prefix would make effective censorship much easier and make working around that problem much harder. In spite of this fact, that is not the primary reason to oppose the ITU proposal. Competing Internet Registry structures where one structure is not bound by the stratagems of RFC-2050, or, for that matter, any form of policy other than what each national IR chooses to implement is a recipe for disaster in address policy. Imagine, for example, what happens when $NATION decides that spammers are a good source of revenue and starts selling them rotating address chunks for a fee. Pretty soon, the IPv6 address space could end up looking like the island of Nauru. (http://www.lawanddevelopment.org/docs/nauru.pdf) > >> (considering the fact that governments themselves are not capable of >> running anything but a gray-cheese-with-a-dial telephone network > > Hm, I was under the impression that ARPANET was a government run > network... > No, ARPANET was a government sponsored network run by researchers. The fact that it is a cooperative anarchy rather than a highly structured centralized management structure pretty much proves that although the government funded it and pointed in a vague development direction, they had little to do with the implementation details and even less to do with the operational details. >> they need us, we don't need them > > If they install legislation that forbids anyone without a license to run > a telecommunications network of ANY kind, surely you need them, with or > without ITU and/or RIR's. > And yet so long as a given country has at least one licensed carrier doing some level of international IP based services it becomes almost impossible to inflict deeper policy on what use those IP based services are put to. OTOH, a wide-spread crackdown of national control over prefix distribution could make that much worse. Owen From tvarriale at comcast.net Mon Mar 1 12:43:42 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Mon, 1 Mar 2010 12:43:42 -0600 Subject: Comcast IPv6 Trials Update References: <4B8BCD6D.8040107@xyonet.com> Message-ID: <7DE9A3EDB07149BF961C1FA7FD6AB44F@flamdt01> ----- Original Message ----- From: "Curtis Maurand" To: Sent: Monday, March 01, 2010 8:21 AM Subject: Re: Comcast IPv6 Trials Update > > Can anyone recommend a decent book on IPV6? Most of what I find on the > net don't explain things very well. > > thanks, > Curtis > Deploying IPv6 Networks is pretty good. Definitely not a beginner book and is geared towards service providers. Note that it is a CP book... tv From owen at delong.com Mon Mar 1 12:42:52 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Mar 2010 02:42:52 +0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <4B8BE37F.8010705@tuenti.com> References: <4B8BE37F.8010705@tuenti.com> Message-ID: <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> On Mar 1, 2010, at 11:55 PM, Adam Waite wrote: > >> Hm, I was under the impression that ARPANET was a government run >> network... >> >> > Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. > > ARPANET only lives on in reverse dns..... > > Um, actually, I would say that in all of those cases, including ARPANET when it existed, you are dealing with a government sponsored network rather than a government run network. Generally, in each of those cases, the government provides some or all of the money to keep the network going, but, has very little to do with dictating policy or operational aspects of the network. Owen From smb at cs.columbia.edu Mon Mar 1 12:53:49 2010 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 1 Mar 2010 13:53:49 -0500 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <4B8BF393.40808@cox.net> References: <4B8BE37F.8010705@tuenti.com> <4B8BF393.40808@cox.net> Message-ID: <20100301135349.11c8937a@cs.columbia.edu> On Mon, 01 Mar 2010 11:04:19 -0600 Larry Sheldon wrote: > On 3/1/2010 9:55 AM, Adam Waite wrote: > > > >> Hm, I was under the impression that ARPANET was a government run > >> network... > >> > >> > > Not since 1992......what you're looking for these days is NIPRnet > > and SIPRnet, and ESnet, etc, etc, etc. > > > > ARPANET only lives on in reverse dns..... > > And that is only the TLD label. > > Is there still a DARPANET, ARPANET's successor? > > Depends on what you mean. As noted, there are government-only IP networks, some of which are not connected to the public Internet. SIPRNET, for example, is the "Secret IP Router Network", for lightly-classified traffic. --Steve Bellovin, http://www.cs.columbia.edu/~smb From owen at delong.com Mon Mar 1 12:42:52 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Mar 2010 02:42:52 +0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <4B8BE37F.8010705@tuenti.com> References: <4B8BE37F.8010705@tuenti.com> Message-ID: <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> On Mar 1, 2010, at 11:55 PM, Adam Waite wrote: > >> Hm, I was under the impression that ARPANET was a government run >> network... >> >> > Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. > > ARPANET only lives on in reverse dns..... > > Um, actually, I would say that in all of those cases, including ARPANET when it existed, you are dealing with a government sponsored network rather than a government run network. Generally, in each of those cases, the government provides some or all of the money to keep the network going, but, has very little to do with dictating policy or operational aspects of the network. Owen From tony at lava.net Mon Mar 1 13:12:58 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 1 Mar 2010 09:12:58 -1000 (HST) Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> References: <4B8BE37F.8010705@tuenti.com> <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> Message-ID: On Tue, 2 Mar 2010, Owen DeLong wrote: > On Mar 1, 2010, at 11:55 PM, Adam Waite wrote: >> Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. > Um, actually, I would say that in all of those cases, including ARPANET when it existed, you are > dealing with a government sponsored network rather than a government run network. > > Generally, in each of those cases, the government provides some or all of the money to keep > the network going, but, has very little to do with dictating policy or operational aspects of the > network. I think DISA and DoD would argue about that claim with regard to NIPRNet and SIPRNet :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From tony at lava.net Mon Mar 1 13:12:58 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 1 Mar 2010 09:12:58 -1000 (HST) Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> References: <4B8BE37F.8010705@tuenti.com> <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> Message-ID: On Tue, 2 Mar 2010, Owen DeLong wrote: > On Mar 1, 2010, at 11:55 PM, Adam Waite wrote: >> Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. > Um, actually, I would say that in all of those cases, including ARPANET when it existed, you are > dealing with a government sponsored network rather than a government run network. > > Generally, in each of those cases, the government provides some or all of the money to keep > the network going, but, has very little to do with dictating policy or operational aspects of the > network. I think DISA and DoD would argue about that claim with regard to NIPRNet and SIPRNet :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From LarrySheldon at cox.net Mon Mar 1 14:09:51 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 01 Mar 2010 14:09:51 -0600 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <20100301135349.11c8937a@cs.columbia.edu> References: <4B8BE37F.8010705@tuenti.com> <4B8BF393.40808@cox.net> <20100301135349.11c8937a@cs.columbia.edu> Message-ID: <4B8C1F0F.6080102@cox.net> On 3/1/2010 12:53 PM, Steven M. Bellovin wrote: > On Mon, 01 Mar 2010 11:04:19 -0600 > Larry Sheldon wrote: > >> On 3/1/2010 9:55 AM, Adam Waite wrote: >>> >>>> Hm, I was under the impression that ARPANET was a government run >>>> network... >>>> >>>> >>> Not since 1992......what you're looking for these days is NIPRnet >>> and SIPRnet, and ESnet, etc, etc, etc. >>> >>> ARPANET only lives on in reverse dns..... >> >> And that is only the TLD label. >> >> Is there still a DARPANET, ARPANET's successor? >> >> > Depends on what you mean. I meant "is there still a DARPAnet" separate and apart from its progeny, fragments, and follow-ons. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From oberman at es.net Mon Mar 1 15:30:24 2010 From: oberman at es.net (Kevin Oberman) Date: Mon, 01 Mar 2010 13:30:24 -0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: Your message of "Mon, 01 Mar 2010 16:55:43 +0100." <4B8BE37F.8010705@tuenti.com> Message-ID: <20100301213024.597291CC13@ptavv.es.net> > Date: Mon, 01 Mar 2010 16:55:43 +0100 > From: Adam Waite > > > > Hm, I was under the impression that ARPANET was a government run > > network... > > > > > Not since 1992......what you're looking for these days is NIPRnet and > SIPRnet, and ESnet, etc, etc, etc. While ESnet is funded by the Department of Energy and they certainly define the strategic policy of ESnet, they don't make design decisions nor get involved with the technical end of the network. ESnet is run by the University of California's Berkeley Lab under contract to the DOE. This may sound like hair splitting, but it is really very different from Fednets like NIPR and SIPR (and many, many others) including the Department of Energy's own DOEnet. Note that DOEnet is used for DOE business operations while ESnet is use support DOE funded research. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From oberman at es.net Mon Mar 1 15:30:24 2010 From: oberman at es.net (Kevin Oberman) Date: Mon, 01 Mar 2010 13:30:24 -0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: Your message of "Mon, 01 Mar 2010 16:55:43 +0100." <4B8BE37F.8010705@tuenti.com> Message-ID: <20100301213024.597291CC13@ptavv.es.net> > Date: Mon, 01 Mar 2010 16:55:43 +0100 > From: Adam Waite > > > > Hm, I was under the impression that ARPANET was a government run > > network... > > > > > Not since 1992......what you're looking for these days is NIPRnet and > SIPRnet, and ESnet, etc, etc, etc. While ESnet is funded by the Department of Energy and they certainly define the strategic policy of ESnet, they don't make design decisions nor get involved with the technical end of the network. ESnet is run by the University of California's Berkeley Lab under contract to the DOE. This may sound like hair splitting, but it is really very different from Fednets like NIPR and SIPR (and many, many others) including the Department of Energy's own DOEnet. Note that DOEnet is used for DOE business operations while ESnet is use support DOE funded research. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From wbailey at gci.com Mon Mar 1 18:19:38 2010 From: wbailey at gci.com (Warren Bailey) Date: Mon, 1 Mar 2010 15:19:38 -0900 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <643429FE-57D4-4B39-82FD-C5BC1A9637D9@senie.com> References: <1002262134.AA10367@ivan.Harhan.ORG> <643429FE-57D4-4B39-82FD-C5BC1A9637D9@senie.com> Message-ID: <5B3743FC2D0D8B41B27EE4F5EACA79D10D23C143@DTN1EX01.gci.com> How do you think we feel in Alaska. Until mid last year, most cellular BTS were backhauled via DS1. Only Within the last 12 months have we (insert obligatory "I work for a GSM and CDMA cellular provider serving most of Alaska") even migrated from Local copper to fiber or air interfaces (ds1/ds3 microwave). I've always been curious as to why the people who aren't being served with "broadband" type of services haven't made a larger fuss about this. The idea of running a copper pair to a home should have died long ago, IMHO. As an RF Engineer, I see everyone turning to fiber and dry loops when it's just not necessary or even cost effective. Put up the *LICENSED* loop and call it a day.. Or a 5.8 RAD shot when you feel like rolling the deice. Either way, cellular isn't the drop dead answer to solving a sparsely covered area. About 95% of my state is not covered by cellular, but we've had no problems deploying the largest cellular (rural obviously) provider in the United States - just look up. It's not as expensive as you would think. //warren Warren Bailey GCI Communication Corp. RF Network Engineering 907.868.5911 office 907.903.5410 mobile -----Original Message----- From: Daniel Senie [mailto:dts at senie.com] Sent: Friday, February 26, 2010 3:21 PM To: NANOG list Subject: Re: Locations with no good Internet (was ISP in Johannesburg) Hopefully someone will bother to cover the rural areas with cell service eventually. Much of western Massachusetts (by which I mean the Berkshires, more than I mean the Pioneer Valley) is not covered by cell service. Where there is cell service, most cell sites have only minimal data speeds. Vermont is far worse, as is much of Maine. If there were 3G cellular, it'd be a big step up. But I expect the inner cities will all be running LTE for years before more rural areas even get voice service. On Feb 26, 2010, at 6:04 PM, Haney, Wilson wrote: > As we all know it's expensive building out any landline network. Rural areas just get over looked. > > Check out this tech coming out of Motorola and to a Verizon/ATT tower near you soon. > > 100 Mbps possible off cellular signals. Looks like they will throttle it to 20 Mbps and less though. > > http://business.motorola.com/experiencelte/lte-depth.html > > http://news.techworld.com/networking/3203498/motorola-predicts-20mbps- > download-speed-with-future-lte-networks/ > > WPH > > -----Original Message----- > From: Crooks, Sam [mailto:Sam.Crooks at experian.com] > Sent: Friday, February 26, 2010 4:51 PM > To: Michael Sokolov; nanog at nanog.org > Subject: RE: Locations with no good Internet (was ISP in Johannesburg) > > I had good luck getting my dad some form of broadband access in rural > Oregon using a 3g router (Cradlepoint), a Wilson Electronics signal > amp (model 811211), and an outdoor mount high gain antenna. It's not > great, but considering the alternatives (33.6k dialup for $60/mo or > satellite broadband for $150-$200/mo) it wasn't a bad deal for my dad > when you consider that the dialup ISP + dedicated POTS line cost about > as much as the 5GB 3G data plan does. > > Speed is somewhere between dialup and Uverse or FIOS. I get the > sense that it is somewhere in the range of 256 - 512 kbps with high > latency (Dad's not one for much in the way of network performance testing). > > > >> -----Original Message----- >> From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] >> Sent: Friday, February 26, 2010 3:35 PM >> To: nanog at nanog.org >> Subject: Locations with no good Internet (was ISP in Johannesburg) >> >> Daniel Senie wrote: >> >>> Better than western Massachusetts, where there's just no > connectivity >> at = >>> all. Even dialup fails to function over crappy lines. >> >> Hmm. Although I've never been to Western MA and hence have no idea >> what the telecom situation is like over there, I'm certainly aware of >> quite a few places in "first world USA" where DSL is still a fantasy, >> let > alone >> fiber. >> >> As a local example, I have a friend in a rural area of Southern >> California who can't get any kind of "high-speed Internet". I've run > a >> prequal on her address and it tells me she is 31 kft from the CO. >> The CO in question has a Covad DSLAM in it, but at 31 kft those rural >> residents' options are limited to either IDSL at 144 kbps (not much >> point in that) or a T1 starting at ~$700/month. The latter figure is >> typically well out of range for the kind of people who live in such >> places. >> >> That got me thinking: ISDN/IDSL and T1 can be extended infinitely far >> into the boondocks because those signal formats support repeaters. >> What >> I'm wondering is how can we do the same thing with SDSL - and I mean >> politically rather than technically. The technical part is easy: >> some COs already have CLECs in them that serve G.shdsl (I've been >> told that NEN does that) and for G.shdsl repeaters are part of the >> standard (searching around shows a few vendors making them); in the >> case of SDSL/2B1Q (Covad and DSL.net) there is no official support >> for repeaters and hence no major vendors making such, but I can build >> such a > repeater >> unofficially. >> >> The difficulty is with the political part, and that's where I'm > seeking >> the wisdom of this list. How would one go about sticking a mid-span >> repeater into an ILEC-owned 31 kft rural loop? From what I >> understand (someone please correct me if I'm wrong!), when a CLEC >> orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC >> actually orders a T1 or ISDN BRI transport from the ILEC rather than >> a dry pair, and any mid-span repeaters or HDSLx converters or the >> like become the responsibility of the ILEC rather than the CLEC, >> right? >> >> So how could one extend this model to provide, say, repeatered >> G.shdsl service to far-outlying rural subscribers? Is there some >> political process (PUC/FCC/etc) by which an ILEC could be forced to >> allow a > third >> party to stick a repeater in the middle of their loop? Or would it >> have to work by way of the ILEC providing a G.shdsl transport service >> to CLECs, with the ILEC being responsible for the selection, >> procurement and deployment of repeater hardware? And what if the >> ILEC is not interested in providing such a service - any PUC/FCC/etc >> political process via which they could be forced to cooperate? >> >> Things get even more complicated in those locations where the CO has >> a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving >> G.shdsl. Even if the ILEC were to provide a G.shdsl transport >> service with repeaters, it wouldn't help with SDSL/2B1Q. My idea >> involves building a gadget in the form factor of a standard mid-span >> repeater that would function as a converter from SDSL/2B1Q to >> G.shdsl: if the loop calls for one mid-span repeater, stick this >> gadget in as if it were that repeater; if the loop calls for 2 or >> more repeaters, use my gadget as the first "repeater" and then >> standard G.shdsl repeaters after it. But of course this idea is >> totally dependent on the ability of a third party to stick these >> devices in the middle of long rural loops, perhaps in the place of >> loading coils which are likely present on such loops. >> >> Any ideas? >> >> MS > > > From joelja at bogus.com Mon Mar 1 11:18:08 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 01 Mar 2010 09:18:08 -0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <4B8BF393.40808@cox.net> References: <4B8BE37F.8010705@tuenti.com> <4B8BF393.40808@cox.net> Message-ID: <4B8BF6D0.9000900@bogus.com> On 03/01/2010 09:04 AM, Larry Sheldon wrote: > On 3/1/2010 9:55 AM, Adam Waite wrote: >> >>> Hm, I was under the impression that ARPANET was a government run >>> network... >>> >>> >> Not since 1992......what you're looking for these days is NIPRnet and >> SIPRnet, and ESnet, etc, etc, etc. >> >> ARPANET only lives on in reverse dns..... > > And that is only the TLD label. > > Is there still a DARPANET, ARPANET's successor? On the us military side the successor to Arpanet was Milnet, NIPRnet, DDN etc. In some respects the modern analog is DREN ESNET and so on. > From bora at pnl.gov Mon Mar 1 19:34:01 2010 From: bora at pnl.gov (Akyol, Bora A) Date: Mon, 1 Mar 2010 17:34:01 -0800 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <1002270004.AA11084@ivan.Harhan.ORG> References: <1002270004.AA11084@ivan.Harhan.ORG> Message-ID: Michael I think for the people in the situation you are describing, the best bet would be one of the wireless technologies. Someone on the thread mentioned LTE (which should be coming out in a couple years time), and to that we can add WiMAX and even the 3G/3.5G HSPDA type wireless. The prices will not be USD19.99 but for less than USD70/month it is quite possible to get reasonable high speed Internet access. Will it be as fast as GigE to the house? No. But it will certainly support most web apps. The only challenge is that some of these wireless technologies still have much higher latency when compared to the wired DSL/cable modem links. Regards -----Original Message----- From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] Sent: Friday, February 26, 2010 4:05 PM To: nanog at nanog.org Subject: Re: Locations with no good Internet (was ISP in Johannesburg) Brandon Galbraith wrote: > http://www.rric.net/ I'm very familiar with those folks of course, they've been an inspiration to me for a long time. However, my needs are different. RRIC's model basically involves a specific community with a well-defined boundary: bring the bandwidth into the community via a bulk feed, then sublet inside the community. But I don't have a specific community in mind - I'm trying to develop a more generic solution. (The case of my friend who is at 31 kft from a Covad-enabled CO is only an example and nothing more.) Again, consider a town with a Covad-enabled CO plus an outlying countryside. The people in the town proper already have Covad xDSL available to them, and if we could stick my SDSL/2B1Q repeater in the middle of some longer loops, it would enable the people in the countryside to get *exactly the same* Covad (or ISP-X-via-Covad) services as those in the town proper. My repeater approach would also allow me to stay out of ISP or ISP-like business which I really don't want to get into - I would rather just make hardware and let someone else operate it. A repeater is totally unlike a router, it is not IP-aware, it just makes the loop seem shorter, allowing farther-outlying users to connect to *existing* ISPs with an already established business structure. Anyway, I just saw a post on NANOG about an area deprived of "high-speed Internet" services and thought I would post my idea in the hope that someone would have some ideas that would actually be *helpful* to what I'm trying to do. If not - oh well, I'll just put the idea back on the dusty shelf in the back of my mind until I'm ready to try presenting it to the folks who own the CO-colocated DSLAMs it would have to work with - gotta finish a few other things before I open that can of worms in the earnest. MS From mjkelly at gmail.com Mon Mar 1 20:45:28 2010 From: mjkelly at gmail.com (Matt Kelly) Date: Mon, 1 Mar 2010 21:45:28 -0500 Subject: hotmail help Message-ID: <43AE4319-35D0-4055-AC32-F0E99D241967@gmail.com> Anyone from hotmail on the list that can contact me please? We're having a widespread issue. Thanks. -- Matt From jared at puck.nether.net Mon Mar 1 21:03:51 2010 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 1 Mar 2010 22:03:51 -0500 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: References: <1002270004.AA11084@ivan.Harhan.ORG> Message-ID: <0759CC34-F108-418A-90DE-8067AB91F029@puck.nether.net> On Mar 1, 2010, at 8:34 PM, Akyol, Bora A wrote: > Michael > > I think for the people in the situation you are describing, the best bet would be > one of the wireless technologies. Someone on the thread mentioned LTE (which should > be coming out in a couple years time), and to that we can add WiMAX and > even the 3G/3.5G HSPDA type wireless. The prices will not be USD19.99 but for > less than USD70/month it is quite possible to get reasonable high speed Internet > access. Will it be as fast as GigE to the house? No. But it will certainly support > most web apps. The only challenge is that some of these wireless technologies still have > much higher latency when compared to the wired DSL/cable modem links. Some of the WISP hardware is getting "cheap". It's no longer $500 NIUs, you can get something that can go a fair distance at high speeds for ~$80. http://www.ubnt.com/products/nanobridge.php You can find used microwave (unlicensed & licensed) equipment "cheap" as well. ($1-2k per pair/hop). The FTTH equipment is ~$600 for 20km reach @ 1Gb/s. Life is getting interesting these days.. I'm seeing interest in solving this last mile issue, but I suspect some networks will eventually be forced to abandon their DSL strategy (ATT, Qwest) before too long. They are going to start to lose out to the competitors. Verizon seems to be the only (large) US based provider with a decent strategy. I'm expecting regulatory intervention in the next few years to actually require universal broadband access from the iLECs, and the only way to reach these further distances is with FTTH gear (cost effectively). I have wondered, how many POTS lines do I need to order to get them to build fiber/access to me. Anyone have guesses/data? - Jared From shon at unwiredbb.com Mon Mar 1 21:57:14 2010 From: shon at unwiredbb.com (Shon Elliott) Date: Mon, 01 Mar 2010 19:57:14 -0800 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <0759CC34-F108-418A-90DE-8067AB91F029@puck.nether.net> References: <1002270004.AA11084@ivan.Harhan.ORG> <0759CC34-F108-418A-90DE-8067AB91F029@puck.nether.net> Message-ID: <4B8C8C9A.8010707@unwiredbb.com> Hmm... unless I'm completely off, 1,080. About enough for a DS3. Maybe half of a DS3.. as long as it overreaches their T1 or HDSL capacity. It seems that while DS3 is a copper product, it's typically delivered to the site broken off of a fiber node. Wouldn't want to see the installation bill of that, though. That's been my experience of AT&T here in California. -S Jared Mauch wrote: > On Mar 1, 2010, at 8:34 PM, Akyol, Bora A wrote: > >> Michael >> >> I think for the people in the situation you are describing, the best bet would be >> one of the wireless technologies. Someone on the thread mentioned LTE (which should >> be coming out in a couple years time), and to that we can add WiMAX and >> even the 3G/3.5G HSPDA type wireless. The prices will not be USD19.99 but for >> less than USD70/month it is quite possible to get reasonable high speed Internet >> access. Will it be as fast as GigE to the house? No. But it will certainly support >> most web apps. The only challenge is that some of these wireless technologies still have >> much higher latency when compared to the wired DSL/cable modem links. > > Some of the WISP hardware is getting "cheap". It's no longer $500 NIUs, you can get something that can go a fair distance at high speeds for ~$80. > > http://www.ubnt.com/products/nanobridge.php > > You can find used microwave (unlicensed & licensed) equipment "cheap" as well. ($1-2k per pair/hop). > > The FTTH equipment is ~$600 for 20km reach @ 1Gb/s. > > Life is getting interesting these days.. I'm seeing interest in solving this last mile issue, but I suspect some networks will eventually be forced to abandon their DSL strategy (ATT, Qwest) before too long. They are going to start to lose out to the competitors. Verizon seems to be the only (large) US based provider with a decent strategy. > > I'm expecting regulatory intervention in the next few years to actually require universal broadband access from the iLECs, and the only way to reach these further distances is with FTTH gear (cost effectively). > > I have wondered, how many POTS lines do I need to order to get them to build fiber/access to me. Anyone have guesses/data? > > - Jared > From joelja at bogus.com Tue Mar 2 00:41:58 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 01 Mar 2010 22:41:58 -0800 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: References: <1002270004.AA11084@ivan.Harhan.ORG> Message-ID: <4B8CB336.1060706@bogus.com> On 03/01/2010 05:34 PM, Akyol, Bora A wrote: > Michael > > I think for the people in the situation you are describing, the best bet would be > one of the wireless technologies. Someone on the thread mentioned LTE (which should > be coming out in a couple years time), and to that we can add WiMAX and > even the 3G/3.5G HSPDA type wireless. The prices will not be USD19.99 but for > less than USD70/month it is quite possible to get reasonable high speed Internet > access. Will it be as fast as GigE to the house? No. But it will certainly support > most web apps. The only challenge is that some of these wireless technologies still have > much higher latency when compared to the wired DSL/cable modem links. point-to-point and ptmp 802.11phy derived tdm gear has been outperforming cellular access layers on the throughput and cost equations for a number of years. The choice of frequencies and licensed vs unlicensed operation continues to proliferate as the radios get more flexible and cheaper... see for one ptp backkhul example: http://www.ubnt.com/nanobridge It is now possible to put together a passable community or wisp network for what essentially is microcap money. Unlike rural electrification or rural ftfth the prospects of doing such a deployment for the low hundreds of dollars per household in aggregate are not hard to imagine. As far as I'm concerned someone else with capital can solve the mobility problem, the fixed wireless problem can be addressed in many cases with sound engineering, sweat equitity, community involvement and a little capital. If a technology can connect a bunch of ngo's in haiti or connect transponder sites for hf radio relays in New Guinea it ought to work in the less developed parts of the developed world. > Regards > > > -----Original Message----- > From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] > Sent: Friday, February 26, 2010 4:05 PM > To: nanog at nanog.org > Subject: Re: Locations with no good Internet (was ISP in Johannesburg) > > Brandon Galbraith wrote: > >> http://www.rric.net/ > > I'm very familiar with those folks of course, they've been an inspiration > to me for a long time. > > However, my needs are different. RRIC's model basically involves a > specific community with a well-defined boundary: bring the bandwidth > into the community via a bulk feed, then sublet inside the community. > > But I don't have a specific community in mind - I'm trying to develop a > more generic solution. (The case of my friend who is at 31 kft from a > Covad-enabled CO is only an example and nothing more.) Again, consider > a town with a Covad-enabled CO plus an outlying countryside. The people > in the town proper already have Covad xDSL available to them, and if we > could stick my SDSL/2B1Q repeater in the middle of some longer loops, it > would enable the people in the countryside to get *exactly the same* > Covad (or ISP-X-via-Covad) services as those in the town proper. > > My repeater approach would also allow me to stay out of ISP or ISP-like > business which I really don't want to get into - I would rather just > make hardware and let someone else operate it. A repeater is totally > unlike a router, it is not IP-aware, it just makes the loop seem shorter, > allowing farther-outlying users to connect to *existing* ISPs with an > already established business structure. > > Anyway, I just saw a post on NANOG about an area deprived of "high-speed > Internet" services and thought I would post my idea in the hope that > someone would have some ideas that would actually be *helpful* to what > I'm trying to do. If not - oh well, I'll just put the idea back on the > dusty shelf in the back of my mind until I'm ready to try presenting it > to the folks who own the CO-colocated DSLAMs it would have to work with > - gotta finish a few other things before I open that can of worms in the > earnest. > > MS > > From johnmusbach1 at gmail.com Tue Mar 2 01:17:34 2010 From: johnmusbach1 at gmail.com (John Musbach) Date: Tue, 2 Mar 2010 02:17:34 -0500 Subject: NANOG Digest, Vol 26, Issue 6 In-Reply-To: References: Message-ID: <17c8e29e1003012317i39f9523ei3187d7b6b29f3f6@mail.gmail.com> Unsubscribe. On 3/1/10, nanog-request at nanog.org wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 > Group (fwd) (Antonio Querubin) > 2. Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 > Group (fwd) (Larry Sheldon) > 3. Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 > Group (fwd) (Kevin Oberman) > 4. Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 > Group (fwd) (Kevin Oberman) > 5. RE: Locations with no good Internet (was ISP in Johannesburg) > (Warren Bailey) > 6. Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 > Group (fwd) (Joel Jaeggli) > 7. RE: Locations with no good Internet (was ISP in Johannesburg) > (Akyol, Bora A) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 1 Mar 2010 09:12:58 -1000 (HST) > From: "Antonio Querubin" > Subject: Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 > Group (fwd) > To: > Cc: lir at uralttk.ru, nanog at nanog.org, members-discuss at ripe.net > Message-ID: > Content-Type: TEXT/PLAIN; format=flowed; charset="US-ASCII" > > On Tue, 2 Mar 2010, Owen DeLong wrote: > >> On Mar 1, 2010, at 11:55 PM, Adam Waite wrote: > >>> Not since 1992......what you're looking for these days is NIPRnet and >>> SIPRnet, and ESnet, etc, etc, etc. > >> Um, actually, I would say that in all of those cases, including ARPANET >> when it existed, you are >> dealing with a government sponsored network rather than a government run >> network. >> >> Generally, in each of those cases, the government provides some or all of >> the money to keep >> the network going, but, has very little to do with dictating policy or >> operational aspects of the >> network. > > I think DISA and DoD would argue about that claim with regard to NIPRNet > and SIPRNet :) > > Antonio Querubin > 808-545-5282 x3003 > e-mail/xmpp: tony at lava.net > > > > > ------------------------------ > > Message: 2 > Date: Mon, 01 Mar 2010 14:09:51 -0600 > From: Larry Sheldon > Subject: Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 > Group (fwd) > Cc: nanog at nanog.org > Message-ID: <4B8C1F0F.6080102 at cox.net> > Content-Type: text/plain; charset=ISO-8859-1 > > On 3/1/2010 12:53 PM, Steven M. Bellovin wrote: >> On Mon, 01 Mar 2010 11:04:19 -0600 >> Larry Sheldon wrote: >> >>> On 3/1/2010 9:55 AM, Adam Waite wrote: >>>> >>>>> Hm, I was under the impression that ARPANET was a government run >>>>> network... >>>>> >>>>> >>>> Not since 1992......what you're looking for these days is NIPRnet >>>> and SIPRnet, and ESnet, etc, etc, etc. >>>> >>>> ARPANET only lives on in reverse dns..... >>> >>> And that is only the TLD label. >>> >>> Is there still a DARPANET, ARPANET's successor? >>> >>> >> Depends on what you mean. > > I meant "is there still a DARPAnet" separate and apart from its progeny, > fragments, and follow-ons. > -- > "Government big enough to supply everything you need is big enough to > take everything you have." > > Remember: The Ark was built by amateurs, the Titanic by professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > > > ------------------------------ > > Message: 3 > Date: Mon, 01 Mar 2010 13:30:24 -0800 > From: "Kevin Oberman" > Subject: Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 > Group (fwd) > To: Adam Waite > Cc: nanog at nanog.org, lir at uralttk.ru, members-discuss at ripe.net > Message-ID: <20100301213024.597291CC13 at ptavv.es.net> > >> Date: Mon, 01 Mar 2010 16:55:43 +0100 >> From: Adam Waite >> >> >> > Hm, I was under the impression that ARPANET was a government run >> > network... >> > >> > >> Not since 1992......what you're looking for these days is NIPRnet and >> SIPRnet, and ESnet, etc, etc, etc. > > While ESnet is funded by the Department of Energy and they certainly > define the strategic policy of ESnet, they don't make design decisions > nor get involved with the technical end of the network. > > ESnet is run by the University of California's Berkeley Lab under > contract to the DOE. This may sound like hair splitting, but it is > really very different from Fednets like NIPR and SIPR (and many, many > others) including the Department of Energy's own DOEnet. Note that > DOEnet is used for DOE business operations while ESnet is use support > DOE funded research. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > > > > ------------------------------ > > Message: 4 > Date: Mon, 01 Mar 2010 13:30:24 -0800 > From: "Kevin Oberman" > Subject: Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 > Group (fwd) > To: > Cc: nanog at nanog.org, lir at uralttk.ru, members-discuss at ripe.net > Message-ID: <20100301213024.597291CC13 at ptavv.es.net> > >> Date: Mon, 01 Mar 2010 16:55:43 +0100 >> From: Adam Waite >> >> >> > Hm, I was under the impression that ARPANET was a government run >> > network... >> > >> > >> Not since 1992......what you're looking for these days is NIPRnet and >> SIPRnet, and ESnet, etc, etc, etc. > > While ESnet is funded by the Department of Energy and they certainly > define the strategic policy of ESnet, they don't make design decisions > nor get involved with the technical end of the network. > > ESnet is run by the University of California's Berkeley Lab under > contract to the DOE. This may sound like hair splitting, but it is > really very different from Fednets like NIPR and SIPR (and many, many > others) including the Department of Energy's own DOEnet. Note that > DOEnet is used for DOE business operations while ESnet is use support > DOE funded research. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > > > > > > ------------------------------ > > Message: 5 > Date: Mon, 1 Mar 2010 15:19:38 -0900 > From: Warren Bailey > Subject: RE: Locations with no good Internet (was ISP in Johannesburg) > To: Daniel Senie , NANOG list > Message-ID: > <5B3743FC2D0D8B41B27EE4F5EACA79D10D23C143 at DTN1EX01.gci.com> > Content-Type: text/plain; charset="us-ascii" > > How do you think we feel in Alaska. Until mid last year, most cellular > BTS were backhauled via DS1. Only Within the last 12 months have we > (insert obligatory "I work for a GSM and CDMA cellular provider serving > most of Alaska") even migrated from Local copper to fiber or air > interfaces (ds1/ds3 microwave). > > I've always been curious as to why the people who aren't being served > with "broadband" type of services haven't made a larger fuss about this. > The idea of running a copper pair to a home should have died long ago, > IMHO. As an RF Engineer, I see everyone turning to fiber and dry loops > when it's just not necessary or even cost effective. Put up the > *LICENSED* loop and call it a day.. Or a 5.8 RAD shot when you feel like > rolling the deice. Either way, cellular isn't the drop dead answer to > solving a sparsely covered area. > > About 95% of my state is not covered by cellular, but we've had no > problems deploying the largest cellular (rural obviously) provider in > the United States - just look up. It's not as expensive as you would > think. > > > //warren > > Warren Bailey > GCI Communication Corp. > RF Network Engineering > 907.868.5911 office > 907.903.5410 mobile > > > -----Original Message----- > From: Daniel Senie [mailto:dts at senie.com] > Sent: Friday, February 26, 2010 3:21 PM > To: NANOG list > Subject: Re: Locations with no good Internet (was ISP in Johannesburg) > > Hopefully someone will bother to cover the rural areas with cell service > eventually. > > Much of western Massachusetts (by which I mean the Berkshires, more than > I mean the Pioneer Valley) is not covered by cell service. Where there > is cell service, most cell sites have only minimal data speeds. Vermont > is far worse, as is much of Maine. If there were 3G cellular, it'd be a > big step up. But I expect the inner cities will all be running LTE for > years before more rural areas even get voice service. > > On Feb 26, 2010, at 6:04 PM, Haney, Wilson wrote: > >> As we all know it's expensive building out any landline network. Rural > areas just get over looked. >> >> Check out this tech coming out of Motorola and to a Verizon/ATT tower > near you soon. >> >> 100 Mbps possible off cellular signals. Looks like they will throttle > it to 20 Mbps and less though. >> >> http://business.motorola.com/experiencelte/lte-depth.html >> >> http://news.techworld.com/networking/3203498/motorola-predicts-20mbps- >> download-speed-with-future-lte-networks/ >> >> WPH >> >> -----Original Message----- >> From: Crooks, Sam [mailto:Sam.Crooks at experian.com] >> Sent: Friday, February 26, 2010 4:51 PM >> To: Michael Sokolov; nanog at nanog.org >> Subject: RE: Locations with no good Internet (was ISP in Johannesburg) >> >> I had good luck getting my dad some form of broadband access in rural >> Oregon using a 3g router (Cradlepoint), a Wilson Electronics signal >> amp (model 811211), and an outdoor mount high gain antenna. It's not >> great, but considering the alternatives (33.6k dialup for $60/mo or >> satellite broadband for $150-$200/mo) it wasn't a bad deal for my dad >> when you consider that the dialup ISP + dedicated POTS line cost about > >> as much as the 5GB 3G data plan does. >> >> Speed is somewhere between dialup and Uverse or FIOS. I get the >> sense that it is somewhere in the range of 256 - 512 kbps with high >> latency (Dad's not one for much in the way of network performance > testing). >> >> >> >>> -----Original Message----- >>> From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] >>> Sent: Friday, February 26, 2010 3:35 PM >>> To: nanog at nanog.org >>> Subject: Locations with no good Internet (was ISP in Johannesburg) >>> >>> Daniel Senie wrote: >>> >>>> Better than western Massachusetts, where there's just no >> connectivity >>> at = >>>> all. Even dialup fails to function over crappy lines. >>> >>> Hmm. Although I've never been to Western MA and hence have no idea >>> what the telecom situation is like over there, I'm certainly aware of > >>> quite a few places in "first world USA" where DSL is still a fantasy, > >>> let >> alone >>> fiber. >>> >>> As a local example, I have a friend in a rural area of Southern >>> California who can't get any kind of "high-speed Internet". I've run >> a >>> prequal on her address and it tells me she is 31 kft from the CO. >>> The CO in question has a Covad DSLAM in it, but at 31 kft those rural > >>> residents' options are limited to either IDSL at 144 kbps (not much >>> point in that) or a T1 starting at ~$700/month. The latter figure is > >>> typically well out of range for the kind of people who live in such >>> places. >>> >>> That got me thinking: ISDN/IDSL and T1 can be extended infinitely far > >>> into the boondocks because those signal formats support repeaters. >>> What >>> I'm wondering is how can we do the same thing with SDSL - and I mean >>> politically rather than technically. The technical part is easy: >>> some COs already have CLECs in them that serve G.shdsl (I've been >>> told that NEN does that) and for G.shdsl repeaters are part of the >>> standard (searching around shows a few vendors making them); in the >>> case of SDSL/2B1Q (Covad and DSL.net) there is no official support >>> for repeaters and hence no major vendors making such, but I can build > >>> such a >> repeater >>> unofficially. >>> >>> The difficulty is with the political part, and that's where I'm >> seeking >>> the wisdom of this list. How would one go about sticking a mid-span >>> repeater into an ILEC-owned 31 kft rural loop? From what I >>> understand (someone please correct me if I'm wrong!), when a CLEC >>> orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC >>> actually orders a T1 or ISDN BRI transport from the ILEC rather than >>> a dry pair, and any mid-span repeaters or HDSLx converters or the >>> like become the responsibility of the ILEC rather than the CLEC, >>> right? >>> >>> So how could one extend this model to provide, say, repeatered >>> G.shdsl service to far-outlying rural subscribers? Is there some >>> political process (PUC/FCC/etc) by which an ILEC could be forced to >>> allow a >> third >>> party to stick a repeater in the middle of their loop? Or would it >>> have to work by way of the ILEC providing a G.shdsl transport service > >>> to CLECs, with the ILEC being responsible for the selection, >>> procurement and deployment of repeater hardware? And what if the >>> ILEC is not interested in providing such a service - any PUC/FCC/etc >>> political process via which they could be forced to cooperate? >>> >>> Things get even more complicated in those locations where the CO has >>> a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving >>> G.shdsl. Even if the ILEC were to provide a G.shdsl transport >>> service with repeaters, it wouldn't help with SDSL/2B1Q. My idea >>> involves building a gadget in the form factor of a standard mid-span >>> repeater that would function as a converter from SDSL/2B1Q to >>> G.shdsl: if the loop calls for one mid-span repeater, stick this >>> gadget in as if it were that repeater; if the loop calls for 2 or >>> more repeaters, use my gadget as the first "repeater" and then >>> standard G.shdsl repeaters after it. But of course this idea is >>> totally dependent on the ability of a third party to stick these >>> devices in the middle of long rural loops, perhaps in the place of >>> loading coils which are likely present on such loops. >>> >>> Any ideas? >>> >>> MS >> >> >> > > > > > > ------------------------------ > > Message: 6 > Date: Mon, 01 Mar 2010 09:18:08 -0800 > From: Joel Jaeggli > Subject: Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 > Group (fwd) > To: Larry Sheldon > Cc: nanog at nanog.org > Message-ID: <4B8BF6D0.9000900 at bogus.com> > Content-Type: text/plain; charset=UTF-8 > > > > On 03/01/2010 09:04 AM, Larry Sheldon wrote: >> On 3/1/2010 9:55 AM, Adam Waite wrote: >>> >>>> Hm, I was under the impression that ARPANET was a government run >>>> network... >>>> >>>> >>> Not since 1992......what you're looking for these days is NIPRnet and >>> SIPRnet, and ESnet, etc, etc, etc. >>> >>> ARPANET only lives on in reverse dns..... >> >> And that is only the TLD label. >> >> Is there still a DARPANET, ARPANET's successor? > > On the us military side the successor to Arpanet was Milnet, NIPRnet, > DDN etc. > > In some respects the modern analog is DREN ESNET and so on. > >> > > > > ------------------------------ > > Message: 7 > Date: Mon, 1 Mar 2010 17:34:01 -0800 > From: "Akyol, Bora A" > Subject: RE: Locations with no good Internet (was ISP in Johannesburg) > To: 'Michael Sokolov' , "nanog at nanog.org" > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Michael > > I think for the people in the situation you are describing, the best bet > would be > one of the wireless technologies. Someone on the thread mentioned LTE (which > should > be coming out in a couple years time), and to that we can add WiMAX and > even the 3G/3.5G HSPDA type wireless. The prices will not be USD19.99 but > for > less than USD70/month it is quite possible to get reasonable high speed > Internet > access. Will it be as fast as GigE to the house? No. But it will certainly > support > most web apps. The only challenge is that some of these wireless > technologies still have > much higher latency when compared to the wired DSL/cable modem links. > > Regards > > > -----Original Message----- > From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] > Sent: Friday, February 26, 2010 4:05 PM > To: nanog at nanog.org > Subject: Re: Locations with no good Internet (was ISP in Johannesburg) > > Brandon Galbraith wrote: > >> http://www.rric.net/ > > I'm very familiar with those folks of course, they've been an inspiration > to me for a long time. > > However, my needs are different. RRIC's model basically involves a > specific community with a well-defined boundary: bring the bandwidth > into the community via a bulk feed, then sublet inside the community. > > But I don't have a specific community in mind - I'm trying to develop a > more generic solution. (The case of my friend who is at 31 kft from a > Covad-enabled CO is only an example and nothing more.) Again, consider > a town with a Covad-enabled CO plus an outlying countryside. The people > in the town proper already have Covad xDSL available to them, and if we > could stick my SDSL/2B1Q repeater in the middle of some longer loops, it > would enable the people in the countryside to get *exactly the same* > Covad (or ISP-X-via-Covad) services as those in the town proper. > > My repeater approach would also allow me to stay out of ISP or ISP-like > business which I really don't want to get into - I would rather just > make hardware and let someone else operate it. A repeater is totally > unlike a router, it is not IP-aware, it just makes the loop seem shorter, > allowing farther-outlying users to connect to *existing* ISPs with an > already established business structure. > > Anyway, I just saw a post on NANOG about an area deprived of "high-speed > Internet" services and thought I would post my idea in the hope that > someone would have some ideas that would actually be *helpful* to what > I'm trying to do. If not - oh well, I'll just put the idea back on the > dusty shelf in the back of my mind until I'm ready to try presenting it > to the folks who own the CO-colocated DSLAMs it would have to work with > - gotta finish a few other things before I open that can of worms in the > earnest. > > MS > > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 26, Issue 6 > ************************************ > -- Best Regards, John Musbach From jmamodio at gmail.com Mon Mar 1 10:08:10 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 1 Mar 2010 10:08:10 -0600 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <4B8843F4.9070108@foobar.org> <18a5e7cb1002261459p2ef6ac14leb86ab384337c148@mail.gmail.com> <4B8B9FD0.4010302@nosignal.org> <4B8BCA2D.3000505@nosignal.org> Message-ID: <202705b1003010808g42807573m7e45561c9ec9c0a2@mail.gmail.com> > But anyhow, don't get me wrong. I agree with all that has been said on > why and how ITU is trying to get a grip on packet switched communication > networks. My only point it that it might not be a bad idea to ponder on > the subject of allowing competition between RIR's in the same > geographical aerea and hence allow ITU to achieve the status of > nationwide RIR. That will be an extremely bad idea. ITU is aspiring to be a global RIR. Once upon a time since the network architecture/protocols/technology required the assignment/allocation of particular object identifiers that must be globally unique we had Jon Postel's authoritative notepad that later assumed the IANA name and became institutionalized as ICANNzilla. On the address space IANA delegates part of its authority to regional registries and even when there are some common practices and guidelines/policies, each registry establishes its own policies via a bottom-up policy development process for address allocation and how to deal with issues associated with this practice. Since there are requirements/policies associated, each RIR indirectly acts as a soft "regulator" by applying the terms and conditions and collecting fees. It is not a perfect "system" and if something is wrong with a particular RIR or policy that is what needs to be fixed, not create an alternative channel that intends to override the existing "authority" delegation tree by developing its own policies and trying to enforce them through national governments telecom regulations, which imho is what ITU is attempting to do. Basic example (bah very stupid one), Johnny SPAM-BoTnEt on country XX wants IP address space for his operations that in XX-land may not be considered illegal, when service providers direct him to the appropriate RIR there is a chance that the RIR will give a hard time to Johnny to get his address space due the obscurity of his operations that may be illegal in other countries within the region. Then Johnny will go to King of XX who will call his nephew at ITU to get the address space for poor Johnny. Not good. -J ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From awaite at tuenti.com Mon Mar 1 09:55:43 2010 From: awaite at tuenti.com (Adam Waite) Date: Mon, 01 Mar 2010 16:55:43 +0100 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: References: Message-ID: <4B8BE37F.8010705@tuenti.com> > Hm, I was under the impression that ARPANET was a government run > network... > > Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. ARPANET only lives on in reverse dns..... ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From drc at virtualized.org Mon Mar 1 10:59:13 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 1 Mar 2010 08:59:13 -0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: References: Message-ID: On Mar 1, 2010, at 7:42 AM, Arjan van der Oest wrote: >> keep in mind, most telcos and ISPs (the founders and members of the >> current IANA -> RIRS -> LIRs model resulting in a global internet which is >> hard to censor) do not agree on this ITU proposal... > > I wonder who those ITU members are then? Are those all currently > non-internet-offering telco's? Government departments/ministries? Even in the case of sector members, the folks who attend ITU generally are not the folks who attend RIR/NANOG meetings. > Not comparing this to the former-DDR or Chinese situation (please refer > to my tin-foil remark above) a per-country specific prefix is not > necessarily a bad thing and may even have an upside. There are, of course, plusses and minuses to country based allocations. On the plus side, it makes geo-location easier. On the minus side, it makes geo-location easier. It would also likely increase the number of routing prefixes announced by multi-nationals (not that this matters all that much in the grand scheme of things). It may also greatly simplify a return to the settlements-based regime that was the norm before around 1996 or so. However, I suspect the biggest change is that the moves where address policy is made away from the folks who are directly impacted by that policy (ISPs) to governments/PTTs. Please read some of the contributions at http://www.itu.int/net/ITU-T/ipv6/itudocs.aspx and determine for yourself whether you think they would make good policies. >> In order to accomplish that they want to create their own address >> registry, for now "secondary" to the ISP/telco run bottom-down RIR system >> (RIPE,ARIN,APNIC,AFRINIC,APNIC) but ofcourse we can't expect it to take >> long before repressive governments start to force "the internets" "in >> their country" to use only the ITU registry... > > Why? Because they are repressive? > Now let's stop folding tin hats. It has been noted in the past that you're not necessarily paranoid if they really are out to get you. Regards, -drc ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From Valdis.Kletnieks at vt.edu Mon Mar 1 11:25:31 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 01 Mar 2010 12:25:31 -0500 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: Your message of "Mon, 01 Mar 2010 16:42:15 +0100." References: Message-ID: <10497.1267464331@localhost> On Mon, 01 Mar 2010 16:42:15 +0100, Arjan van der Oest said: > > (considering the fact that governments themselves are not capable of > >running anything but a gray-cheese-with-a-dial telephone network > > Hm, I was under the impression that ARPANET was a government run > network... I would not be surprised if some of the bigger providers now have bigger networks in their test labs than the ARPANET/MILNET combo was - ISTR it was on the order of 4,000 total nodes in the 1984 era. I remember being surprised when my then-current employer joined both networks that the 3,000+ nodes on Bitnet and the size of the Arpa/Mil aggregate being comparable (and Bitnet may have been even bigger at some points). And let's face it - the Arpa/Milnet was a test network, not a production network. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ron at nosc.mil Mon Mar 1 11:49:50 2010 From: ron at nosc.mil (Ron Broersma) Date: Mon, 1 Mar 2010 09:49:50 -0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <10497.1267464331@localhost> References: <10497.1267464331@localhost> Message-ID: On Mar 1, 2010, at 9:25 AM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 01 Mar 2010 16:42:15 +0100, Arjan van der Oest said: > >>> (considering the fact that governments themselves are not capable of >>> running anything but a gray-cheese-with-a-dial telephone network >> >> Hm, I was under the impression that ARPANET was a government run >> network... > > And let's face it - the Arpa/Milnet was a test network, not a production > network. It may have started as a research network, but was very much used for production activities by late 70's and early 80's. --Ron (Site coordinator for Arpanet IMP #3) ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From owen at delong.com Mon Mar 1 12:42:52 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Mar 2010 02:42:52 +0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <4B8BE37F.8010705@tuenti.com> References: <4B8BE37F.8010705@tuenti.com> Message-ID: <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> On Mar 1, 2010, at 11:55 PM, Adam Waite wrote: > >> Hm, I was under the impression that ARPANET was a government run >> network... >> >> > Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. > > ARPANET only lives on in reverse dns..... > > Um, actually, I would say that in all of those cases, including ARPANET when it existed, you are dealing with a government sponsored network rather than a government run network. Generally, in each of those cases, the government provides some or all of the money to keep the network going, but, has very little to do with dictating policy or operational aspects of the network. Owen ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From owen at delong.com Mon Mar 1 12:40:22 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Mar 2010 02:40:22 +0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: References: Message-ID: <541B85C5-1FB0-4D20-B62A-15D4222E4E78@delong.com> On Mar 1, 2010, at 11:42 PM, Arjan van der Oest wrote: > CB3ROB scribbled: > >> let the riots commence 2.0.... > > Oh dear oh dear... > >> keep in mind, most telcos and ISPs (the founders and members of the >> current IANA -> RIRS -> LIRs model resulting in a global internet which > is >> hard to censor) do not agree on this ITU proposal... > > I wonder who those ITU members are then? Are those all currently > non-internet-offering telco's? > The voting members of the ITU are national governments. The telcos get to speak at some ITU sessions and get to attend most of them, but, they don't generally get to vote as I understand it. >> If we allow them to go forward, this WILL result in a "per country" >> easy-to-filter internet in a few years when ipv6 is the only serious >> protocol left. > > /me hands CB3ROB some tinfoil and mumbles : "believers, start your > FOLDING!" > >> we only need to point out how easy it was for the DDR to simply route >> all phonecalls to "the west" through a room where people monitored >> telephone conversations, and this "country specific prefix" is just > what >> the ITU seems to want for the internet. > > Not comparing this to the former-DDR or Chinese situation (please refer > to my tin-foil remark above) a per-country specific prefix is not > necessarily a bad thing and may even have an upside. > Care to explain what that could possibly be? (I simply don't see an upside to making it easy to censor the internet by national identity). >> In order to accomplish that they want to create their own address >> registry, for now "secondary" to the ISP/telco run bottom-down RIR > system >> (RIPE,ARIN,APNIC,AFRINIC,APNIC) but ofcourse we can't expect it to > take >> long before repressive governments start to force "the internets" "in >> their country" to use only the ITU registry... > > Why? > Because such is the nature of repressive governments? >> now -we- can always move our office to some other country and take our > tax >> money to some other resort, not a biggie, but don't come complaining > to me >> when germany at some point uses this to build their own chinese bigass > >> golden firewall with flames coming out of its ass to make it faster. > > Sven, I think several less-democratic nations have already proven that > if they require total control of the internet within the boundaries of > their country (sic) they can and will implement this anyhow. They don't > require ITU nor the UN for this. They will just demand Cisco and Google > to implement it and the corporate chiefs will just answer "How soon?"... > In fact, so far, said countries have had only minimal success with this approach. Look at the tunneling out of Iran during the recent events and the amount of "unauthorized" information which made it out to the world via the internet. In general, the current internet regards censorship as damage and routes around it. Giving repressive regimes the ability to know that all the addresses they want to allow to communicate are in a defined prefix would make effective censorship much easier and make working around that problem much harder. In spite of this fact, that is not the primary reason to oppose the ITU proposal. Competing Internet Registry structures where one structure is not bound by the stratagems of RFC-2050, or, for that matter, any form of policy other than what each national IR chooses to implement is a recipe for disaster in address policy. Imagine, for example, what happens when $NATION decides that spammers are a good source of revenue and starts selling them rotating address chunks for a fee. Pretty soon, the IPv6 address space could end up looking like the island of Nauru. (http://www.lawanddevelopment.org/docs/nauru.pdf) > >> (considering the fact that governments themselves are not capable of >> running anything but a gray-cheese-with-a-dial telephone network > > Hm, I was under the impression that ARPANET was a government run > network... > No, ARPANET was a government sponsored network run by researchers. The fact that it is a cooperative anarchy rather than a highly structured centralized management structure pretty much proves that although the government funded it and pointed in a vague development direction, they had little to do with the implementation details and even less to do with the operational details. >> they need us, we don't need them > > If they install legislation that forbids anyone without a license to run > a telecommunications network of ANY kind, surely you need them, with or > without ITU and/or RIR's. > And yet so long as a given country has at least one licensed carrier doing some level of international IP based services it becomes almost impossible to inflict deeper policy on what use those IP based services are put to. OTOH, a wide-spread crackdown of national control over prefix distribution could make that much worse. Owen From tony at lava.net Mon Mar 1 13:12:58 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 1 Mar 2010 09:12:58 -1000 (HST) Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> References: <4B8BE37F.8010705@tuenti.com> <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> Message-ID: On Tue, 2 Mar 2010, Owen DeLong wrote: > On Mar 1, 2010, at 11:55 PM, Adam Waite wrote: >> Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. > Um, actually, I would say that in all of those cases, including ARPANET when it existed, you are > dealing with a government sponsored network rather than a government run network. > > Generally, in each of those cases, the government provides some or all of the money to keep > the network going, but, has very little to do with dictating policy or operational aspects of the > network. I think DISA and DoD would argue about that claim with regard to NIPRNet and SIPRNet :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From owen at delong.com Mon Mar 1 12:42:52 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Mar 2010 02:42:52 +0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <4B8BE37F.8010705@tuenti.com> References: <4B8BE37F.8010705@tuenti.com> Message-ID: <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> On Mar 1, 2010, at 11:55 PM, Adam Waite wrote: > >> Hm, I was under the impression that ARPANET was a government run >> network... >> >> > Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. > > ARPANET only lives on in reverse dns..... > > Um, actually, I would say that in all of those cases, including ARPANET when it existed, you are dealing with a government sponsored network rather than a government run network. Generally, in each of those cases, the government provides some or all of the money to keep the network going, but, has very little to do with dictating policy or operational aspects of the network. Owen ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From tony at lava.net Mon Mar 1 13:12:58 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 1 Mar 2010 09:12:58 -1000 (HST) Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> References: <4B8BE37F.8010705@tuenti.com> <480CA8B6-D640-44D6-8870-2CC262C75F57@delong.com> Message-ID: On Tue, 2 Mar 2010, Owen DeLong wrote: > On Mar 1, 2010, at 11:55 PM, Adam Waite wrote: >> Not since 1992......what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. > Um, actually, I would say that in all of those cases, including ARPANET when it existed, you are > dealing with a government sponsored network rather than a government run network. > > Generally, in each of those cases, the government provides some or all of the money to keep > the network going, but, has very little to do with dictating policy or operational aspects of the > network. I think DISA and DoD would argue about that claim with regard to NIPRNet and SIPRNet :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From oberman at es.net Mon Mar 1 15:30:24 2010 From: oberman at es.net (Kevin Oberman) Date: Mon, 01 Mar 2010 13:30:24 -0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: Your message of "Mon, 01 Mar 2010 16:55:43 +0100." <4B8BE37F.8010705@tuenti.com> Message-ID: <20100301213024.597291CC13@ptavv.es.net> > Date: Mon, 01 Mar 2010 16:55:43 +0100 > From: Adam Waite > > > > Hm, I was under the impression that ARPANET was a government run > > network... > > > > > Not since 1992......what you're looking for these days is NIPRnet and > SIPRnet, and ESnet, etc, etc, etc. While ESnet is funded by the Department of Energy and they certainly define the strategic policy of ESnet, they don't make design decisions nor get involved with the technical end of the network. ESnet is run by the University of California's Berkeley Lab under contract to the DOE. This may sound like hair splitting, but it is really very different from Fednets like NIPR and SIPR (and many, many others) including the Department of Energy's own DOEnet. Note that DOEnet is used for DOE business operations while ESnet is use support DOE funded research. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From yoshida at nttv6.jp Tue Mar 2 01:59:35 2010 From: yoshida at nttv6.jp (Tomoya Yoshida) Date: Tue, 02 Mar 2010 16:59:35 +0900 Subject: 1.0.0.0/8 route from MERIT ? In-Reply-To: <14DB3F7E-7EFA-4A8E-A0E0-114FF6ED0908@apnic.net> References: <4B857A74.6000503@ieee.org> <14DB3F7E-7EFA-4A8E-A0E0-114FF6ED0908@apnic.net> Message-ID: <20100302165433.ACC8.9C4C12A4@nttv6.jp> Are these from youtube also? 1.1.1.0/24 *[BGP/170] 07:04:22, MED 0, localpref 100 AS path: 2914 3356 36561 I 1.2.3.0/24 *[BGP/170] 07:01:21, MED 0, localpref 100 AS path: 2914 3356 36561 I tomoya On Thu, 25 Feb 2010 14:34:02 +1100 Geoff Huston wrote: | |On 25/02/2010, at 6:13 AM, Alex H. Ryu wrote: | |> |> Today I jumped into one of our routers, and I found that 1.0.0.0/8 is |> announced from AS237, which is MERIT. |> |> |> Network Next Hop Metric LocPrf Weight Path |> *> 1.0.0.0/8 4.59.200.5 0 60 0 (65001 |> 65105) 3356 7018 237 i |> |> Is this supposed to be? |> I thought 1.0.0.0/8 is allocated to APNIC. | |Yes, this is supposed to be. This is one of a number of planned experiments in advertising all and selected parts of 1/8 in the coming weeks. | |Geoff Huston |APNIC -- Tomoya Yoshida From gih at apnic.net Tue Mar 2 02:17:45 2010 From: gih at apnic.net (Geoff Huston) Date: Tue, 2 Mar 2010 19:17:45 +1100 Subject: 1.0.0.0/8 route from MERIT ? In-Reply-To: <20100302165433.ACC8.9C4C12A4@nttv6.jp> References: <4B857A74.6000503@ieee.org> <14DB3F7E-7EFA-4A8E-A0E0-114FF6ED0908@apnic.net> <20100302165433.ACC8.9C4C12A4@nttv6.jp> Message-ID: Hi, As I noted in the previous note quoted below, APNIC are undertaking a second experiment with these two /24 routes originated by AS 36561. These two /24s appear to be the major attractors in the 1.0.0.0/8 space. YouTube have generously provided assistance for this second experiment, and we are very grateful for their help! Geoff Huston APNIC On 02/03/2010, at 6:59 PM, Tomoya Yoshida wrote: > Are these from youtube also? > > 1.1.1.0/24 *[BGP/170] 07:04:22, MED 0, localpref 100 > AS path: 2914 3356 36561 I > 1.2.3.0/24 *[BGP/170] 07:01:21, MED 0, localpref 100 > AS path: 2914 3356 36561 I > > tomoya > > > On Thu, 25 Feb 2010 14:34:02 +1100 > Geoff Huston wrote: > > | > |On 25/02/2010, at 6:13 AM, Alex H. Ryu wrote: > | > |> > |> Today I jumped into one of our routers, and I found that 1.0.0.0/8 is > |> announced from AS237, which is MERIT. > |> > |> > |> Network Next Hop Metric LocPrf Weight Path > |> *> 1.0.0.0/8 4.59.200.5 0 60 0 (65001 > |> 65105) 3356 7018 237 i > |> > |> Is this supposed to be? > |> I thought 1.0.0.0/8 is allocated to APNIC. > | > |Yes, this is supposed to be. This is one of a number of planned experiments in advertising all and selected parts of 1/8 in the coming weeks. > | > |Geoff Huston > |APNIC > > -- > Tomoya Yoshida > From yoshida at nttv6.jp Tue Mar 2 02:50:37 2010 From: yoshida at nttv6.jp (Tomoya Yoshida) Date: Tue, 02 Mar 2010 17:50:37 +0900 Subject: 1.0.0.0/8 route from MERIT ? In-Reply-To: References: <20100302165433.ACC8.9C4C12A4@nttv6.jp> Message-ID: <20100302174934.ACD4.9C4C12A4@nttv6.jp> Thank you Geoff. I asked because I could see 1/8 of merit AS237 but couldn't see of origin AS36561 for those two in database. Even if it's an experiment and sort term, It's better to be registerd in right origin I think. # It could be guessed but... When RPKI comes, is it no problem?? -tomoya On Tue, 2 Mar 2010 19:17:45 +1100 Geoff Huston wrote: |Hi, | |As I noted in the previous note quoted below, APNIC are undertaking a second experiment with these two /24 routes originated by AS 36561. These two /24s appear to be the major attractors in the 1.0.0.0/8 space. YouTube have generously provided assistance for this second experiment, and we are very grateful for their help! | | Geoff Huston | APNIC | | | | |On 02/03/2010, at 6:59 PM, Tomoya Yoshida wrote: | |> Are these from youtube also? |> |> 1.1.1.0/24 *[BGP/170] 07:04:22, MED 0, localpref 100 |> AS path: 2914 3356 36561 I |> 1.2.3.0/24 *[BGP/170] 07:01:21, MED 0, localpref 100 |> AS path: 2914 3356 36561 I |> |> tomoya |> |> |> On Thu, 25 Feb 2010 14:34:02 +1100 |> Geoff Huston wrote: |> |> | |> |On 25/02/2010, at 6:13 AM, Alex H. Ryu wrote: |> | |> |> |> |> Today I jumped into one of our routers, and I found that 1.0.0.0/8 is |> |> announced from AS237, which is MERIT. |> |> |> |> |> |> Network Next Hop Metric LocPrf Weight Path |> |> *> 1.0.0.0/8 4.59.200.5 0 60 0 (65001 |> |> 65105) 3356 7018 237 i |> |> |> |> Is this supposed to be? |> |> I thought 1.0.0.0/8 is allocated to APNIC. |> | |> |Yes, this is supposed to be. This is one of a number of planned experiments in advertising all and selected parts of 1/8 in the coming weeks. |> | |> |Geoff Huston |> |APNIC |> |> -- |> Tomoya Yoshida |> -- Tomoya Yoshida From jarenangerbauer at gmail.com Tue Mar 2 06:44:07 2010 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Tue, 2 Mar 2010 05:44:07 -0700 Subject: hotmail help In-Reply-To: <43AE4319-35D0-4055-AC32-F0E99D241967@gmail.com> References: <43AE4319-35D0-4055-AC32-F0E99D241967@gmail.com> Message-ID: <4c6b8c911003020444q19d78671je68ef032b62bca27@mail.gmail.com> On Mon, Mar 1, 2010 at 7:45 PM, Matt Kelly wrote: > Anyone from hotmail on the list that can contact me please? ?We're having a > widespread issue. Is this an issue with delivery, abuse, network issues, other? You need to be more specific -- Hotmail's a big place :) --Jaren From morrowc.lists at gmail.com Tue Mar 2 08:51:29 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 Mar 2010 09:51:29 -0500 Subject: 1.0.0.0/8 route from MERIT ? In-Reply-To: <20100302174934.ACD4.9C4C12A4@nttv6.jp> References: <20100302165433.ACC8.9C4C12A4@nttv6.jp> <20100302174934.ACD4.9C4C12A4@nttv6.jp> Message-ID: <75cb24521003020651n31134d0r758979b2b576c029@mail.gmail.com> On Tue, Mar 2, 2010 at 3:50 AM, Tomoya Yoshida wrote: > Thank you Geoff. > > I asked because I could see 1/8 of merit AS237 but couldn't see > of origin AS36561 for those two in database. > Even if it's an experiment and sort term, It's better to be registerd > in right origin I think. # It could be guessed but... which databases? morrowc at localhost:~$ whois -h rr.arin.net 1.2.3.0 % This is the ARIN Routing Registry. % Note: this output has been filtered. % Information related to '1.2.3.0/24AS36561' route: 1.2.3.0/24 descr: YouTube, Inc. descr: 901 Cherry Ave descr: San Bruno, CA 94066 descr: US origin: AS36561 mnt-by: MNT-YOUTU source: ARIN # Filtered morrowc at localhost:~$ whois -h rr.arin.net 1.1.1.0 % This is the ARIN Routing Registry. % Note: this output has been filtered. % Information related to '1.1.1.0/24AS36561' route: 1.1.1.0/24 descr: YouTube, Inc. descr: 901 Cherry Ave descr: San Bruno, CA 94066 descr: US origin: AS36561 mnt-by: MNT-YOUTU source: ARIN # Filtered These ought to then get around to other IRR-ish-things when their propogation times hit, yes? -Chris > When RPKI comes, is it no problem?? > > ? ? ? ?-tomoya > > > On Tue, 2 Mar 2010 19:17:45 +1100 > Geoff Huston wrote: > > |Hi, > | > |As I noted in the previous note quoted below, APNIC are undertaking a second experiment with these two /24 routes originated by AS 36561. These two /24s appear to be the major attractors in the 1.0.0.0/8 space. YouTube have generously provided assistance for this second experiment, and we are very grateful for their help! > | > | ?Geoff Huston > | ?APNIC > | > | > | > | > |On 02/03/2010, at 6:59 PM, Tomoya Yoshida wrote: > | > |> Are these from youtube also? > |> > |> 1.1.1.0/24 ? ? ? ? *[BGP/170] 07:04:22, MED 0, localpref 100 > |> ? ? ? ? ? ? ? ? ? ? ?AS path: 2914 3356 36561 I > |> 1.2.3.0/24 ? ? ? ? *[BGP/170] 07:01:21, MED 0, localpref 100 > |> ? ? ? ? ? ? ? ? ? ? ?AS path: 2914 3356 36561 I > |> > |> ? ? ?tomoya > |> > |> > |> On Thu, 25 Feb 2010 14:34:02 +1100 > |> Geoff Huston wrote: > |> > |> | > |> |On 25/02/2010, at 6:13 AM, Alex H. Ryu wrote: > |> | > |> |> > |> |> Today I jumped into one of our routers, and I found that 1.0.0.0/8 is > |> |> announced from AS237, which is MERIT. > |> |> > |> |> > |> |> ? ?Network ? ? ? ? ? ?Next Hop ? ? ? ?Metric LocPrf Weight Path > |> |> *> ?1.0.0.0/8 ? ? ? ? ?4.59.200.5 ? ? ?0 ? ? ?60 ? ? 0 ? ? ?(65001 > |> |> 65105) 3356 7018 237 i > |> |> > |> |> Is this supposed to be? > |> |> I thought 1.0.0.0/8 is allocated to APNIC. > |> | > |> |Yes, this is supposed to be. This is one of a number of planned experiments in advertising all and selected parts of 1/8 in the coming weeks. > |> | > |> |Geoff Huston > |> |APNIC > |> > |> -- > |> Tomoya Yoshida > |> > > -- > Tomoya Yoshida > > > From ljb at merit.edu Tue Mar 2 09:28:22 2010 From: ljb at merit.edu (Larry Blunk) Date: Tue, 02 Mar 2010 10:28:22 -0500 Subject: 1.0.0.0/8 route from MERIT ? In-Reply-To: <75cb24521003020651n31134d0r758979b2b576c029@mail.gmail.com> References: <20100302165433.ACC8.9C4C12A4@nttv6.jp> <20100302174934.ACD4.9C4C12A4@nttv6.jp> <75cb24521003020651n31134d0r758979b2b576c029@mail.gmail.com> Message-ID: <4B8D2E96.8040502@merit.edu> Christopher Morrow wrote: > On Tue, Mar 2, 2010 at 3:50 AM, Tomoya Yoshida wrote: > >> Thank you Geoff. >> >> I asked because I could see 1/8 of merit AS237 but couldn't see >> of origin AS36561 for those two in database. >> Even if it's an experiment and sort term, It's better to be registerd >> in right origin I think. # It could be guessed but... >> > > which databases? > > morrowc at localhost:~$ whois -h rr.arin.net 1.2.3.0 > % This is the ARIN Routing Registry. > > % Note: this output has been filtered. > > % Information related to '1.2.3.0/24AS36561' > > route: 1.2.3.0/24 > descr: YouTube, Inc. > descr: 901 Cherry Ave > descr: San Bruno, CA 94066 > descr: US > origin: AS36561 > mnt-by: MNT-YOUTU > source: ARIN # Filtered > > > morrowc at localhost:~$ whois -h rr.arin.net 1.1.1.0 > % This is the ARIN Routing Registry. > > % Note: this output has been filtered. > > % Information related to '1.1.1.0/24AS36561' > > route: 1.1.1.0/24 > descr: YouTube, Inc. > descr: 901 Cherry Ave > descr: San Bruno, CA 94066 > descr: US > origin: AS36561 > mnt-by: MNT-YOUTU > source: ARIN # Filtered > > These ought to then get around to other IRR-ish-things when their > propogation times hit, yes? > > -Chris > I'm not positive that this is still the case, but I believe that there can be quite a bit of latency in mirroring due to the way RIPE database code (which ARIN uses) works. The last object(s) registered are not pushed to the mirror stream until the next object(s) are registered. I believe RIPE regularly pushes a dummy object in order to keep it's mirrors more regularly synced. I don't think that ARIN does this. It's a bigger issue for ARIN as their routing registry is updated less frequently than the RIPE routing registry. According to our logs, the objects were not mirrored on the RADB server until about 2.5 hours after Tomoya posted his email (the objects were picked up from the ARIN mirror at 05:37:42 -0500 (EST) March 2). --Larry > >> When RPKI comes, is it no problem?? >> >> -tomoya >> >> >> On Tue, 2 Mar 2010 19:17:45 +1100 >> Geoff Huston wrote: >> >> |Hi, >> | >> |As I noted in the previous note quoted below, APNIC are undertaking a second experiment with these two /24 routes originated by AS 36561. These two /24s appear to be the major attractors in the 1.0.0.0/8 space. YouTube have generously provided assistance for this second experiment, and we are very grateful for their help! >> | >> | Geoff Huston >> | APNIC >> | >> | >> | >> | >> |On 02/03/2010, at 6:59 PM, Tomoya Yoshida wrote: >> | >> |> Are these from youtube also? >> |> >> |> 1.1.1.0/24 *[BGP/170] 07:04:22, MED 0, localpref 100 >> |> AS path: 2914 3356 36561 I >> |> 1.2.3.0/24 *[BGP/170] 07:01:21, MED 0, localpref 100 >> |> AS path: 2914 3356 36561 I >> |> >> |> tomoya >> |> >> |> >> |> On Thu, 25 Feb 2010 14:34:02 +1100 >> |> Geoff Huston wrote: >> |> >> |> | >> |> |On 25/02/2010, at 6:13 AM, Alex H. Ryu wrote: >> |> | >> |> |> >> |> |> Today I jumped into one of our routers, and I found that 1.0.0.0/8 is >> |> |> announced from AS237, which is MERIT. >> |> |> >> |> |> >> |> |> Network Next Hop Metric LocPrf Weight Path >> |> |> *> 1.0.0.0/8 4.59.200.5 0 60 0 (65001 >> |> |> 65105) 3356 7018 237 i >> |> |> >> |> |> Is this supposed to be? >> |> |> I thought 1.0.0.0/8 is allocated to APNIC. >> |> | >> |> |Yes, this is supposed to be. This is one of a number of planned experiments in advertising all and selected parts of 1/8 in the coming weeks. >> |> | >> |> |Geoff Huston >> |> |APNIC >> |> >> |> -- >> |> Tomoya Yoshida >> |> >> >> -- >> Tomoya Yoshida >> >> >> >> > > From nathan at stonekitty.net Tue Mar 2 09:58:51 2010 From: nathan at stonekitty.net (Nathan) Date: Tue, 2 Mar 2010 07:58:51 -0800 Subject: 1.0.0.0/8 route from MERIT ? In-Reply-To: <4B8D2E96.8040502@merit.edu> References: <20100302165433.ACC8.9C4C12A4@nttv6.jp> <20100302174934.ACD4.9C4C12A4@nttv6.jp> <75cb24521003020651n31134d0r758979b2b576c029@mail.gmail.com> <4B8D2E96.8040502@merit.edu> Message-ID: I'm sorry my RR update was ... too late? Did this cause a problem for someone? --N (AS36561) On Mar 2, 2010, at 7:28, Larry Blunk wrote: > > Christopher Morrow wrote: >> On Tue, Mar 2, 2010 at 3:50 AM, Tomoya Yoshida >> wrote: >> >>> Thank you Geoff. >>> >>> I asked because I could see 1/8 of merit AS237 but couldn't see >>> of origin AS36561 for those two in database. >>> Even if it's an experiment and sort term, It's better to be >>> registerd >>> in right origin I think. # It could be guessed but... >>> >> >> which databases? >> >> morrowc at localhost:~$ whois -h rr.arin.net 1.2.3.0 >> % This is the ARIN Routing Registry. >> >> % Note: this output has been filtered. >> >> % Information related to '1.2.3.0/24AS36561' >> >> route: 1.2.3.0/24 >> descr: YouTube, Inc. >> descr: 901 Cherry Ave >> descr: San Bruno, CA 94066 >> descr: US >> origin: AS36561 >> mnt-by: MNT-YOUTU >> source: ARIN # Filtered >> >> >> morrowc at localhost:~$ whois -h rr.arin.net 1.1.1.0 >> % This is the ARIN Routing Registry. >> >> % Note: this output has been filtered. >> >> % Information related to '1.1.1.0/24AS36561' >> >> route: 1.1.1.0/24 >> descr: YouTube, Inc. >> descr: 901 Cherry Ave >> descr: San Bruno, CA 94066 >> descr: US >> origin: AS36561 >> mnt-by: MNT-YOUTU >> source: ARIN # Filtered >> >> These ought to then get around to other IRR-ish-things when their >> propogation times hit, yes? >> >> -Chris >> > > > I'm not positive that this is still the case, but I believe that > there can be quite a bit of latency in mirroring due to the > way RIPE database code (which ARIN uses) works. The > last object(s) registered are not pushed to the mirror stream until > the next object(s) are registered. I believe RIPE regularly pushes > a dummy object in order to keep it's mirrors more regularly > synced. I don't think that ARIN does this. It's a bigger issue > for ARIN as their routing registry is updated less frequently > than the RIPE routing registry. > > According to our logs, the objects were not mirrored on > the RADB server until about 2.5 hours after Tomoya posted > his email (the objects were picked up from the ARIN > mirror at 05:37:42 -0500 (EST) March 2). > > > > --Larry > > > >> >>> When RPKI comes, is it no problem?? >>> >>> -tomoya >>> >>> >>> On Tue, 2 Mar 2010 19:17:45 +1100 >>> Geoff Huston wrote: >>> >>> |Hi, >>> | >>> |As I noted in the previous note quoted below, APNIC are >>> undertaking a second experiment with these two /24 routes >>> originated by AS 36561. These two /24s appear to be the major >>> attractors in the 1.0.0.0/8 space. YouTube have generously >>> provided assistance for this second experiment, and we are very >>> grateful for their help! >>> | >>> | Geoff Huston >>> | APNIC >>> | >>> | >>> | >>> | >>> |On 02/03/2010, at 6:59 PM, Tomoya Yoshida wrote: >>> | >>> |> Are these from youtube also? >>> |> >>> |> 1.1.1.0/24 *[BGP/170] 07:04:22, MED 0, localpref 100 >>> |> AS path: 2914 3356 36561 I >>> |> 1.2.3.0/24 *[BGP/170] 07:01:21, MED 0, localpref 100 >>> |> AS path: 2914 3356 36561 I >>> |> >>> |> tomoya >>> |> >>> |> >>> |> On Thu, 25 Feb 2010 14:34:02 +1100 >>> |> Geoff Huston wrote: >>> |> >>> |> | >>> |> |On 25/02/2010, at 6:13 AM, Alex H. Ryu wrote: >>> |> | >>> |> |> >>> |> |> Today I jumped into one of our routers, and I found that 1.0.0.0/8 >>> is >>> |> |> announced from AS237, which is MERIT. >>> |> |> >>> |> |> >>> |> |> Network Next Hop Metric LocPrf Weight >>> Path >>> |> |> *> 1.0.0.0/8 4.59.200.5 0 60 0 >>> (65001 >>> |> |> 65105) 3356 7018 237 i >>> |> |> >>> |> |> Is this supposed to be? >>> |> |> I thought 1.0.0.0/8 is allocated to APNIC. >>> |> | >>> |> |Yes, this is supposed to be. This is one of a number of >>> planned experiments in advertising all and selected parts of 1/8 >>> in the coming weeks. >>> |> | >>> |> |Geoff Huston >>> |> |APNIC >>> |> >>> |> -- >>> |> Tomoya Yoshida >>> |> >>> >>> -- >>> Tomoya Yoshida >>> >>> >>> >>> >> >> > > From charles at knownelement.com Tue Mar 2 10:58:20 2010 From: charles at knownelement.com (Charles N Wyble) Date: Tue, 02 Mar 2010 08:58:20 -0800 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <4B8CB336.1060706@bogus.com> References: <1002270004.AA11084@ivan.Harhan.ORG> <4B8CB336.1060706@bogus.com> Message-ID: <4B8D43AC.4070208@knownelement.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joel Jaeggli wrote: > On 03/01/2010 05:34 PM, Akyol, Bora A wrote: >> Michael >> > > point-to-point and ptmp 802.11phy derived tdm gear has been > outperforming cellular access layers on the throughput and cost > equations for a number of years. Yep. There was a cool experiment in Venuzella with a 237 mile link. http://www.wired.com/gadgetlab/2007/06/w_wifi_record_2/ The tdm firmware is really interesting stuff. More at http://tier.cs.berkeley.edu/wiki/Wireless The choice of frequencies and licensed > vs unlicensed operation continues to proliferate as the radios get more > flexible and cheaper... > > see for one ptp backkhul example: > > http://www.ubnt.com/nanobridge I love the ubnt stuff. It's simply amazing. > > It is now possible to put together a passable community or wisp network > for what essentially is microcap money. Yep. Unlike rural electrification or > rural ftfth the prospects of doing such a deployment for the low > hundreds of dollars per household in aggregate are not hard to imagine. Exactly. Yay for unlicensed ISM bands. > > As far as I'm concerned someone else with capital can solve the mobility > problem, the fixed wireless problem can be addressed in many cases with > sound engineering, sweat equitity, community involvement and a little > capital. For sure. Way to many folks focused on celluar as a solution. *peers over at my 16 node openwrt mesh testing lab* In my opinion, last mile access is a very mature area, with well understood operational models etc. Granted all sorts of interesting wifi related issues pop up on the WISPA list, but so does BGP issues on Nanog or weird cisco bugs on c-nsp. The biggest problem is middle mile. That is where the money needs to go. You need something to back haul to the interwebz. There is a lot of fiber in the ground already, but there are numerous layer 8 issues with getting to it most of the time. Solving those is an exercise left for the reader. - -- Charles N Wyble Linux Systems Engineer charles at knownelement.com (818)280-7059 http://www.knownelement.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuNQ6gACgkQJmrRtQ6zKE/AMACfXBpFiBGIt9lv1jErkMB6c+cW VugAn1LqdiyTnveAMdslH1KLnuM94C2K =tkW1 -----END PGP SIGNATURE----- From bill at herrin.us Tue Mar 2 12:24:21 2010 From: bill at herrin.us (William Herrin) Date: Tue, 2 Mar 2010 13:24:21 -0500 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <1002262134.AA10367@ivan.Harhan.ORG> References: <1002262134.AA10367@ivan.Harhan.ORG> Message-ID: <3c3e3fca1003021024m777d63e4ob9581b7f2f821b0@mail.gmail.com> On Fri, Feb 26, 2010 at 4:34 PM, Michael Sokolov wrote: > That got me thinking: ISDN/IDSL and T1 can be extended infinitely far > into the boondocks because those signal formats support repeaters. ?What > I'm wondering is how can we do the same thing with SDSL - and I mean > politically rather than technically. ?The technical part is easy: some > COs already have CLECs in them that serve G.shdsl (I've been told that > NEN does that) and for G.shdsl repeaters are part of the standard > (searching around shows a few vendors making them); in the case of > SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters > and hence no major vendors making such, but I can build such a repeater > unofficially. > > The difficulty is with the political part, and that's where I'm seeking > the wisdom of this list. ?How would one go about sticking a mid-span > repeater into an ILEC-owned 31 kft rural loop? You wouldn't. The ILECs have resisted doing that sort of thing tooth and nail. They may not want to sell you service yet but they don't want anyone else to get a foot in the door while they get around to it. However, if it really is a 31kft copper loop all the way back to the CO and not to a closer vault (try driving the wire path to find out) you may be able to knock on a few doors in the middle around the 15kft point, make a new friend, order a DSL in the middle, order an "alarm circuit" or "dry copper pair" from the 15kft point to you and run your own signal over the alarm circuit. Your terrain may also be a factor. Rolling hills and 3-story trees make wireless hard but if you can see rooftops near the CO with binoculars from your rooftop, amplifying an 802.11 signal for a 6-mile transmission is a walk in the park. Probably not helpful in western Mass, but possible in southern CA. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From raj.singh at demandmedia.com Tue Mar 2 16:24:58 2010 From: raj.singh at demandmedia.com (Raj Singh) Date: Tue, 2 Mar 2010 14:24:58 -0800 Subject: Anyone seeing any issues in LA area with XO? Message-ID: <6CDE22DE80A63A4DACF4FE2C916519A53F4F3C1908@BLV11EXVS01.corp.dm.local> We just lost all our Santa Monica links with XO. Anyone else seeing this? Thanks, Raj Singh | Director Network Engineering _________________________________ Demand Media | eNom, Inc. Direct: 425.974.4679 15801 NE 24th St. Bellevue, WA 98008 Raj.Singh at DemandMedia.com From leen at consolejunkie.net Tue Mar 2 16:38:29 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Tue, 02 Mar 2010 23:38:29 +0100 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <541B85C5-1FB0-4D20-B62A-15D4222E4E78@delong.com> References: <541B85C5-1FB0-4D20-B62A-15D4222E4E78@delong.com> Message-ID: <4B8D9365.7070404@consolejunkie.net> >> Not comparing this to the former-DDR or Chinese situation (please refer >> to my tin-foil remark above) a per-country specific prefix is not >> necessarily a bad thing and may even have an upside. >> >> > Care to explain what that could possibly be? (I simply don't see an > upside to making it easy to censor the internet by national identity). > > Maintenance of "GeoIP"-databases becomes easier and less error-prone ? Possible less out of date because of it. We've seen complaints about those many times on this list. From richard.barnes at gmail.com Tue Mar 2 16:46:46 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 3 Mar 2010 06:46:46 +0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <4B8D9365.7070404@consolejunkie.net> References: <541B85C5-1FB0-4D20-B62A-15D4222E4E78@delong.com> <4B8D9365.7070404@consolejunkie.net> Message-ID: <88ac5c711003021446w7ac42836rcb41a55130125f9@mail.gmail.com> >> Care to explain what that could possibly be? (I simply don't see an >> upside to making it easy to censor the internet by national identity). > > Maintenance of "GeoIP"-databases becomes easier and less error-prone ? > > Possible less out of date because of it. > > We've seen complaints about those many times on this list. There are much better ways to handle geolocation than reconfiguring the structure of the IP address space. See also: Regardless of the technical merits of those specific protocols, which have been debated here and elsewhere, geolocation is an application-layer concept, and shouldn't be forced down onto the network layer. --Richard From leen at consolejunkie.net Tue Mar 2 16:56:14 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Tue, 02 Mar 2010 23:56:14 +0100 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <88ac5c711003021446w7ac42836rcb41a55130125f9@mail.gmail.com> References: <541B85C5-1FB0-4D20-B62A-15D4222E4E78@delong.com> <4B8D9365.7070404@consolejunkie.net> <88ac5c711003021446w7ac42836rcb41a55130125f9@mail.gmail.com> Message-ID: <4B8D978E.6000202@consolejunkie.net> On 03/02/2010 11:46 PM, Richard Barnes wrote: >>> Care to explain what that could possibly be? (I simply don't see an >>> upside to making it easy to censor the internet by national identity). >>> >> Maintenance of "GeoIP"-databases becomes easier and less error-prone ? >> >> Possible less out of date because of it. >> >> We've seen complaints about those many times on this list. >> > There are much better ways to handle geolocation than reconfiguring > the structure of the IP address space. See also: > > > > > > Regardless of the technical merits of those specific protocols, which > have been debated here and elsewhere, geolocation is an > application-layer concept, and shouldn't be forced down onto the > network layer. > > --Richard > > I never said we should do so. :-) I just mentioned it's possible. From Ray.Sanders at VillageVoiceMedia.com Tue Mar 2 17:24:57 2010 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Tue, 02 Mar 2010 16:24:57 -0700 Subject: L.A Network Outages today, Message-ID: <4B8D3BD9020000F20003E1EA@newtimes.com> Sorry if this is better handled by outages, but anyone in the L.A area have an idea about the network/phone outages today in L.A? We've seen issues with x.o, but not sure of the full scope. Thanks. Mobile email powered by the force... From carlos at race.com Tue Mar 2 17:25:45 2010 From: carlos at race.com (Carlos Alcantar) Date: Tue, 2 Mar 2010 15:25:45 -0800 Subject: Anyone seeing any issues in LA area with XO? Message-ID: <859604546CD1FF488BDB6EA94C896AFBC98426@racexchange.race.local> I have 3 t1's that went down in the santa monica area at 1:47pm pst all off he same hub ds3. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 E: carlos at race.com -----Original Message----- From: Raj Singh [mailto:raj.singh at demandmedia.com] Sent: Tuesday, March 02, 2010 2:25 PM To: NANOG Subject: Anyone seeing any issues in LA area with XO? We just lost all our Santa Monica links with XO. Anyone else seeing this? Thanks, Raj Singh | Director Network Engineering _________________________________ Demand Media | eNom, Inc. Direct: 425.974.4679 15801 NE 24th St. Bellevue, WA 98008 Raj.Singh at DemandMedia.com From Ray.Sanders at VillageVoiceMedia.com Tue Mar 2 17:42:59 2010 From: Ray.Sanders at VillageVoiceMedia.com (Ray Sanders) Date: Tue, 02 Mar 2010 16:42:59 -0700 Subject: Anyone seeing any issues in LA area with XO? Message-ID: <4B8D4013020000F20003E1FD@newtimes.com> We've been seeing issues with our XO connection in L.A as well. Mobile email powered by the force... ---- Original Message ---- From: "Carlos Alcantar" Date: 3/2/10 4:28 pm To: "Raj Singh" ; "NANOG" Subj: RE: Anyone seeing any issues in LA area with XO? I have 3 t1's that went down in the santa monica area at 1:47pm pst all off he same hub ds3. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 E: carlos at race.com -----Original Message----- From: Raj Singh [mailto:raj.singh at demandmedia.com] Sent: Tuesday, March 02, 2010 2:25 PM To: NANOG Subject: Anyone seeing any issues in LA area with XO? We just lost all our Santa Monica links with XO. Anyone else seeing this? Thanks, Raj Singh | Director Network Engineering _________________________________ Demand Media | eNom, Inc. Direct: 425.974.4679 15801 NE 24th St. Bellevue, WA 98008 Raj.Singh at DemandMedia.com From logan.lists at capsaic.in Tue Mar 2 17:48:30 2010 From: logan.lists at capsaic.in (Logan Rojas) Date: Tue, 02 Mar 2010 16:48:30 -0700 Subject: Anyone seeing any issues in LA area with XO? In-Reply-To: <6CDE22DE80A63A4DACF4FE2C916519A53F4F3C1908@BLV11EXVS01.corp.dm.local> References: <6CDE22DE80A63A4DACF4FE2C916519A53F4F3C1908@BLV11EXVS01.corp.dm.local> Message-ID: <4B8DA3CE.5060409@capsaic.in> Confirmed major outage with XO- Master ticket 2041432. We lost a T1 to San Fernando, but one to Anaheim is still up. The tech I spoke with said they have something like 15 COs offline. On 3/2/10 3:24 PM, Raj Singh wrote: > We just lost all our Santa Monica links with XO. Anyone else seeing this? > > > Thanks, > Raj Singh | Director Network Engineering > _________________________________ > Demand Media | eNom, Inc. > Direct: 425.974.4679 > 15801 NE 24th St. > Bellevue, WA 98008 > Raj.Singh at DemandMedia.com > > From sven at cb3rob.net Tue Mar 2 14:59:45 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Tue, 2 Mar 2010 20:59:45 +0000 (UTC) Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <20100301213024.597291CC13@ptavv.es.net> References: <20100301213024.597291CC13@ptavv.es.net> Message-ID: just to undermine the ITU's (only) point, why don't we simply have IANA delegate lets say 25% of the available ipv6 space to AFRINIC and APNIC now, like, -now- already... if they're so concerned about the "developing countries" surely, most of them would be in those regions :P and that should cover their need for centuries to come... On Mon, 1 Mar 2010, Kevin Oberman wrote: >> Date: Mon, 01 Mar 2010 16:55:43 +0100 >> From: Adam Waite >> >> >>> Hm, I was under the impression that ARPANET was a government run >>> network... >>> >>> >> Not since 1992......what you're looking for these days is NIPRnet and >> SIPRnet, and ESnet, etc, etc, etc. > > While ESnet is funded by the Department of Energy and they certainly > define the strategic policy of ESnet, they don't make design decisions > nor get involved with the technical end of the network. > > ESnet is run by the University of California's Berkeley Lab under > contract to the DOE. This may sound like hair splitting, but it is > really very different from Fednets like NIPR and SIPR (and many, many > others) including the Department of Energy's own DOEnet. Note that > DOEnet is used for DOE business operations while ESnet is use support > DOE funded research. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > > ---- > If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ > First click on General and then click on Edit. > At the bottom of the Page you can add or remove addresses. > > > ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From Valdis.Kletnieks at vt.edu Tue Mar 2 18:17:18 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 02 Mar 2010 19:17:18 -0500 Subject: Is there a gmail SMTP expert in the house? Message-ID: <9900.1267575438@localhost> Gmail just bounced some mail to the RFC822 From: address rather than the RFC821 MAIL FROM:. And http://mail.google.com/support/ won't let you report a problem unless you have a gmail account. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Tue Mar 2 19:30:16 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 3 Mar 2010 09:30:16 +0800 Subject: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd) In-Reply-To: <4B8D9365.7070404@consolejunkie.net> References: <541B85C5-1FB0-4D20-B62A-15D4222E4E78@delong.com> <4B8D9365.7070404@consolejunkie.net> Message-ID: <6F0F35F3-960B-43E9-A817-A3F16CF02785@delong.com> On Mar 3, 2010, at 6:38 AM, Leen Besselink wrote: > >>> Not comparing this to the former-DDR or Chinese situation (please refer >>> to my tin-foil remark above) a per-country specific prefix is not >>> necessarily a bad thing and may even have an upside. >>> >>> >> Care to explain what that could possibly be? (I simply don't see an >> upside to making it easy to censor the internet by national identity). >> >> > > Maintenance of "GeoIP"-databases becomes easier and less error-prone ? > Um, you say that like it's a good thing. > Possible less out of date because of it. > True. > We've seen complaints about those many times on this list. > Yes, geolocation by IP is a fundamentally broken idea and process. That's, frankly, a good thing in my opinion. However, ignoring all of that for a moment, what makes you assume that CIRs would only delegate prefixes within their own nation under this scheme? I suspect several countries will likely be happy to sell or rent address space to the highest bidder. Owen From bobbyjim at gmail.com Tue Mar 2 19:37:17 2010 From: bobbyjim at gmail.com (Bobby Mac) Date: Tue, 2 Mar 2010 19:37:17 -0600 Subject: SNMP, Static NAT and management systems including servers midwear and applications Message-ID: Hi All: I have been asked to extend the capabilities of my current monitoring and management system to another division of the company. All IP space is rfc1918 with no public routed space in the mix. Needless to say, and rightfully so, the network folks won't allow me to directly attach my management network to theirs. I use SNMP for system level monitoring for all servers via agents on the servers (WIN and NIX). Static NAT will be put into place but it breaks my SNMP gets used by the noc to validate CPU, disk util ect.. In a quick test NAT on my own network was set up and I can receive traps and parse them fine even with the NAT as the current trap receiver and visualization can handle incoming traps and NAT. I can see system IP and peer IP fulfilling the two sides. I know I can create an simple ALG via a Apache server with Perl to execute the SNMP get on the foreign network. Noc folks can see data and import it into the ticket (no blind escalations). My question is how have others handled SNMP and static NATs without a ground up re-architecture. I don't want to bring in new protocols and change my systems as they are today due to the heavy integration with provisioning, work flow and process flows. They have worked well to date besides the huge sunk $ investment in software and integration. I have been looking for a complex ALG but there doesn't seem to be much out there and I would rather not manipulate the payload, but map it correctly. Any suggestions? -Bob From Valdis.Kletnieks at vt.edu Tue Mar 2 23:51:02 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 03 Mar 2010 00:51:02 -0500 Subject: Is there a gmail SMTP expert in the house? In-Reply-To: Your message of "Tue, 02 Mar 2010 19:17:18 EST." <9900.1267575438@localhost> References: <9900.1267575438@localhost> Message-ID: <22301.1267595462@localhost> On Tue, 02 Mar 2010 19:17:18 EST, Valdis.Kletnieks at vt.edu said: > Gmail just bounced some mail to the RFC822 From: address rather than the > RFC821 MAIL FROM:. And http://mail.google.com/support/ won't let you > report a problem unless you have a gmail account. Due to an off-list reply, it's been determined that somebody adgered the Received: headers, causing an error in identifying the real bounce source. Grungy details: After somebody generated a bounce, it took 3 hops through 10.x space inside gmail before arriving at our mail server. The message inbound to gmail hit mx.gmail.com, and then took 3 hops through 10.x space before doing something that generated the bounce. However, it appears that those 3 inbound 10.x hops weren't in fact gmail space - there are apparently missing Received: between when GMail received it and when somebody decided to bounce it (possibly involving a POP/IMAP fetch). Still unclear who either ate or failed to add the Received: headers. And it didn't help that the party guilty of the actual bounce, after bouncing it to the wrong address (mine), turned around and handed the bounce to GMail's mail servers rather than my site's mail servers, so it *looked* like GMail was the source of the bounce. Bottom line: GMail got framed by somebody else's misbehaving mail system. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tarig at suin.edu.sd Wed Mar 3 00:44:49 2010 From: tarig at suin.edu.sd (Tarig Y. Adam) Date: Wed, 03 Mar 2010 06:44:49 -0000 Subject: My email recived in incorrect date by hotmail Message-ID: <17801192.19525.1265177847571.JavaMail.root@mail.sustech.edu> Hi all I notice all messages received by hotmail have wrong date header. for example I sent a message at "2 Feb 2010 01:00:51 +03",but hotmail display completely different. mail.suin.edu.sd (DeskNow) is ours. Below headers captured by hotmail. Received: from mail.suin.edu.sd ([196.29.170.205]) by snt0-mc4-f6.Snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 14:23:03 -0800 Received: from internal by mail.suin.edu.sd (DeskNow) with SMTP ID 1268e8c8086_3AUH_2dc6; Wed, 3 Feb 2010 01:00:51 +0300 (EAT) Date: Tue, 2 Feb 2010 17:00:51 -0500 (EST) -- Tarig Y. Adam Chief Technical Officer Sudanese Universities' Information Network (SUIN) T: +249925659149 w: www.suin.edu.sd ? This message may contain confidential information?from Sudanese Universities Information Network (SUIN). If you have received this message by mistake, please inform the sender by sending an e-mail reply. At the same time please delete the message and any attachments from your system without making, distributing or retaining any copies Although all our e-mails messages and any attachments upon sending are automatically? virus scanned we assume no? responsibility? for any loss? or damage ?arising from the ?receipt. Sudanese Universities Information Network (SUIN), P.O.Box 321/22, University of Khartoum, 11115, Khartoum, Sudan. www.suin.edu.sd ? From hank at efes.iucc.ac.il Wed Mar 3 00:59:41 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 03 Mar 2010 08:59:41 +0200 Subject: My email recived in incorrect date by hotmail In-Reply-To: <17801192.19525.1265177847571.JavaMail.root@mail.sustech.ed u> Message-ID: <5.1.0.14.2.20100303085851.00c3bdf8@efes.iucc.ac.il> At 01:17 03/02/2010 -0500, Tarig Y. Adam wrote: Your local PC has the date set incorrectly as Feb 3 rather than March 3. -Hank >Hi all >I notice all messages received by hotmail have wrong date header. for >example I sent a message at "2 Feb 2010 01:00:51 +03",but hotmail display >completely different. >mail.suin.edu.sd (DeskNow) is ours. Below headers captured by hotmail. > >Received: from mail.suin.edu.sd ([196.29.170.205]) by >snt0-mc4-f6.Snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); > > Tue, 2 Mar 2010 14:23:03 -0800 > >Received: from internal > > by mail.suin.edu.sd (DeskNow) with SMTP ID 1268e8c8086_3AUH_2dc6; > > Wed, 3 Feb 2010 01:00:51 +0300 (EAT) > >Date: Tue, 2 Feb 2010 17:00:51 -0500 (EST) > > > > >-- >Tarig Y. Adam >Chief Technical Officer >Sudanese Universities' Information Network (SUIN) >T: +249925659149 >w: www.suin.edu.sd > > > > >This message may contain confidential information from Sudanese >Universities Information Network (SUIN). If you have received this message >by mistake, please inform the sender by sending an e-mail reply. At the >same time please delete the message and any attachments from your system >without making, distributing or retaining any copies Although all our >e-mails messages and any attachments upon sending are automatically virus >scanned we assume no responsibility for any loss or damage arising >from the receipt. >Sudanese Universities Information Network (SUIN), P.O.Box 321/22, >University of >Khartoum, 11115, Khartoum, Sudan. www.suin.edu.sd > From Valdis.Kletnieks at vt.edu Wed Mar 3 01:00:15 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 03 Mar 2010 02:00:15 -0500 Subject: My email recived in incorrect date by hotmail In-Reply-To: Your message of "Wed, 03 Feb 2010 01:17:27 EST." <17801192.19525.1265177847571.JavaMail.root@mail.sustech.edu> References: <17801192.19525.1265177847571.JavaMail.root@mail.sustech.edu> Message-ID: <24940.1267599615@localhost> On Wed, 03 Feb 2010 01:17:27 EST, "Tarig Y. Adam" said: > Tue, 2 Mar 2010 14:23:03 -0800 > Wed, 3 Feb 2010 01:00:51 +0300 (EAT) > > Tue, 2 Feb 2010 17:00:51 -0500 (EST) What's wrong here? Different timezones in different parts of the world. It was 2PM Tuesday on the US West Coast, 5PM on US East Coast, and 1AM Wed in the Sudan. Or are you looking at the fact it apparently took 22 minutes and 12 seconds for your system to send the mail to Hotmail? That's common, hotmail will often rate-limit connections. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mark at streamservice.nl Wed Mar 3 06:19:18 2010 From: mark at streamservice.nl (Mark Scholten) Date: Wed, 3 Mar 2010 13:19:18 +0100 Subject: SNMP, Static NAT and management systems including servers midwear and applications In-Reply-To: References: Message-ID: <023f01cabacb$bf8a74d0$3e9f5e70$@nl> Hi Bobby, Can your monitoring system use other ports (per host) for SNMP? In that case you could user port forwarding (and up to 60,000 hosts this should be fine), with static NAT this would be a good option I guess. With kind regards, Mark Scholten > -----Original Message----- > From: Bobby Mac [mailto:bobbyjim at gmail.com] > Sent: Wednesday, March 03, 2010 2:37 AM > To: nanog at nanog.org > Subject: SNMP, Static NAT and management systems including servers > midwear and applications > > Hi All: > > I have been asked to extend the capabilities of my current monitoring > and > management system to another division of the company. All IP space is > rfc1918 with no public routed space in the mix. Needless to say, and > rightfully so, the network folks won't allow me to directly attach my > management network to theirs. > > I use SNMP for system level monitoring for all servers via agents on > the > servers (WIN and NIX). Static NAT will be put into place but it breaks > my > SNMP gets used by the noc to validate CPU, disk util ect.. In a quick > test > NAT on my own network was set up and I can receive traps and parse them > fine > even with the NAT as the current trap receiver and visualization can > handle > incoming traps and NAT. I can see system IP and peer IP fulfilling > the two > sides. I know I can create an simple ALG via a Apache server with Perl > to > execute the SNMP get on the foreign network. Noc folks can see data > and > import it into the ticket (no blind escalations). > > My question is how have others handled SNMP and static NATs without a > ground > up re-architecture. I don't want to bring in new protocols and change > my > systems as they are today due to the heavy integration with > provisioning, > work flow and process flows. They have worked well to date besides the > huge > sunk $ investment in software and integration. > > I have been looking for a complex ALG but there doesn't seem to be much > out > there and I would rather not manipulate the payload, but map it > correctly. > Any suggestions? > > -Bob From flintbarber at flintrock.com Wed Mar 3 07:33:00 2010 From: flintbarber at flintrock.com (Flint E. Barber) Date: Wed, 3 Mar 2010 06:33:00 -0700 Subject: Datacenter List for Rack&Stack in Europe, Switzerland Message-ID: Anyone have a good source for finding contractors in Europe, specifically Switzerland, to do datacenter racking and cabling? A list or contractor site would be helpful. I am looking for 4 people, 2 in Berne and 2 in Zurich, for a small project in early April for about a week. Thanks, -Flint From jmamodio at gmail.com Wed Mar 3 13:37:45 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 3 Mar 2010 13:37:45 -0600 Subject: My email recived in incorrect date by hotmail In-Reply-To: <17801192.19525.1265177847571.JavaMail.root@mail.sustech.edu> References: <17801192.19525.1265177847571.JavaMail.root@mail.sustech.edu> Message-ID: <202705b1003031137g394c52d0o425151a57bab1571@mail.gmail.com> By the virtue of CCITT X.666 Hyperspace Transport Protocol your messages have been transported within different space-time coordinates, best guess check your PC Real Time Clock. Cheers Jorge From leslie at craigslist.org Wed Mar 3 13:52:15 2010 From: leslie at craigslist.org (Leslie) Date: Wed, 03 Mar 2010 11:52:15 -0800 Subject: lt2p/pptp vpn concentrators Message-ID: <4B8EBDEF.4020202@craigslist.org> Hey - We're currently looking for a small lt2p/pptp concentrator, mainly so people can connect via their iphones/androids with some vpn client to get email on the go. Does anyone have any boxes that they love/hate? Thanks for the advice Leslie From sparctacus at gmail.com Wed Mar 3 13:55:39 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Wed, 3 Mar 2010 11:55:39 -0800 Subject: lt2p/pptp vpn concentrators In-Reply-To: <4B8EBDEF.4020202@craigslist.org> References: <4B8EBDEF.4020202@craigslist.org> Message-ID: <53d706301003031155k3de3eb93i73897fd6ddcb551@mail.gmail.com> On Wed, Mar 3, 2010 at 11:52 AM, Leslie wrote: > Hey - > > We're currently looking for a small lt2p/pptp concentrator, mainly so people > can connect via their iphones/androids with some vpn client to get email on > the go. > > Does anyone have any boxes that they love/hate? Soekris with a copy of pfsense on it. -B From leslie at craigslist.org Wed Mar 3 13:58:50 2010 From: leslie at craigslist.org (Leslie) Date: Wed, 03 Mar 2010 11:58:50 -0800 Subject: lt2p/pptp vpn concentrators In-Reply-To: <53d706301003031155k3de3eb93i73897fd6ddcb551@mail.gmail.com> References: <4B8EBDEF.4020202@craigslist.org> <53d706301003031155k3de3eb93i73897fd6ddcb551@mail.gmail.com> Message-ID: <4B8EBF7A.7020907@craigslist.org> I didn't realize that os x server can run this - and pretty much anyone can set up os x in 5 seconds -- anyone have any horror stories? Bryan Irvine wrote: > On Wed, Mar 3, 2010 at 11:52 AM, Leslie wrote: >> Hey - >> >> We're currently looking for a small lt2p/pptp concentrator, mainly so people >> can connect via their iphones/androids with some vpn client to get email on >> the go. >> >> Does anyone have any boxes that they love/hate? > > Soekris with a copy of pfsense on it. > > -B From nikky at mnet.bg Wed Mar 3 14:03:18 2010 From: nikky at mnet.bg (Nickola Kolev) Date: Wed, 3 Mar 2010 22:03:18 +0200 Subject: lt2p/pptp vpn concentrators In-Reply-To: <4B8EBDEF.4020202@craigslist.org> References: <4B8EBDEF.4020202@craigslist.org> Message-ID: <20100303220318.fe6a5f14.nikky@mnet.bg> Hello, Leslie, Can you define small? How does a GNU/Linux server, which is able to terminate 200+ PPTP/IPSec(L2TP) sessions on a moderately old hardware, sound? Having that, you only need iPhones/Androids (v 1.6 and above) configured with their native VPN clients, and you're ready... :) On Wed, 03 Mar 2010 11:52:15 -0800 Leslie wrote: > Hey - > > We're currently looking for a small lt2p/pptp concentrator, mainly so > people can connect via their iphones/androids with some vpn client to > get email on the go. > > Does anyone have any boxes that they love/hate? > > Thanks for the advice > Leslie > -- Best regards, Nickola From sparctacus at gmail.com Wed Mar 3 14:04:23 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Wed, 3 Mar 2010 12:04:23 -0800 Subject: lt2p/pptp vpn concentrators In-Reply-To: <4B8EBF7A.7020907@craigslist.org> References: <4B8EBDEF.4020202@craigslist.org> <53d706301003031155k3de3eb93i73897fd6ddcb551@mail.gmail.com> <4B8EBF7A.7020907@craigslist.org> Message-ID: <53d706301003031204qeb3416q8488b53ace66b47c@mail.gmail.com> I know someone who's run an OS X server VPN for years without issue. On Wed, Mar 3, 2010 at 11:58 AM, Leslie wrote: > I didn't realize that os x server can run this - and pretty much anyone can > set up os x in 5 seconds -- anyone have any horror stories? > > Bryan Irvine wrote: >> >> On Wed, Mar 3, 2010 at 11:52 AM, Leslie wrote: >>> >>> Hey - >>> >>> We're currently looking for a small lt2p/pptp concentrator, mainly so >>> people >>> can connect via their iphones/androids with some vpn client to get email >>> on >>> the go. >>> >>> Does anyone have any boxes that they love/hate? >> >> Soekris with a copy of pfsense on it. >> >> -B > From sil at infiltrated.net Wed Mar 3 15:25:58 2010 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 03 Mar 2010 16:25:58 -0500 Subject: F5 contact Message-ID: <4B8ED3E6.10609@infiltrated.net> Sorry for a non-NANOG related message. Anyone with a direct security contact at F5 please shoot me a message off-list. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From sean at donelan.com Wed Mar 3 17:13:56 2010 From: sean at donelan.com (Sean Donelan) Date: Wed, 3 Mar 2010 18:13:56 -0500 (EST) Subject: Alaska IXP? Message-ID: Are there any common locations in Alaska where multiple local ISPs exchange traffic, either transit or peering? Or is Seattle the closest exchange point for Alaska ISPs? From tony at lava.net Wed Mar 3 17:27:31 2010 From: tony at lava.net (Antonio Querubin) Date: Wed, 3 Mar 2010 13:27:31 -1000 (HST) Subject: Alaska IXP? In-Reply-To: References: Message-ID: On Wed, 3 Mar 2010, Sean Donelan wrote: > Are there any common locations in Alaska where multiple local ISPs exchange > traffic, either transit or peering? Or is Seattle the closest exchange point > for Alaska ISPs? peeringdb.com lists only SIX (in Seattle) and PAIX Seattle. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From pauldotwall at gmail.com Wed Mar 3 18:01:27 2010 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 3 Mar 2010 19:01:27 -0500 Subject: lt2p/pptp vpn concentrators In-Reply-To: <4B8EBDEF.4020202@craigslist.org> References: <4B8EBDEF.4020202@craigslist.org> Message-ID: <620fd17c1003031601s45a1eaa5r9ebfd48f3be641b0@mail.gmail.com> On Wed, Mar 3, 2010 at 2:52 PM, Leslie wrote: > We're currently looking for a small lt2p/pptp concentrator, mainly so people > can connect via their iphones/androids with some vpn client to get email on > the go. If you're looking for ease of client configuration, try a Cisco router or ASA. A current enterprise best-practice is to put your Exchange web server in the DMZ, sacrificing some security for not having to deal with the annoyance of supporting client-side tunneling. Drive Slow, Paul Wall From pauldotwall at gmail.com Wed Mar 3 18:05:20 2010 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 3 Mar 2010 19:05:20 -0500 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <4B8843F4.9070108@foobar.org> <4B886B33.9080403@foobar.org> <20100227040406.GH13373@macbook.catpipe.net> <4B8906B7.8070203@foobar.org> <4B8971F1.8030204@bogus.com> Message-ID: <620fd17c1003031605i36a63b16mc151e9827e097ebe@mail.gmail.com> On Mon, Mar 1, 2010 at 12:30 AM, Randy Bush wrote: > nope. ?in japan, there is still far more powerpoint than packets. ?i > have ntt ftth. ?it is v4 only. ?i have to tunnel to iij to get v6. > > do not believe powerpoint. NTT also charges its (wholesale) IP transit customers a premium for v6 connectivity in Asia. Dorian can speak better to their rationale, though I can't see it helping foster adoption in this economy. Drive Slow, Paul Wall From jared at puck.nether.net Wed Mar 3 18:44:40 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 3 Mar 2010 19:44:40 -0500 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <620fd17c1003031605i36a63b16mc151e9827e097ebe@mail.gmail.com> References: <20100226170924.99ADB1CC0E@ptavv.es.net> <4B8843F4.9070108@foobar.org> <4B886B33.9080403@foobar.org> <20100227040406.GH13373@macbook.catpipe.net> <4B8906B7.8070203@foobar.org> <4B8971F1.8030204@bogus.com> <620fd17c1003031605i36a63b16mc151e9827e097ebe@mail.gmail.com> Message-ID: On Mar 3, 2010, at 7:05 PM, Paul Wall wrote: > On Mon, Mar 1, 2010 at 12:30 AM, Randy Bush wrote: >> nope. in japan, there is still far more powerpoint than packets. i >> have ntt ftth. it is v4 only. i have to tunnel to iij to get v6. >> >> do not believe powerpoint. > > NTT also charges its (wholesale) IP transit customers a premium for v6 > connectivity in Asia. > > Dorian can speak better to their rationale, though I can't see it > helping foster adoption in this economy. (Yes, I know how silly this seems, but read on for useful stuff) It would help if you would each identify which NTT you speak of. There are a variety of NTT lines of business as can be seen here: http://www.ntt.co.jp/csr_e/2009report/group.html It's also my understanding that they own flower shops. -- Useful information to follow -- If you have not yet joined the US State Department Delegation and are interested, please let me know and I will connect you with the right people. I saw a message earlier today to collect the names that are interested. "Formation of a U.S. Delegation to the ITU Meeting on IPv6, March 15 and 16 in Geneva" - Jared From woody at pch.net Wed Mar 3 17:51:13 2010 From: woody at pch.net (Bill Woodcock) Date: Wed, 3 Mar 2010 15:51:13 -0800 Subject: Alaska IXP? In-Reply-To: References: Message-ID: <45442790-3592-4CE7-8EC9-0B364A729993@pch.net> On Mar 3, 2010, at 3:13 PM, Sean Donelan wrote: > Are there any common locations in Alaska where multiple local ISPs exchange traffic, either transit or peering? Or is Seattle the closest exchange point for Alaska ISPs? PCH doesn't know of any. If any exist, we'd very much like to hear about it. Vancouver BC may technically be closer than Seattle, but that's not a significant answer. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jmamodio at gmail.com Wed Mar 3 20:28:59 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 3 Mar 2010 20:28:59 -0600 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100226170924.99ADB1CC0E@ptavv.es.net> <4B886B33.9080403@foobar.org> <20100227040406.GH13373@macbook.catpipe.net> <4B8906B7.8070203@foobar.org> <4B8971F1.8030204@bogus.com> <620fd17c1003031605i36a63b16mc151e9827e097ebe@mail.gmail.com> Message-ID: <202705b1003031828x4d5b2caoa322312582fcb1bc@mail.gmail.com> > "Formation of a U.S. Delegation to the ITU Meeting on IPv6, March 15 and 16 in Geneva" Will the State Department also provide hardware and ammo ? Regards Jorge From babydr at baby-dragons.com Wed Mar 3 21:38:45 2010 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Wed, 3 Mar 2010 18:38:45 -0900 (AKST) Subject: Alaska IXP? In-Reply-To: <45442790-3592-4CE7-8EC9-0B364A729993@pch.net> References: <45442790-3592-4CE7-8EC9-0B364A729993@pch.net> Message-ID: Hello All , On Wed, 3 Mar 2010, Bill Woodcock wrote: > On Mar 3, 2010, at 3:13 PM, Sean Donelan wrote: >> Are there any common locations in Alaska where multiple local ISPs exchange traffic, either transit or peering? Or is Seattle the closest exchange point for Alaska ISPs? > > PCH doesn't know of any. If any exist, we'd very much like to hear about it. Vancouver BC may technically be closer than Seattle, but that's not a significant answer. > > -Bill Having done a little poking around on this subject for the last 1.5 Years . I have not seen a single instance of routing NOT going to Seattle from either of the Eye's based networks (ACS/GCI) to any other network based in alaska , Except through private interconnects . Take with grain of salt , ... Hth , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +------------------------------------------------------------------+ From ml at kenweb.org Wed Mar 3 21:46:47 2010 From: ml at kenweb.org (ML) Date: Wed, 03 Mar 2010 22:46:47 -0500 Subject: FastE iperf in Southeast US Message-ID: <4B8F2D27.9020508@kenweb.org> Would anyone on list be kind enough to provide an iperf server for testing through a Level3 link in Miami? Atlanta or other close nodes should work as well. Throughput <100Mbps. Thanks in advance. From msokolov at ivan.Harhan.ORG Wed Mar 3 22:55:22 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Thu, 4 Mar 2010 04:55:22 GMT Subject: Locations with no good Internet (was ISP in Johannesburg) Message-ID: <1003040455.AA22820@ivan.Harhan.ORG> Charles N Wyble wrote: > The biggest problem is middle mile. That is where the money needs to go. > You need something to back haul to the interwebz. There is a lot of > fiber in the ground already, Another possible way to solve the middle mile issue would again be to use the copper plant that's already in the ground. Unlike fiber, the copper plant is *ubiquitous*: I don't know of any place in the 1st or 2nd worlds that doesn't have copper pairs going to it. Also AFAIK T1s are available everywhere too: if you order a T1, they'll deliver it to you regardless of how deep you are in the middle of nowhere, although I suppose there likely are extra surcharges involved. Granted, a T1 at 1.5 Mbps may not be much for backhaul, but what about bonded T1s? Bond 4 of them to get 6 Mbps symmetric - not too bad in my book for a rural community. And again using SDSL instead of T1 offers a cost reduction opportunity. One could get that 6 Mbps symmetric for much cheaper by bonding 4 SDSL circuits running at 1.5 Mbps each instead of T1s. There is a Covad DSLAM with SDSL capability in virtually every CO in the country, but they serve out a whacky flavor of SDSL/2B1Q. I have good reason to suspect that I may be the last person alive on Earth who knows how to make CPE for this flavor *and* who cares about such things. > but there are numerous layer 8 issues with > getting to it most of the time. Solving those is an exercise left for > the reader. Layer 8? Assuming that layers 8, 9 and 10 are management, financial and political, respectively, the issues that keep me from being able to build that Covad-compatible bonded NxSDSL CPE device lie at Layer 9. Anyone interested in helping me solve those issues? MS From matthew at sorbs.net Thu Mar 4 01:16:07 2010 From: matthew at sorbs.net (Michelle Sullivan) Date: Thu, 04 Mar 2010 08:16:07 +0100 Subject: Spamcop Blocks Facebook? In-Reply-To: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> Message-ID: <4B8F5E37.9030503@sorbs.net> deleskie at gmail.com wrote: > Maybe I'm wrong on this, You are I'm afraid. > and I'm not a mailadmin anywhere nor have I been or pretended to have been in the past. But I'm pretty sure FB only sends you mail based on the prefrences you choose, and I know this is the answer you where given so mostly a statement. How does that equal spam :) > The default is for everything 'on'. They will send to any email address with notifications and mail regardless of signup and they don't honor bounces in any 'email address doesn't work so don't mail it' lists they might or might not employ. Regards, Michelle From jay at west.net Thu Mar 4 02:19:27 2010 From: jay at west.net (Jay Hennigan) Date: Thu, 04 Mar 2010 00:19:27 -0800 Subject: Spamcop Blocks Facebook? In-Reply-To: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> Message-ID: <4B8F6D0F.80500@west.net> On 2/25/10 10:12 PM, deleskie at gmail.com wrote: > Maybe I'm wrong on this, and I'm not a mailadmin anywhere nor have I been or pretended to have been in the past. But I'm pretty sure FB only sends you mail based on the prefrences you choose, and I know this is the answer you where given so mostly a statement. How does that equal spam :) Facebook, like many similar sites, rather aggressively requests that its users supply their email credentials so that the site can "invite" their contacts. All of them. Every stinkin' email address they can mine. If the user/victim falls for this, the social networking site will scrape every email address it can find in the user/victim's contact list and "invite" them to join. These invitations are often forged to appear as if sent from from the user/victim's email address. Similarly, if anyone on Facebook uses the site to forward content (often Trojanned), then Facebook now has the address of the forwardee and will "invite" and then 'remind" repeatedly. So it isn't the Facebook members that Facebook spams (although they might do that too). It's the non-member addresses they scrape from their members. As it's entire contact lists that get scraped, it's bulk. As the people being "invited" and "reminded" didn't ask for it, it's unsolicited. And it's obviously email. Put those together and you get Unsolicited Bulk Email, AKA spam. And those sites that send with their user's name as the sender are even more egregious because they are forging header information. Social networking site users are not the site's customers. They are the site's product. This product is sold to advertisers and data-miners. -- 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 sean at donelan.com Thu Mar 4 07:13:42 2010 From: sean at donelan.com (Sean Donelan) Date: Thu, 4 Mar 2010 08:13:42 -0500 (EST) Subject: Alaska IXP? In-Reply-To: References: Message-ID: On Wed, 3 Mar 2010, Antonio Querubin wrote: > On Wed, 3 Mar 2010, Sean Donelan wrote: > >> Are there any common locations in Alaska where multiple local ISPs exchange >> traffic, either transit or peering? Or is Seattle the closest exchange >> point for Alaska ISPs? > > peeringdb.com lists only SIX (in Seattle) and PAIX Seattle. Thanks and also thanks to the other folks that replied privately. That matches basically what I had found, but I wanted to check. Transit is also ok, I'm doing the usual minimum connections/maximum communications in case of (earthquake, volcano, tsunomi, etc) math. Is there someplace in Anchorage that buying transit or peering from one or a few ISPs is significant enough, or is it going back to Seattle anyway and the local ISPs already have done the math. From jared at puck.nether.net Thu Mar 4 08:33:39 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 4 Mar 2010 09:33:39 -0500 Subject: Alaska IXP? In-Reply-To: References: Message-ID: On Mar 4, 2010, at 8:13 AM, Sean Donelan wrote: > On Wed, 3 Mar 2010, Antonio Querubin wrote: >> On Wed, 3 Mar 2010, Sean Donelan wrote: >> >>> Are there any common locations in Alaska where multiple local ISPs exchange traffic, either transit or peering? Or is Seattle the closest exchange point for Alaska ISPs? >> >> peeringdb.com lists only SIX (in Seattle) and PAIX Seattle. > > Thanks and also thanks to the other folks that replied privately. That matches basically what I had found, but I wanted to check. > > Transit is also ok, I'm doing the usual minimum connections/maximum communications in case of (earthquake, volcano, tsunomi, etc) math. Is > there someplace in Anchorage that buying transit or peering from one or a few ISPs is significant enough, or is it going back to Seattle anyway and > the local ISPs already have done the math. What I've seen is that in smaller markets (in my previous life), eg: Michigan, even when the providers are all in the same facility they 1) Lacked understanding of traffic-patterns to understand peering savings 2) Lacked ability to interconnect (eg: no switch on-site, no bgp/routing capability) 3) CLEC or other colo provider prohibited #2 This meant traffic would regularly be diverted to Chicago or similar for exchange between local ISPs. The one time I was able to pull off a local facility cross-connect, it was difficult to get it at a speed greater than 10megs (this was 1999 or so). With the dropping metro-ethernet/ftth type equipment that can do 1G for "cheap", perhaps a short fiber build for x-connect would help faciltiate things these days. (i should model that and post the results). - Jared From cmaurand at xyonet.com Thu Mar 4 08:36:57 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Thu, 04 Mar 2010 09:36:57 -0500 Subject: lt2p/pptp vpn concentrators In-Reply-To: <620fd17c1003031601s45a1eaa5r9ebfd48f3be641b0@mail.gmail.com> References: <4B8EBDEF.4020202@craigslist.org> <620fd17c1003031601s45a1eaa5r9ebfd48f3be641b0@mail.gmail.com> Message-ID: <4B8FC589.8090803@xyonet.com> pfsense or Vyatta on Intel dual core hardware with decent network cards will save you a ton of $$$ and run thousands of tunnels. On 3/3/2010 7:01 PM, Paul Wall wrote: > On Wed, Mar 3, 2010 at 2:52 PM, Leslie wrote: > >> We're currently looking for a small lt2p/pptp concentrator, mainly so people >> can connect via their iphones/androids with some vpn client to get email on >> the go. >> > If you're looking for ease of client configuration, try a Cisco router or ASA. > > A current enterprise best-practice is to put your Exchange web server > in the DMZ, sacrificing some security for not having to deal with the > annoyance of supporting client-side tunneling. > > Drive Slow, > Paul Wall > > From jhanke at myclearwave.net Thu Mar 4 08:57:18 2010 From: jhanke at myclearwave.net (Jay Hanke) Date: Thu, 4 Mar 2010 08:57:18 -0600 Subject: Alaska IXP? In-Reply-To: References: Message-ID: <000f01cabbaa$fcb20500$f6160f00$@net> On Mar 4, 2010, at 8:13 AM, Sean Donelan wrote: > On Wed, 3 Mar 2010, Antonio Querubin wrote: >> On Wed, 3 Mar 2010, Sean Donelan wrote: >> >>> Are there any common locations in Alaska where multiple local ISPs exchange traffic, either transit or peering? Or is Seattle the closest exchange point for Alaska ISPs? >> >> peeringdb.com lists only SIX (in Seattle) and PAIX Seattle. > > Thanks and also thanks to the other folks that replied privately. That matches basically what I had found, but I wanted to check. > > Transit is also ok, I'm doing the usual minimum connections/maximum communications in case of (earthquake, volcano, tsunomi, etc) math. Is > there someplace in Anchorage that buying transit or peering from one or a few ISPs is significant enough, or is it going back to Seattle anyway and > the local ISPs already have done the math. > >What I've seen is that in smaller markets (in my previous life), eg: Michigan, even when the providers are all in the same facility they > >1) Lacked understanding of traffic-patterns to understand peering savings >2) Lacked ability to interconnect (eg: no switch on-site, no bgp/routing capability) >3) CLEC or other colo provider prohibited #2 > >This meant traffic would regularly be diverted to Chicago or similar for exchange between local ISPs. >The one time I was able to pull off a local facility cross-connect, it was difficult to get it at a speed greater than 10megs (this was 1999 or so). >With the dropping metro-ethernet/ftth type equipment that can do 1G for "cheap", perhaps a short fiber build for x-connect would help faciltiate things >these days. (i should model that and post the results). >- Jared We've seen the same issues in Minnesota. Locally referred to as the "Chicago Problem". Adding on to point 3, there is also a lack of neutral facilities with a sufficient amount of traffic to justify the next carrier connecting. In rural areas many times the two ISPs that provide services are enemies at the business level. A couple of us have started to talk about starting an exchange point. With transit being so cheap it is sometimes difficult to justify paying for the x-connects for a small piece of the routing table. Have you considered starting your own exchange point with some of the local players? Just having the connectivity in place may help with DR situations in addition to all of the benefits of an exchange point. I would also be very interested in seeing any modeling on the subject. There was a document a couple of years ago that was pretty good talking about when to peer but if memory serves it was more focused on the larger carriers. Jay From ahoyos at xiocom.com Thu Mar 4 09:27:41 2010 From: ahoyos at xiocom.com (Andrew Hoyos) Date: Thu, 4 Mar 2010 10:27:41 -0500 Subject: Alaska IXP? In-Reply-To: <000f01cabbaa$fcb20500$f6160f00$@net> Message-ID: On 3/4/10 8:57 AM, "Jay Hanke" wrote: > > We've seen the same issues in Minnesota. Locally referred to as the "Chicago > Problem". Adding on to point 3, there is also a lack of neutral facilities > with a sufficient amount of traffic to justify the next carrier connecting. > In rural areas many times the two ISPs that provide services are enemies at > the business level. A couple of us have started to talk about starting an > exchange point. With transit being so cheap it is sometimes difficult to > justify paying for the x-connects for a small piece of the routing table. > > Have you considered starting your own exchange point with some of the local > players? Just having the connectivity in place may help with DR situations > in addition to all of the benefits of an exchange point. Any interest by other anchor tenants in the area, such as the higher education facilities? In Madison, we have MadIX[1], an exchange point hosted by the University of Wisconsin-Madison, with a presence in one of the neutral carrier hotels in Madison. That eliminates the carrier to carrier issues you run into in the smaller cities, also helps with the "Chicago Problem" which we are very familiar with here as well. [1] http://kb.wisc.edu/ns/page.php?id=6636 Andrew From jabley at hopcount.ca Thu Mar 4 10:14:52 2010 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 4 Mar 2010 11:14:52 -0500 Subject: Alaska IXP? In-Reply-To: <45442790-3592-4CE7-8EC9-0B364A729993@pch.net> References: <45442790-3592-4CE7-8EC9-0B364A729993@pch.net> Message-ID: <3F60A7DC-9B80-4AC2-9D8B-1407A492976F@hopcount.ca> On 2010-03-03, at 18:51, Bill Woodcock wrote: > > On Mar 3, 2010, at 3:13 PM, Sean Donelan wrote: >> Are there any common locations in Alaska where multiple local ISPs exchange traffic, either transit or peering? Or is Seattle the closest exchange point for Alaska ISPs? > > PCH doesn't know of any. If any exist, we'd very much like to hear about it. Vancouver BC may technically be closer than Seattle, but that's not a significant answer. Seattle is the closest practical peering point to Vancouver too, as far as I know, outside of academic/federal networks. Joe From jhanke at myclearwave.net Thu Mar 4 10:33:08 2010 From: jhanke at myclearwave.net (Jay Hanke) Date: Thu, 4 Mar 2010 10:33:08 -0600 Subject: Alaska IXP? In-Reply-To: References: <000f01cabbaa$fcb20500$f6160f00$@net> Message-ID: <001f01cabbb8$601bed60$2053c820$@net> On 3/4/10 8:57 AM, "Jay Hanke" wrote: >> >> We've seen the same issues in Minnesota. Locally referred to as the "Chicago >>. Problem". Adding on to point 3, there is also a lack of neutral facilities >> with a sufficient amount of traffic to justify the next carrier connecting. >> In rural areas many times the two ISPs that provide services are enemies at >> the business level. A couple of us have started to talk about starting an >> exchange point. With transit being so cheap it is sometimes difficult to >> justify paying for the x-connects for a small piece of the routing table. >> >> Have you considered starting your own exchange point with some of the local >> players? Just having the connectivity in place may help with DR situations >> in addition to all of the benefits of an exchange point. > >Any interest by other anchor tenants in the area, such as the higher >education facilities? In Madison, we have MadIX[1], an exchange point hosted >by the University of Wisconsin-Madison, with a presence in one of the >neutral carrier hotels in Madison. > >That eliminates the carrier to carrier issues you run into in the smaller >cities, also helps with the "Chicago Problem" which we are very familiar >with here as well. > >[1] http://kb.wisc.edu/ns/page.php?id=6636 > >Andrew >From the looks of the link it looks like there is a bit of traction at the MadIX. One of the other interested carriers has talked to the University of MN and they showed some interest in participating. The trick is getting the first couple of participants to get to critical mass. Is the MadIX using a route server or is it strictly layer2? Thanks, Jay From aaron at wholesaleinternet.net Thu Mar 4 10:41:38 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 4 Mar 2010 10:41:38 -0600 Subject: Alaska IXP? In-Reply-To: <001f01cabbb8$601bed60$2053c820$@net> References: <000f01cabbaa$fcb20500$f6160f00$@net> <001f01cabbb8$601bed60$2053c820$@net> Message-ID: <00db01cabbb9$93134d20$b939e760$@net> We have very similar issues in Kansas City. A couple years ago we set up a local exchange point but it's had issues gaining traction due to a lack of understanding more than anything else. In these smaller markets people have a hard time understanding how connecting to a competitor benefits them. The key is to get a few solid players on board and cross your fingers that others will follow. Aaron -----Original Message----- From: Jay Hanke [mailto:jhanke at myclearwave.net] Sent: Thursday, March 04, 2010 10:33 AM To: 'Andrew Hoyos'; 'Jared Mauch'; 'Sean Donelan' Cc: nanog at nanog.org Subject: RE: Alaska IXP? On 3/4/10 8:57 AM, "Jay Hanke" wrote: >> >> We've seen the same issues in Minnesota. Locally referred to as the "Chicago >>. Problem". Adding on to point 3, there is also a lack of neutral facilities >> with a sufficient amount of traffic to justify the next carrier connecting. >> In rural areas many times the two ISPs that provide services are enemies at >> the business level. A couple of us have started to talk about starting an >> exchange point. With transit being so cheap it is sometimes difficult to >> justify paying for the x-connects for a small piece of the routing table. >> >> Have you considered starting your own exchange point with some of the local >> players? Just having the connectivity in place may help with DR situations >> in addition to all of the benefits of an exchange point. > >Any interest by other anchor tenants in the area, such as the higher >education facilities? In Madison, we have MadIX[1], an exchange point hosted >by the University of Wisconsin-Madison, with a presence in one of the >neutral carrier hotels in Madison. > >That eliminates the carrier to carrier issues you run into in the smaller >cities, also helps with the "Chicago Problem" which we are very familiar >with here as well. > >[1] http://kb.wisc.edu/ns/page.php?id=6636 > >Andrew >From the looks of the link it looks like there is a bit of traction at the MadIX. One of the other interested carriers has talked to the University of MN and they showed some interest in participating. The trick is getting the first couple of participants to get to critical mass. Is the MadIX using a route server or is it strictly layer2? Thanks, Jay No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2720 - Release Date: 03/03/10 13:34:00 From sparctacus at gmail.com Thu Mar 4 10:54:51 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Thu, 4 Mar 2010 08:54:51 -0800 Subject: My email recived in incorrect date by hotmail In-Reply-To: <202705b1003031137g394c52d0o425151a57bab1571@mail.gmail.com> References: <17801192.19525.1265177847571.JavaMail.root@mail.sustech.edu> <202705b1003031137g394c52d0o425151a57bab1571@mail.gmail.com> Message-ID: <53d706301003040854x23786b7eh69aa45e82de5f26@mail.gmail.com> On Wed, Mar 3, 2010 at 11:37 AM, Jorge Amodio wrote: > By the virtue of CCITT X.666 Hyperspace Transport Protocol your > messages have been transported within different space-time > coordinates, best guess check your PC Real Time Clock. When working with timezones I always find it best to refer to RFC 2324 3 or 4 times, before reaching any conclusion. -Bryan From dwcarder at wisc.edu Thu Mar 4 11:00:09 2010 From: dwcarder at wisc.edu (Dale W. Carder) Date: Thu, 04 Mar 2010 11:00:09 -0600 Subject: Alaska IXP? In-Reply-To: <001f01cabbb8$601bed60$2053c820$@net> References: <000f01cabbaa$fcb20500$f6160f00$@net> <001f01cabbb8$601bed60$2053c820$@net> Message-ID: <4AEC688F-DE30-44EC-809D-20B35B179C2A@wisc.edu> On Mar 4, 2010, at 10:33 AM, Jay Hanke wrote: >> From the looks of the link it looks like there is a bit of traction at the > MadIX. One of the other interested carriers has talked to the University of > MN and they showed some interest in participating. The trick is getting the > first couple of participants to get to critical mass. Is the MadIX using a > route server or is it strictly layer2? Just L2 w/ PIM snooping. Dale From Valdis.Kletnieks at vt.edu Thu Mar 4 11:13:12 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Mar 2010 12:13:12 -0500 Subject: Alaska IXP? In-Reply-To: Your message of "Thu, 04 Mar 2010 10:41:38 CST." <00db01cabbb9$93134d20$b939e760$@net> References: <000f01cabbaa$fcb20500$f6160f00$@net> <001f01cabbb8$601bed60$2053c820$@net> <00db01cabbb9$93134d20$b939e760$@net> Message-ID: <5986.1267722792@localhost> On Thu, 04 Mar 2010 10:41:38 CST, Aaron Wendel said: > We have very similar issues in Kansas City. A couple years ago we set up a > local exchange point but it's had issues gaining traction due to a lack of > understanding more than anything else. In these smaller markets people have > a hard time understanding how connecting to a competitor benefits them. Does anybody have some numbers they're able to share? In the "two small ISPs in the boonies" scenario, *is* there enough cross traffic to make an interconnect worth it? (I'd expect that gaming/IM/email across town to a friend on The Other ISP would dominate here?) Or are both competitors too busy carrying customer traffic to the same sites elsewhere (google, youtube, amazon, etc)? Phrased differently, how big/small a cross-connect is worth the effort? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From alex at blastro.com Thu Mar 4 11:17:03 2010 From: alex at blastro.com (Alex Thurlow) Date: Thu, 04 Mar 2010 11:17:03 -0600 Subject: Redundant BGP for lower cost Message-ID: <4B8FEB0F.5060107@blastro.com> Let me preface this by saying that I'm not a full time network admin, but we're a small company and I'm the only one handling this. Our budget is also not huge, but we're at the point where extended downtime would cost us enough money that we can spend some money to fix the problem. Here's my situation: I have two providers, each handing me gigabit ethernet. I'm getting full BGP feeds and handling them with a Linux/Quagga router. We max out at about 100kpps, as we're mostly pushing video which gives us a large packet size. It works fine, and I've been happy with it so far. But, we've gotten to the point where I want a backup router of some sort in case something happens to that one, what with the fans and disks that could fail. I see a few options. 1. Just set up another Quagga box and use keepalived or some other HA solution. 2. Buy a Cisco/Juniper/whatever and then have the Quagga box as backup. 3. I have a 6500 behind the router that's just doing switching. Could I have something switch that to static route all traffic to one of my providers if something happened to the router? The 6500 has Sup1A with MSFC2 running IOS native. On the Cisco side, I see that we could probably run a 7200VXR with NPE-G1 (about $6000 on ebay). Moving to the Sup720, even used is probably out of our price range. What do you guys think I should use here? Thanks, Alex From jared at puck.nether.net Thu Mar 4 11:19:35 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 4 Mar 2010 12:19:35 -0500 Subject: Alaska IXP? In-Reply-To: <5986.1267722792@localhost> References: <000f01cabbaa$fcb20500$f6160f00$@net> <001f01cabbb8$601bed60$2053c820$@net> <00db01cabbb9$93134d20$b939e760$@net> <5986.1267722792@localhost> Message-ID: <3E88C900-5716-404A-9444-A5CBE233FFC1@puck.nether.net> On Mar 4, 2010, at 12:13 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 04 Mar 2010 10:41:38 CST, Aaron Wendel said: >> We have very similar issues in Kansas City. A couple years ago we set up a >> local exchange point but it's had issues gaining traction due to a lack of >> understanding more than anything else. In these smaller markets people have >> a hard time understanding how connecting to a competitor benefits them. > > Does anybody have some numbers they're able to share? In the "two small ISPs > in the boonies" scenario, *is* there enough cross traffic to make an > interconnect worth it? (I'd expect that gaming/IM/email across town to a friend > on The Other ISP would dominate here?) Or are both competitors too busy > carrying customer traffic to the same sites elsewhere (google, youtube, amazon, > etc)? Phrased differently, how big/small a cross-connect is worth the effort? > Or at the cogent website ($4/meg) do the cost justify peering anymore? Obviously some of this always depends on the loop costs. Going to try to write something up that would be useful for smaller ISPs. The BGP barrier IMHO is quite high in most cases, not all the small ISPs carry their routes out to the edge in the same manner as the larger SPs. - Jared From jack at crepinc.com Thu Mar 4 11:23:56 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 4 Mar 2010 12:23:56 -0500 Subject: Redundant BGP for lower cost In-Reply-To: <4B8FEB0F.5060107@blastro.com> References: <4B8FEB0F.5060107@blastro.com> Message-ID: <2ad0f9f61003040923q7e8e644cw83b20b5a3796b3f0@mail.gmail.com> If you want to keep it cheap, roll out another Quagga edge - one to each peer. Drop default into OSPF from both edges, iBGP over a GE between them. If one toasts you'll only lose half your routes for 1s-ish, or however long you set your OSPF keepalives. While you're at it, add extra fans and run the edge systems off solid state disks or CF cards. Or, buy $real hardware. -Jack Carrozzo On Thu, Mar 4, 2010 at 12:17 PM, Alex Thurlow wrote: > Let me preface this by saying that I'm not a full time network admin, but > we're a small company and I'm the only one handling this. Our budget is > also not huge, but we're at the point where extended downtime would cost us > enough money that we can spend some money to fix the problem. > > Here's my situation: I have two providers, each handing me gigabit > ethernet. I'm getting full BGP feeds and handling them with a Linux/Quagga > router. We max out at about 100kpps, as we're mostly pushing video which > gives us a large packet size. It works fine, and I've been happy with it so > far. But, we've gotten to the point where I want a backup router of some > sort in case something happens to that one, what with the fans and disks > that could fail. I see a few options. > > 1. Just set up another Quagga box and use keepalived or some other HA > solution. > 2. Buy a Cisco/Juniper/whatever and then have the Quagga box as backup. > 3. I have a 6500 behind the router that's just doing switching. Could I > have something switch that to static route all traffic to one of my > providers if something happened to the router? The 6500 has Sup1A with > MSFC2 running IOS native. > > On the Cisco side, I see that we could probably run a 7200VXR with NPE-G1 > (about $6000 on ebay). Moving to the Sup720, even used is probably out of > our price range. > > What do you guys think I should use here? > > Thanks, > Alex > > > From jhanke at myclearwave.net Thu Mar 4 11:42:39 2010 From: jhanke at myclearwave.net (Jay Hanke) Date: Thu, 4 Mar 2010 11:42:39 -0600 Subject: Small IXP [was Alaska IXP?] In-Reply-To: <3E88C900-5716-404A-9444-A5CBE233FFC1@puck.nether.net> References: <000f01cabbaa$fcb20500$f6160f00$@net> <001f01cabbb8$601bed60$2053c820$@net> <00db01cabbb9$93134d20$b939e760$@net> <5986.1267722792@localhost> <3E88C900-5716-404A-9444-A5CBE233FFC1@puck.nether.net> Message-ID: <003d01cabbc2$1606e2c0$4214a840$@net> [snip] > Does anybody have some numbers they're able to share? In the "two small ISPs > in the boonies" scenario, *is* there enough cross traffic to make an > interconnect worth it? (I'd expect that gaming/IM/email across town to a friend > on The Other ISP would dominate here?) Or are both competitors too busy > carrying customer traffic to the same sites elsewhere (google, youtube, amazon, > etc)? Phrased differently, how big/small a cross-connect is worth the effort? > Or at the cogent website ($4/meg) do the cost justify peering anymore? Obviously some of this always depends on the loop costs. Going to try to write something up that would be useful for smaller ISPs. The BGP barrier IMHO is quite high in most cases, not all the small ISPs carry their routes out to the edge in the same manner as the larger SPs. - Jared In our efforts, BGP hasn't come up as often as the Cogent (low cost) issue. I think there are two aspects, one is the opportunity. If you need to build or bury it gets pretty tough to keep costs below $4/meg. The second is traffic volume, if you can set up a peering connection for $200 per month for a full GE you need to stuff 50 Mb/s over the link to break even. That may be tough unless you have an anchor institution like a college or a content network. Rural wholesale (delivered to ISP) is going at $50-60 per Mb in large parts of the US. That brings the breakeven to about 4 Mb which is much easier for the small guys. I think the dominate application driving cross connects right now is might be business VPN between the small ISPs either at L2 or L3. Also, keep in mind though the cheap Internet is only at a limited number of metro area and you still need to pay to transport that Internet back to your network. jay From scott at doc.net.au Thu Mar 4 11:42:51 2010 From: scott at doc.net.au (Scott Howard) Date: Thu, 4 Mar 2010 09:42:51 -0800 Subject: Alaska IXP? In-Reply-To: <3E88C900-5716-404A-9444-A5CBE233FFC1@puck.nether.net> References: <000f01cabbaa$fcb20500$f6160f00$@net> <001f01cabbb8$601bed60$2053c820$@net> <00db01cabbb9$93134d20$b939e760$@net> <5986.1267722792@localhost> <3E88C900-5716-404A-9444-A5CBE233FFC1@puck.nether.net> Message-ID: On Thu, Mar 4, 2010 at 9:19 AM, Jared Mauch wrote: > Or at the cogent website ($4/meg) do the cost justify peering anymore? Personally I'd rather pay $10 for something that works, than $4 for something that doesn't.... scott at zaphod:~$ telnet www.cogentco.com 80 Trying 2001:550:1::cc01... ^C scott at zaphod:~$ (Yes, I know, the cake and all that, but even so...) Scott. From marty.anstey at sunwave.net Thu Mar 4 12:02:49 2010 From: marty.anstey at sunwave.net (Marty Anstey) Date: Thu, 04 Mar 2010 10:02:49 -0800 Subject: Alaska IXP? In-Reply-To: <3F60A7DC-9B80-4AC2-9D8B-1407A492976F@hopcount.ca> References: <45442790-3592-4CE7-8EC9-0B364A729993@pch.net> <3F60A7DC-9B80-4AC2-9D8B-1407A492976F@hopcount.ca> Message-ID: <4B8FF5C9.4020100@sunwave.net> Joe Abley wrote: > On 2010-03-03, at 18:51, Bill Woodcock wrote: > > >> On Mar 3, 2010, at 3:13 PM, Sean Donelan wrote: >> >>> Are there any common locations in Alaska where multiple local ISPs exchange traffic, either transit or peering? Or is Seattle the closest exchange point for Alaska ISPs? >>> >> PCH doesn't know of any. If any exist, we'd very much like to hear about it. Vancouver BC may technically be closer than Seattle, but that's not a significant answer. >> > > Seattle is the closest practical peering point to Vancouver too, as far as I know, outside of academic/federal networks. > > > Joe > We have the PIX in Vancouver. However, you are correct in that most players in Vancouver also peer in Seattle so the point is moot. Maybe someone can correct me on this, but I don't know of any direct connectivity between Alaska and Vancouver - whereas with Seattle there is. In terms of connectivity, Seattle sounds like your best option. -M From jlewis at lewis.org Thu Mar 4 12:12:06 2010 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 4 Mar 2010 13:12:06 -0500 (EST) Subject: Redundant BGP for lower cost In-Reply-To: <4B8FEB0F.5060107@blastro.com> References: <4B8FEB0F.5060107@blastro.com> Message-ID: On Thu, 4 Mar 2010, Alex Thurlow wrote: > 2. Buy a Cisco/Juniper/whatever and then have the Quagga box as backup. > 3. I have a 6500 behind the router that's just doing switching. Could I have > something switch that to static route all traffic to one of my providers if > something happened to the router? The 6500 has Sup1A with MSFC2 running IOS > native. > > On the Cisco side, I see that we could probably run a 7200VXR with NPE-G1 > (about $6000 on ebay). Moving to the Sup720, even used is probably out of > our price range. If you were to upgrade the 6500 to a Sup720-3bxl or better, it would be a far superior platform for handling multiple gigabit ethernet circuits and full BGP than the NPE-G1. Sadly, the sup720 and required power supply and fan card upgrades would cost more than that 7200/NPE-G1, but it'll route considerably more traffic. I don't think you're going to get line-rate GigE from the G1. You will with the 6500. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From todd at velocitytelephone.com Thu Mar 4 12:44:01 2010 From: todd at velocitytelephone.com (Todd Mueller) Date: Thu, 04 Mar 2010 12:44:01 -0600 (CST) Subject: Ubiquti NanobridgeM Message-ID: <47B0A0C1ADE1ED4BA114480988FE878F2113F4@dc1.gv-office.local> Anyone have any real-world experience with Ubiquti's MIMO PTP equipment? We're looking to shoot data at distances of a few hundred feet up to 2-3 miles. Reliability? Latency? Other issues? Any feedback is appreciated. http://www.ubnt.com/nanobridge Thanks! Todd From meekjt at gmail.com Thu Mar 4 12:50:18 2010 From: meekjt at gmail.com (Jon Meek) Date: Thu, 4 Mar 2010 13:50:18 -0500 Subject: Ubiquti NanobridgeM In-Reply-To: <47B0A0C1ADE1ED4BA114480988FE878F2113F4@dc1.gv-office.local> References: <47B0A0C1ADE1ED4BA114480988FE878F2113F4@dc1.gv-office.local> Message-ID: There is a wealth of information in Ubiquti's forums: http://ubnt.com/forum/ Jon On Thu, Mar 4, 2010 at 1:44 PM, Todd Mueller wrote: > Anyone have any real-world experience with Ubiquti's MIMO PTP equipment? > We're looking to shoot data at distances of a few hundred feet up to 2-3 > miles. Reliability? Latency? Other issues? Any feedback is appreciated. > > http://www.ubnt.com/nanobridge > > Thanks! > > Todd > > From jared at puck.nether.net Thu Mar 4 12:52:10 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 4 Mar 2010 13:52:10 -0500 Subject: Ubiquti NanobridgeM In-Reply-To: <47B0A0C1ADE1ED4BA114480988FE878F2113F4@dc1.gv-office.local> References: <47B0A0C1ADE1ED4BA114480988FE878F2113F4@dc1.gv-office.local> Message-ID: <06EB7CA6-4BAE-4322-B540-C6F545F7BAD7@puck.nether.net> On Mar 4, 2010, at 1:44 PM, Todd Mueller wrote: > Anyone have any real-world experience with Ubiquti's MIMO PTP equipment? > We're looking to shoot data at distances of a few hundred feet up to 2-3 > miles. Reliability? Latency? Other issues? Any feedback is appreciated. > > http://www.ubnt.com/nanobridge > > Thanks! > > Todd > The newer equipment has not been released yet (the stuff that supports MCS-15 speeds). I have some NB-5G22 on-order and am waiting for it to ship. The suppliers should receive shipment later this month with early Apr availability. It seems to be in high demand. If you want anything faster than 50Mb/s SIMPLEX, you need one of the systems with the 400mhz processor. I've found this to be a limit in my lab environment. (tested w/ iperf both tcp/udp multiple streams, etc..) I do wish they had some better marking capabilities, so I could ask them to honor tos/qos generically. You have to play with the settings to get the best performance.. (I was just outside finishing the conduit/wiring et all for the termination). - Jared From tmagill at providecommerce.com Thu Mar 4 12:52:24 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Thu, 4 Mar 2010 10:52:24 -0800 Subject: IP4 Space Message-ID: So to start off, I'm new to following this list so if these points have already been beaten into the ground, feel free to tell me to shut up. So two things I wonder about the preservation of current IP4 space and delaying IP6 are: 1. Why don't providers use /31 addresses for P2P links? This works fine per rfc 3021 but nobody seems to believe it or use it. Are there any major manufacturers out there that do not support it? 2. Longer than /24 prefixes in global BGP table. The most obvious answer is that some hardware may not handle it... How is that hardware going to handle an IP6 table then? I have had several occasions where functionally I needed to advertise for different sites but only needed 20-30 addresses which is a complete waste of a /24. How hard would it be to start allowing /25s when compared to trying to roll out IP6? The intention of this isn't to start a "what's good or bad about IP6 and what still doesn't work" debate.. I'm just generally curious about how these two seem like easy ways to make more efficient use of what we have already. Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 mailto:tmagill at providecommerce.com provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers | redENVELOPE | Cherry Moon Farms | Shari's Berries From jared at puck.nether.net Thu Mar 4 13:03:12 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 4 Mar 2010 14:03:12 -0500 Subject: IP4 Space In-Reply-To: References: Message-ID: <41A016D3-E2D3-43B1-A58D-D338A3CAA3D8@puck.nether.net> On Mar 4, 2010, at 1:52 PM, Thomas Magill wrote: > 1. Why don't providers use /31 addresses for P2P links? This > works fine per rfc 3021 but nobody seems to believe it or use it. Are > there any major manufacturers out there that do not support it? Some vendors inconsistently support these on ethernet-framed interfaces and randomly break their code [again]. The one I am aware of is located on Tasman, and YMMV varies depending on what line of business synced code from whom and when. Nothing like upgrading a minor patch revision of software and losing your infrastructure link.... - Jared From sethm at rollernet.us Thu Mar 4 13:06:15 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 04 Mar 2010 11:06:15 -0800 Subject: IP4 Space In-Reply-To: References: Message-ID: <4B9004A7.2090907@rollernet.us> On 3/4/10 10:52 AM, Thomas Magill wrote: > So to start off, I'm new to following this list so if these points have > already been beaten into the ground, feel free to tell me to shut up. > > > > So two things I wonder about the preservation of current IP4 space and > delaying IP6 are: > > > > 1. Why don't providers use /31 addresses for P2P links? This > works fine per rfc 3021 but nobody seems to believe it or use it. Are > there any major manufacturers out there that do not support it? > I posed this to the list in January, and learned that apparently there are still some vendors whose products choke with presented with a /31. Search for thread "Using /31 for router links". ~Seth From marcoh at marcoh.net Thu Mar 4 13:10:44 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 4 Mar 2010 20:10:44 +0100 Subject: IP4 Space In-Reply-To: References: Message-ID: <4963F3C4-5E67-48DD-8254-CD8C3C2FA738@marcoh.net> > 1. Why don't providers use /31 addresses for P2P links? This > works fine per rfc 3021 but nobody seems to believe it or use it. Are > there any major manufacturers out there that do not support it? 99.999% of my customers are on /32 anyway. I could probably get a handfull of addresses (/25) back by renumbering the backbone links . But this will not save the world and they will most likely be used more rapidly as I can reclaim them. MarcoH From joelja at bogus.com Thu Mar 4 13:12:01 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 04 Mar 2010 11:12:01 -0800 Subject: IP4 Space In-Reply-To: References: Message-ID: <4B900601.9020709@bogus.com> On 03/04/2010 10:52 AM, Thomas Magill wrote: > 2. Longer than /24 prefixes in global BGP table. The most obvious > answer is that some hardware may not handle it... How is that hardware > going to handle an IP6 table then? I have had several occasions where > functionally I needed to advertise for different sites but only needed > 20-30 addresses which is a complete waste of a /24. How hard would it > be to start allowing /25s when compared to trying to roll out IP6? prefix deaggregatation beyond /24 is probably inevitable but that doesn't mean you want people to burn routing table slots on your equipment for /28s. That routing table slot is an externality that everyone has to pay for. By holding the line to the extent that it is held, a cap of the growth rate of your dfz fib that is roughly congruent with rir policy. handling the v6 table is not currently hard (~2600 prefixes) while long term the temptation to do TE is roughly that same in v6 as in v4, the prospect of having a bunch of non-aggregatable direct assignments should be much lower... From deleskie at gmail.com Thu Mar 4 13:16:25 2010 From: deleskie at gmail.com (jim deleskie) Date: Thu, 4 Mar 2010 15:16:25 -0400 Subject: Spamcop Blocks Facebook? In-Reply-To: <4B8F5E37.9030503@sorbs.net> References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> <4B8F5E37.9030503@sorbs.net> Message-ID: If I leave all boxes checked to send mail/notices/app requests to everyone in my list, or if I give FB my gmail password to pull all my contacts and send them an invite, its pure @ my request, sure FB is happy I do it, but it is no way spam. Its like calling 5 ICMP packets a DDoS. -jim On Thu, Mar 4, 2010 at 3:16 AM, Michelle Sullivan wrote: > deleskie at gmail.com wrote: >> Maybe I'm wrong on this, > > You are I'm afraid. > >> and I'm not a mailadmin anywhere nor have I been or pretended to have been in the past. But I'm pretty sure FB only sends you mail based on the prefrences you choose, and I know this is the answer you where given so mostly a statement. How does that equal spam :) >> > > The default is for everything 'on'. ?They will send to any email address > with notifications and mail regardless of signup and they don't honor > bounces in any 'email address doesn't work so don't mail it' lists they > might or might not employ. > > Regards, > > Michelle > > From bill at herrin.us Thu Mar 4 13:30:30 2010 From: bill at herrin.us (William Herrin) Date: Thu, 4 Mar 2010 14:30:30 -0500 Subject: IP4 Space In-Reply-To: References: Message-ID: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> On Thu, Mar 4, 2010 at 1:52 PM, Thomas Magill wrote: > 1. ? ? ? ?Why don't providers use /31 addresses for P2P links? ?This > works fine per rfc 3021 but nobody seems to believe it or use it. ?Are > there any major manufacturers out there that do not support it? Because those who want to hyper-optimize use a /32 loopback address on each router instead and rely on SNMP instead of Ping to determine whether an interface is up. > 2. ? ? ? Longer than /24 prefixes in global BGP table. ?The most obvious > answer is that some hardware may not handle it... That's the most obvious answer? On Thu, Mar 4, 2010 at 2:12 PM, Joel Jaeggli wrote: > handling the v6 table is not currently hard (~2600 prefixes) while long > term the temptation to do TE is roughly that same in v6 as in v4, the > prospect of having a bunch of non-aggregatable direct assignments should > be much lower... Because we expect far fewer end users to multihome tomorrow than do today? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rsk at gsp.org Thu Mar 4 13:25:15 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 4 Mar 2010 14:25:15 -0500 Subject: Spamcop Blocks Facebook? In-Reply-To: References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> <4B8F5E37.9030503@sorbs.net> Message-ID: <20100304192515.GA23038@gsp.org> On Thu, Mar 04, 2010 at 03:16:25PM -0400, jim deleskie wrote: > If I leave all boxes checked to send mail/notices/app requests to > everyone in my list, or if I give FB my gmail password to pull all my > contacts and send them an invite, its pure @ my request, sure FB is > happy I do it, but it is no way spam. This is dead wrong. You're not authorized to solicit bulk email on behalf of third parties: only they are. In the absence of solicitation from the *recipients*, bulk email is spam -- by definition. ---Rsk From deleskie at gmail.com Thu Mar 4 13:37:03 2010 From: deleskie at gmail.com (jim deleskie) Date: Thu, 4 Mar 2010 15:37:03 -0400 Subject: Spamcop Blocks Facebook? In-Reply-To: <20100304192515.GA23038@gsp.org> References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> <4B8F5E37.9030503@sorbs.net> <20100304192515.GA23038@gsp.org> Message-ID: I'm not going to both on this thread anymore.. waste of time. Sorry for the bulk mail/spam generated by my replies to nanog. I'll stop feeding the trolls now. -jim On Thu, Mar 4, 2010 at 3:25 PM, Rich Kulawiec wrote: > On Thu, Mar 04, 2010 at 03:16:25PM -0400, jim deleskie wrote: >> If I leave all boxes checked to send mail/notices/app requests to >> everyone in my list, or if I give FB my gmail password to pull all my >> contacts and send them an invite, its pure @ my request, sure FB is >> happy I do it, but it is no way spam. > > This is dead wrong. ?You're not authorized to solicit bulk email on behalf > of third parties: only they are. ?In the absence of solicitation from > the *recipients*, bulk email is spam -- by definition. > > ---Rsk > > > From Valdis.Kletnieks at vt.edu Thu Mar 4 13:45:33 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Mar 2010 14:45:33 -0500 Subject: Spamcop Blocks Facebook? In-Reply-To: Your message of "Thu, 04 Mar 2010 15:16:25 -0400." References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> <4B8F5E37.9030503@sorbs.net> Message-ID: <13007.1267731933@localhost> On Thu, 04 Mar 2010 15:16:25 -0400, jim deleskie said: > If I leave all boxes checked to send mail/notices/app requests to > everyone in my list, or if I give FB my gmail password to pull all my > contacts and send them an invite, its pure @ my request, sure FB is > happy I do it, but it is no way spam. Its like calling 5 ICMP packets > a DDoS. So if all 100 million zombied machines sent you 5 ICMP packets each, you wouldn't feel DDoSed at all? Yeah. Thought so. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From LarrySheldon at cox.net Thu Mar 4 13:58:22 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 04 Mar 2010 13:58:22 -0600 Subject: Spamcop Blocks Facebook? In-Reply-To: References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> <4B8F5E37.9030503@sorbs.net> Message-ID: <4B9010DE.1070104@cox.net> On 3/4/2010 1:16 PM, jim deleskie wrote: > If I leave all boxes checked to send mail/notices/app requests to > everyone in my list, or if I give FB my gmail password to pull all my > contacts and send them an invite, its pure @ my request, sure FB is > happy I do it, but it is no way spam. Its like calling 5 ICMP packets > a DDoS. Almost all spam is OK with the sender. It is the recipient of unsolicited bulk email that tend to be offended. As are the recipients of unsolicited commercial email. I tend to get terminally annoyed at unsolicited email and let [word for All-Mighty} sort them out. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Thu Mar 4 13:59:53 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 04 Mar 2010 13:59:53 -0600 Subject: Spamcop Blocks Facebook? In-Reply-To: References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> <4B8F5E37.9030503@sorbs.net> <20100304192515.GA23038@gsp.org> Message-ID: <4B901139.5070400@cox.net> On 3/4/2010 1:37 PM, jim deleskie wrote: > I'm not going to both on this thread anymore.. waste of time. Sorry > for the bulk mail/spam generated by my replies to nanog. > > I'll stop feeding the trolls now. Nice recovery attempt for a lost cause. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From tony at lava.net Thu Mar 4 14:10:34 2010 From: tony at lava.net (Antonio Querubin) Date: Thu, 4 Mar 2010 10:10:34 -1000 (HST) Subject: IP4 Space In-Reply-To: References: Message-ID: On Thu, 4 Mar 2010, Thomas Magill wrote: > 1. Why don't providers use /31 addresses for P2P links? This > works fine per rfc 3021 but nobody seems to believe it or use it. Are > there any major manufacturers out there that do not support it? > > 2. Longer than /24 prefixes in global BGP table. The most obvious > answer is that some hardware may not handle it... How is that hardware > going to handle an IP6 table then? I have had several occasions where > functionally I needed to advertise for different sites but only needed > 20-30 addresses which is a complete waste of a /24. How hard would it > be to start allowing /25s when compared to trying to roll out IP6? I think these qualify to be in an IPv6 FAQ if they're not already :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From DStaal at usa.net Thu Mar 4 14:28:47 2010 From: DStaal at usa.net (Daniel Staal) Date: Thu, 4 Mar 2010 15:28:47 -0500 Subject: Spamcop Blocks Facebook? In-Reply-To: <4B8F6D0F.80500@west.net> References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> <4B8F6D0F.80500@west.net> Message-ID: <9636135af6fd9f4cdaa901521e3b2681.squirrel@www.magehandbook.com> On Thu, March 4, 2010 3:19 am, Jay Hennigan wrote: > Facebook, like many similar sites, rather aggressively requests that its > users supply their email credentials so that the site can "invite" their > contacts. All of them. Every stinkin' email address they can mine. Also, Facebook sends mail from many different IP ranges, and non-Facebook (but @facebook.com) spam mail manages to get sent from overlapping IP ranges on occasion. Facebook tends to send mail from address+id at facebook.com, where 'address' is something like 'notifications' and 'id' is some random string. Some spam mail packages cannot distinguish this from address at facebook.com, which many of the spammers who try to spoof Facebook use (using the same common 'address'es as Facebook does). If you don't watch what you are doing, this can result in significant amounts of false-positives on manual sender-based blacklists. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From afx66 at hotmail.com Thu Mar 4 14:48:24 2010 From: afx66 at hotmail.com (Kaveh .) Date: Thu, 4 Mar 2010 12:48:24 -0800 Subject: Cisco hardware question Message-ID: Hello, I apologize if this is an unusual topic but I would like to know what this expert community thinks about this issue: We have noticed that a number of Cisco appliances we have recently purchased and paid (AS NEW), are being shipped as if they have been already used/refurbished. In other words, several times we have seen brand new Cisco hardware, out of the box, that has pre-existing configuration (Interfaces with Private IP addresses, static routes, etc ?) and in some cases even non-system files, like ?crashdump.txt? or additional IOS images. Most importantly our latest purchase; 2 'new' ASAs, contain a series of files named: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, etc ... . Based on some research it seems like that these files are 'recovery files' signaling bad/failing hard disks in these appliances. Anyone on thhis group has seen this before and if yes, are we supposed to blindly trust the vendor saying the hardware is new, safe and secure? The only way I can explain this is that the hardware has been refurbished or previously configured for reasons unknown to me. I think if customers pays for new hardware, they should get new hardware, even if refurbished hardware may be covered by Smartnet. Any thoughts or recommendations anyone? The last thing we want to do is to deploy faulty (or non secure) security appliances in production. :) Thank you Best regards _________________________________________________________________ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/201469228/direct/01/ From michael.holstein at csuohio.edu Thu Mar 4 15:02:37 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 04 Mar 2010 16:02:37 -0500 Subject: Spamcop Blocks Facebook? In-Reply-To: References: <1047489384-1267164733-cardhu_decombobulator_blackberry.rim.net-363809049-@bda006.bisx.prod.on.blackberry> <4B8F5E37.9030503@sorbs.net> Message-ID: <4B901FED.7050908@csuohio.edu> > Its like calling 5 ICMP packets a DDoS. > Okay .. here's a fun exercise (granted, as a .edu, the FB stats are statistically over-represented) .. this is yesterday. total email : 1,594,435 from @*facebook* : 17,274 (1.1%) Taken as a total of *legitimate* email that got through the spam filter .. "legit" email : 79,072 from @*facebook* : 16,383 (20.7%) Facebook's "notifications" account for ~21% of the mail making it past the border SPAM appliances. Top subjects (minus name field) : 1260 commented on your status... 993 sent you a message on Facebook... 826 wrote on your Wall... 743 commented on your wall post... 738 commented on her status... 704 added you as a friend on Facebook... 430 confirmed you as a friend on Facebook... 287 commented on your photo... 279 commented on his status... 260 commented on a photo of you on Facebook.. Cheers, Michael Holstein Cleveland State University From bfeeny at mac.com Thu Mar 4 15:05:09 2010 From: bfeeny at mac.com (Brian Feeny) Date: Thu, 04 Mar 2010 16:05:09 -0500 Subject: Cisco hardware question In-Reply-To: References: Message-ID: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> If you are getting Cisco hardware with configs on it or crashfiles, etc. Then no it is NOT new equipment. Who are you buying from? Are they a Gold partner on Cisco's partner locator? If not, then I have seen some seedy things, and of course i have seen seedy things with Gold partners too, I am just pointing out that the ability to compete and make margin get more and more difficult the lower the partner is on the totem pole and so desperation can drive certain behavior. In general from a cisco Gold partner you can expect as good as 35-40% or so on new equipment for a discount for regular deals. Special pricing for special projects you may be able to get a bit better, and maybe 1% or so better for general products from CDW or a big box company like them. If you are paying 50-60% off list for just individual items you order, then its likely not new and there is likely something shady going on, as no partner is going to get you some special discount pricing on a single 3845 for example. All of your good gold partners are going to charge around the same give or take a few percent on material. So find someone you can trust and just build a relationship. If your paying new prices for used gear then yes you are getting ripped off. I would be glad to recommend to you a reputable gold partner if you email me off list. Brian On Mar 4, 2010, at 3:48 PM, Kaveh . wrote: > > Hello, > > I apologize if this is an unusual topic but I would like to know what this expert community thinks about this issue: > > We have noticed that a number of Cisco appliances we have recently purchased and paid (AS NEW), are being shipped as if they have been already used/refurbished. In other words, several times we have seen brand new Cisco hardware, out of the box, that has pre-existing configuration (Interfaces with Private IP addresses, static routes, etc ?) and in some cases even non-system files, like ?crashdump.txt? or additional IOS images. Most importantly our latest purchase; 2 'new' ASAs, contain a series of files named: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, etc ... . Based on some research it seems like that these files are 'recovery files' signaling bad/failing hard disks in these appliances. > Anyone on thhis group has seen this before and if yes, are we supposed to blindly trust the vendor saying the hardware is new, safe and secure? > > The only way I can explain this is that the hardware has been refurbished or previously configured for reasons unknown to me. I think if customers pays for new hardware, they should get new hardware, even if refurbished hardware may be covered by Smartnet. > > Any thoughts or recommendations anyone? The last thing we want to do is to deploy faulty (or non secure) security appliances in production. :) > > Thank you > > Best regards > > _________________________________________________________________ > Hotmail: Free, trusted and rich email service. > http://clk.atdmt.com/GBL/go/201469228/direct/01/ From SBrown at clackesd.k12.or.us Thu Mar 4 15:14:53 2010 From: SBrown at clackesd.k12.or.us (Scott Brown/Clack/ESD) Date: Thu, 4 Mar 2010 13:14:53 -0800 Subject: Ubiquti NanobridgeM In-Reply-To: <47B0A0C1ADE1ED4BA114480988FE878F2113F4@dc1.gv-office.local> References: <47B0A0C1ADE1ED4BA114480988FE878F2113F4@dc1.gv-office.local> Message-ID: "Todd Mueller" wrote on 03/04/2010 10:44:01 AM: > From: "Todd Mueller" > To: <> > Date: 03/04/2010 10:44 AM > Subject: Ubiquti NanobridgeM > > Anyone have any real-world experience with Ubiquti's MIMO PTP equipment? > We're looking to shoot data at distances of a few hundred feet up to 2-3 > miles. Reliability? Latency? Other issues? Any feedback is appreciated. > > http://www.ubnt.com/nanobridge > > Thanks! > > Todd > At my previous job we had around 300 different Ubiquiti devices in use -- mainly as client devices for our CISCO 1522 mesh network, but some as bridges. For distances of a few hundred feet I would not use the NanoBridge, even with a reduced output power you would like overpower the receiver. The NanoStationM would work better for that. Reliability and latency... oiy. Well - these are plastic radios that are realllllly inexpensive. It takes forever and a day to get a RMA, so they suggest you just "buy spares" -- when the Airmax/MIMO series first shipped, it had buggy software. To this day the 5.1.x code is not as stable as most would like. Some have no issues, others are having tons of issues. To be honest, for critical links or links where reliability and performance are required 100% of the time, I'd look at RAD Airmux-400 (50Mbps FDX, they now have an asymmetrical version so you can do 80/20, 50/50, 90/10, etc -- but TDMoIP if you wish) -- complete link (integrated antennas) will be in sub-$5k range. But we are talking about carrier grade hardware. (China Telecom is a huge RAD customer, I believe Time Warner Telecom also uses them (according to the RAD site) Other brands, depending on throughput and distance requirements, are the Motorola PTP-500, 600, and 800 series. Dragonwave Horizon, and then Bridgewave. All of those provide carrier class performance, reliability, and support. Ubiquiti ---- they provide cheap radios that work well most of the time. My house is fed from a Powerstation2 bridge -- 12Mbps up, 12Mbps down - over 3 miles away. That tower site is fed by a RAD Airmux-400 though... 50Mbps at 6 miles. In my tests with traffic generators, the Airmux and Motorola radios handled more PPS than the Ubiquiti . Mbps isn't the only thing to look at. So if you are interested in shooting a lot of VoIP or video across the link, I can't say how well the Ubiquiti will work. I have an Asterisk PBX at home using SIP trunks from Vitelity and that works over the Ubiquiti radios - but that is 3 channels at most... If you want to give me a call sometime, send me an email directly and I'll shoot you my phone number -- I've worked with a lot of different radios ranging from cheap to "I could buy a car for that" and links from 100 feet to 30 miles. Scott Brown From MAdcock at hisna.com Thu Mar 4 15:22:21 2010 From: MAdcock at hisna.com (Adcock, Matt [HISNA]) Date: Thu, 4 Mar 2010 13:22:21 -0800 Subject: Cisco hardware question References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> Message-ID: Don't deploy the equipment, demand a refund, and report the reseller to Cisco. I agree completely with Brian - find a good Cisco partner and stick with them. Also, you can't legally buy used Cisco equipment and use the operating system. You can buy the equipment but the OS is absolutely non-transferrable. If you try to get SMARTNet on it red flags will go up and Cisco won't support it. Thanks, Matt Matt Adcock, Manager 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com 700 Hyundai Blvd. / Montgomery, AL 36105 P The average office worker uses 10,000 sheets of paper = 1.2 trees, per year By not printing this email, you?ve saved paper, ink and millions of trees From: Brian Feeny [mailto:bfeeny at mac.com] Sent: Thu 3/4/2010 3:05 PM To: Kaveh . Cc: nanog at nanog.org Subject: Re: Cisco hardware question If you are getting Cisco hardware with configs on it or crashfiles, etc. Then no it is NOT new equipment. Who are you buying from? Are they a Gold partner on Cisco's partner locator? If not, then I have seen some seedy things, and of course i have seen seedy things with Gold partners too, I am just pointing out that the ability to compete and make margin get more and more difficult the lower the partner is on the totem pole and so desperation can drive certain behavior. In general from a cisco Gold partner you can expect as good as 35-40% or so on new equipment for a discount for regular deals. Special pricing for special projects you may be able to get a bit better, and maybe 1% or so better for general products from CDW or a big box company like them. If you are paying 50-60% off list for just individual items you order, then its likely not new and there is likely something shady going on, as no partner is going to get you some special discount pricing on a single 3845 for example. All of your good gold partners are going to charge around the same give or take a few percent on material. So find someone you can trust and just build a relationship. If your paying new prices for used gear then yes you are getting ripped off. I would be glad to recommend to you a reputable gold partner if you email me off list. Brian On Mar 4, 2010, at 3:48 PM, Kaveh . wrote: > > Hello, > > I apologize if this is an unusual topic but I would like to know what this expert community thinks about this issue: > > We have noticed that a number of Cisco appliances we have recently purchased and paid (AS NEW), are being shipped as if they have been already used/refurbished. In other words, several times we have seen brand new Cisco hardware, out of the box, that has pre-existing configuration (Interfaces with Private IP addresses, static routes, etc ...) and in some cases even non-system files, like 'crashdump.txt' or additional IOS images. Most importantly our latest purchase; 2 'new' ASAs, contain a series of files named: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, etc ... . Based on some research it seems like that these files are 'recovery files' signaling bad/failing hard disks in these appliances. > Anyone on thhis group has seen this before and if yes, are we supposed to blindly trust the vendor saying the hardware is new, safe and secure? > > The only way I can explain this is that the hardware has been refurbished or previously configured for reasons unknown to me. I think if customers pays for new hardware, they should get new hardware, even if refurbished hardware may be covered by Smartnet. > > Any thoughts or recommendations anyone? The last thing we want to do is to deploy faulty (or non secure) security appliances in production. :) > > Thank you > > Best regards > > The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments > Hotmail: Free, trusted and rich email service. > http://clk.atdmt.com/GBL/go/201469228/direct/01/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1391 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1745 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1418 bytes Desc: not available URL: From sob at academ.com Thu Mar 4 15:44:30 2010 From: sob at academ.com (Stan Barber) Date: Thu, 4 Mar 2010 15:44:30 -0600 Subject: IP4 Space In-Reply-To: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> Message-ID: <84B6A1D7-8BAC-4542-A4C9-B3B7F5FC7F9C@academ.com> On Mar 4, 2010, at 1:30 PM, William Herrin wrote: > > Because we expect far fewer end users to multihome tomorrow than do today? > > Regards, > Bill Herrin I would suggest that the ratio of folks that will multihome under IPv6 versus those that won't will get smaller. I base that on an assumption that NAT (as we know it today) will be less prevalent as IPv6 usage grows. From tims at donet.com Thu Mar 4 15:48:54 2010 From: tims at donet.com (Tim Sanderson) Date: Thu, 4 Mar 2010 16:48:54 -0500 Subject: Cisco hardware question In-Reply-To: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> Message-ID: <175DA64769AE0F4498D813EDBFB44949C144DAF0A0@intexch07.internal.donet.com> >If you are getting Cisco hardware with configs on ... Then no it is NOT new equipment. That is not entirely true. Many Cisco models arrive with a default configuration - private IP addresses and all. All the new Cisco ASA's I've seen were this way. -- Tim Sanderson THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately. Thank you. From bill at herrin.us Thu Mar 4 15:53:45 2010 From: bill at herrin.us (William Herrin) Date: Thu, 4 Mar 2010 16:53:45 -0500 Subject: IP4 Space In-Reply-To: <84B6A1D7-8BAC-4542-A4C9-B3B7F5FC7F9C@academ.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <84B6A1D7-8BAC-4542-A4C9-B3B7F5FC7F9C@academ.com> Message-ID: <3c3e3fca1003041353q4e8a1945p72d57ef1303b62d0@mail.gmail.com> On Thu, Mar 4, 2010 at 4:44 PM, Stan Barber wrote: >> On Mar 4, 2010, at 1:30 PM, William Herrin wrote: >> Because we expect far fewer end users to multihome tomorrow than do today? > > I would suggest that the ratio of folks that will multihome under IPv6 > versus those that won't will get smaller. I base that on an assumption that > NAT (as we know it today) will be less prevalent as IPv6 usage grows. Alrighty then... -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From lists at iamchriswallace.com Thu Mar 4 16:07:56 2010 From: lists at iamchriswallace.com (Chris Wallace) Date: Thu, 4 Mar 2010 17:07:56 -0500 Subject: Alcatel-Lucent Message-ID: I am hoping to get some peoples opinions on Alcatel-Lucent routers. We are looking at the 7750 SR line and the 7450 ESS line. We are currently a Cisco shop but these would be deployed in a completely new network delivering mostly MPLS based services and DIA. Any comments are welcome, good and bad. ---Chris From joe at riversidecg.com Thu Mar 4 16:08:23 2010 From: joe at riversidecg.com (Joe Johnson) Date: Thu, 4 Mar 2010 16:08:23 -0600 Subject: Cisco hardware question In-Reply-To: <175DA64769AE0F4498D813EDBFB44949C144DAF0A0@intexch07.internal.donet.com> References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> <175DA64769AE0F4498D813EDBFB44949C144DAF0A0@intexch07.internal.donet.com> Message-ID: <154EDE9026B3D54F883B20F2BBDCF8794F55802E@exbe01.windows.riversidecg.com> Tim Sanderson wrote: > That is not entirely true. Many Cisco models arrive with a default configuration - private IP addresses and all. All the new Cisco ASA's I've seen were this way. Ditto on that. Of about 12 ASA 5505s and 5510s I've deployed in the last year, only one didn't come with a private IP enabled and a public interface set to DHCP. The only one that didn't was running about a year behind in firmware, while the rest came pre-loaded with the latest. Joe Johnson Chief Information Officer Riverside Consulting Group, Ltd. joe at riversidecg.com www.riversidecg.com From ken.gilmour at gmail.com Thu Mar 4 16:17:06 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Thu, 4 Mar 2010 16:17:06 -0600 Subject: Cisco hardware question In-Reply-To: References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> Message-ID: <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com> So if one were to purchase equipment, which is explicitly sold as "Refurbished" from, say www.impulsetech.us and they were to offer Smartnet on it, there is no guarantee that even if you paid for it, that Cisco would fulfil their support contract? Regards, Ken On 4 March 2010 15:22, Adcock, Matt [HISNA] wrote: > > Don't deploy the equipment, demand a refund, and report the reseller to > Cisco. I agree completely with Brian - find a good Cisco partner and stick > with them. Also, you can't legally buy used Cisco equipment and use the > operating system. You can buy the equipment but the OS is absolutely > non-transferrable. If you try to get SMARTNet on it red flags will go up > and Cisco won't support it. > > Thanks, > Matt > > > > Matt Adcock, Manager > 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com > 700 Hyundai Blvd. / Montgomery, AL 36105 > > P > The average office worker uses 10,000 sheets of paper = 1.2 trees, per year > By not printing this email, you?ve saved paper, ink and millions of trees > > > > From: Brian Feeny [mailto:bfeeny at mac.com] > Sent: Thu 3/4/2010 3:05 PM > To: Kaveh . > Cc: nanog at nanog.org > Subject: Re: Cisco hardware question > > > > > If you are getting Cisco hardware with configs on it or crashfiles, etc. > Then no it is NOT new equipment. Who are you buying from? Are they a Gold > partner on Cisco's partner locator? If not, then I have seen some seedy > things, and of course i have seen seedy things with Gold partners too, I am > just pointing out that the ability to compete and make margin get more and > more difficult the lower the partner is on the totem pole and so desperation > can drive certain behavior. > > In general from a cisco Gold partner you can expect as good as 35-40% or so > on new equipment for a discount for regular deals. Special pricing for > special projects you may be able to get a bit better, and maybe 1% or so > better for general products from CDW or a big box company like them. If you > are paying 50-60% off list for just individual items you order, then its > likely not new and there is likely something shady going on, as no partner > is going to get you some special discount pricing on a single 3845 for > example. > > All of your good gold partners are going to charge around the same give or > take a few percent on material. So find someone you can trust and just > build a relationship. If your paying new prices for used gear then yes you > are getting ripped off. > > I would be glad to recommend to you a reputable gold partner if you email > me off list. > > > Brian > > > On Mar 4, 2010, at 3:48 PM, Kaveh . wrote: > > > > > Hello, > > > > I apologize if this is an unusual topic but I would like to know what > this expert community thinks about this issue: > > > > We have noticed that a number of Cisco appliances we have recently > purchased and paid (AS NEW), are being shipped as if they have been already > used/refurbished. In other words, several times we have seen brand new Cisco > hardware, out of the box, that has pre-existing configuration (Interfaces > with Private IP addresses, static routes, etc ...) and in some cases even > non-system files, like 'crashdump.txt' or additional IOS images. Most > importantly our latest purchase; 2 'new' ASAs, contain a series of files > named: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, etc ... . Based on some > research it seems like that these files are 'recovery files' signaling > bad/failing hard disks in these appliances. > > Anyone on thhis group has seen this before and if yes, are we supposed to > blindly trust the vendor saying the hardware is new, safe and secure? > > > > The only way I can explain this is that the hardware has been refurbished > or previously configured for reasons unknown to me. I think if customers > pays for new hardware, they should get new hardware, even if refurbished > hardware may be covered by Smartnet. > > > > Any thoughts or recommendations anyone? The last thing we want to do is > to deploy faulty (or non secure) security appliances in production. :) > > > > Thank you > > > > Best regards > > > > > > The information in this email and any attachments are for the sole use of > the intended recipient and may contain privileged and confidential > information. If you are not the intended recipient, any use, disclosure, > copying or distribution of this message or attachment is strictly > prohibited. We have taken precautions to minimize the risk of transmitting > software viruses, but we advise you to carry out your own virus checks on > any attachment to this message. We cannot accept liability for any loss or > damage caused by software viruses. If you believe that you have received > this email in error, please contact the sender immediately and delete the > email and all of its attachments > > > Hotmail: Free, trusted and rich email service. > > http://clk.atdmt.com/GBL/go/201469228/direct/01/ > > > > > > > > > From sliplever at gmail.com Thu Mar 4 16:17:30 2010 From: sliplever at gmail.com (Dan Snyder) Date: Thu, 4 Mar 2010 17:17:30 -0500 Subject: Alcatel-Lucent In-Reply-To: References: Message-ID: The 7750 and 7450 are really good products. We were a pure Cisco shop about three years ago and then started using the 7750. We are very happy with the product. If you have any questions you can contact me off list. Sent from my iPhone On Mar 4, 2010, at 5:07 PM, Chris Wallace wrote: > I am hoping to get some peoples opinions on Alcatel-Lucent routers. > We are looking at the 7750 SR line and the 7450 ESS line. We are > currently a Cisco shop but these would be deployed in a completely > new network delivering mostly MPLS based services and DIA. Any > comments are welcome, good and bad. > > ---Chris From surfer at mauigateway.com Thu Mar 4 16:22:38 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Mar 2010 14:22:38 -0800 Subject: Alcatel-Lucent Message-ID: <20100304142238.1B9D28FE@resin14.mta.everyone.net> --- lists at iamchriswallace.com wrote: I am hoping to get some peoples opinions on Alcatel-Lucent routers. We are looking at the 7750 SR line and the 7450 ESS line. We are currently a Cisco shop but these would be deployed in a completely new network delivering mostly MPLS based services and DIA. Any comments are welcome, good and bad. --------------------------------------------------- We deploy these. They are very different from cisco (so there will be a big learning curve) and kick ass. Be sure to go to 7. as cflowd (their netflow) does not report correctly on things like ASN. scott From MAdcock at hisna.com Thu Mar 4 16:27:04 2010 From: MAdcock at hisna.com (Adcock, Matt [HISNA]) Date: Thu, 4 Mar 2010 14:27:04 -0800 Subject: Cisco hardware question References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com> Message-ID: According to previous conversations with my Cisco rep the answer is no - Cisco won't support it. I'm blind copying him on this and will pass on his response. Thanks, Matt ________________________________ From: Ken Gilmour [mailto:ken.gilmour at gmail.com] Sent: Thu 3/4/2010 4:17 PM To: Adcock, Matt [HISNA] Cc: nanog at nanog.org Subject: Re: Cisco hardware question So if one were to purchase equipment, which is explicitly sold as "Refurbished" from, say www.impulsetech.us and they were to offer Smartnet on it, there is no guarantee that even if you paid for it, that Cisco would fulfil their support contract? Regards, Ken On 4 March 2010 15:22, Adcock, Matt [HISNA] wrote: Don't deploy the equipment, demand a refund, and report the reseller to Cisco. I agree completely with Brian - find a good Cisco partner and stick with them. Also, you can't legally buy used Cisco equipment and use the operating system. You can buy the equipment but the OS is absolutely non-transferrable. If you try to get SMARTNet on it red flags will go up and Cisco won't support it. Thanks, Matt Matt Adcock, Manager 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com 700 Hyundai Blvd. / Montgomery, AL 36105 P The average office worker uses 10,000 sheets of paper = 1.2 trees, per year By not printing this email, you've saved paper, ink and millions of trees From: Brian Feeny [mailto:bfeeny at mac.com] Sent: Thu 3/4/2010 3:05 PM To: Kaveh . Cc: nanog at nanog.org Subject: Re: Cisco hardware question If you are getting Cisco hardware with configs on it or crashfiles, etc. Then no it is NOT new equipment. Who are you buying from? Are they a Gold partner on Cisco's partner locator? If not, then I have seen some seedy things, and of course i have seen seedy things with Gold partners too, I am just pointing out that the ability to compete and make margin get more and more difficult the lower the partner is on the totem pole and so desperation can drive certain behavior. In general from a cisco Gold partner you can expect as good as 35-40% or so on new equipment for a discount for regular deals. Special pricing for special projects you may be able to get a bit better, and maybe 1% or so better for general products from CDW or a big box company like them. If you are paying 50-60% off list for just individual items you order, then its likely not new and there is likely something shady going on, as no partner is going to get you some special discount pricing on a single 3845 for example. All of your good gold partners are going to charge around the same give or take a few percent on material. So find someone you can trust and just build a relationship. If your paying new prices for used gear then yes you are getting ripped off. I would be glad to recommend to you a reputable gold partner if you email me off list. Brian On Mar 4, 2010, at 3:48 PM, Kaveh . wrote: > > Hello, > > I apologize if this is an unusual topic but I would like to know what this expert community thinks about this issue: > > We have noticed that a number of Cisco appliances we have recently purchased and paid (AS NEW), are being shipped as if they have been already used/refurbished. In other words, several times we have seen brand new Cisco hardware, out of the box, that has pre-existing configuration (Interfaces with Private IP addresses, static routes, etc ...) and in some cases even non-system files, like 'crashdump.txt' or additional IOS images. Most importantly our latest purchase; 2 'new' ASAs, contain a series of files named: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, etc ... . Based on some research it seems like that these files are 'recovery files' signaling bad/failing hard disks in these appliances. > Anyone on thhis group has seen this before and if yes, are we supposed to blindly trust the vendor saying the hardware is new, safe and secure? > > The only way I can explain this is that the hardware has been refurbished or previously configured for reasons unknown to me. I think if customers pays for new hardware, they should get new hardware, even if refurbished hardware may be covered by Smartnet. > > Any thoughts or recommendations anyone? The last thing we want to do is to deploy faulty (or non secure) security appliances in production. :) > > Thank you > > Best regards > > The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments > Hotmail: Free, trusted and rich email service. > http://clk.atdmt.com/GBL/go/201469228/direct/01/ From surfer at mauigateway.com Thu Mar 4 16:32:56 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Mar 2010 14:32:56 -0800 Subject: Alcatel-Lucent Message-ID: <20100304143256.1B9D279B@resin14.mta.everyone.net> --- lists at iamchriswallace.com wrote: I am hoping to get some peoples opinions on Alcatel-Lucent routers. We are looking at the 7750 SR line and the 7450 ESS line. We are currently a Cisco shop but these would be deployed in a completely new network delivering mostly MPLS based services and DIA. Any comments are welcome, good and bad. --------------------------------------------------- BTW, one example is you only have to deal with one command set for all boxes within a given version. Good for programmatic thingies... :-) Also, SAM (the element management system) has gotten better as well. scott From mpetach at netflight.com Thu Mar 4 16:37:51 2010 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 4 Mar 2010 14:37:51 -0800 Subject: Desperately Seeking APNIC Message-ID: <63ac96a51003041437o3fe7ddc7i78acae067263a5c7@mail.gmail.com> Would anyone here know of any 24x7 contact at APNIC? The TXT records indicate they just signed the reverse zone for 203.in-addr.arpa today, and the delegations for our IP blocks disappeared when they did; and the helpdesk is currently not answering the phones: http://www.apnic.net/services/services-apnic-provides/helpdesk Trying to find someone there who can fix the delegations within the 84.203.in-addr.arpa. zone for 222 and 223 for us, and am running into dead ends. :/ Any pointers would be appreciated. Thanks! Matt From blakjak at blakjak.net Thu Mar 4 16:46:44 2010 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 5 Mar 2010 11:46:44 +1300 (NZDT) Subject: Desperately Seeking APNIC In-Reply-To: <63ac96a51003041437o3fe7ddc7i78acae067263a5c7@mail.gmail.com> References: <63ac96a51003041437o3fe7ddc7i78acae067263a5c7@mail.gmail.com> Message-ID: <2256.119.15.0.26.1267742804.squirrel@webmail.blakjak.net> On Fri, March 5, 2010 11:37 am, Matthew Petach wrote: > Would anyone here know of any 24x7 contact at APNIC? The TXT records > indicate they just signed the reverse zone for 203.in-addr.arpa today, and > the delegations for our IP blocks disappeared when they did; and the > helpdesk is > currently not answering the phones: > > http://www.apnic.net/services/services-apnic-provides/helpdesk > > Trying to find someone there who can fix the delegations within the > 84.203.in-addr.arpa. zone for 222 and 223 for us, and am running > into dead ends. :/ Any pointers would be appreciated. > You may have well had a relevant response by now, but the phone numbers at http://www.apnic.net/about-APNIC/organization/contact-APNIC are known to work, and their helpdesk opens in 15 minutes (Brisbane observing UTC+10). Mark. From woody at pch.net Thu Mar 4 16:57:32 2010 From: woody at pch.net (Bill Woodcock) Date: Thu, 4 Mar 2010 14:57:32 -0800 (PST) Subject: Desperately Seeking APNIC In-Reply-To: <63ac96a51003041437o3fe7ddc7i78acae067263a5c7@mail.gmail.com> References: <63ac96a51003041437o3fe7ddc7i78acae067263a5c7@mail.gmail.com> Message-ID: On Thu, 4 Mar 2010, Matthew Petach wrote: > Would anyone here know of any 24x7 contact at APNIC? The TXT records > indicate they just signed the reverse zone for 203.in-addr.arpa today, and > the delegations for our IP blocks disappeared when they did; and the helpdesk is > currently not answering the phones: Many of them are here in Kuala Lumpur for the APRICOT/APNIC meeting, of which today is the last day, and it's currently just coming up on 7am. So I'd guess you'll start getting answers in the next hour or so. If not, let me know, and I'll run down there and start trying to find someone to take a look at it. -Bill From marka at isc.org Thu Mar 4 16:57:57 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 05 Mar 2010 09:57:57 +1100 Subject: Desperately Seeking APNIC In-Reply-To: Your message of "Thu, 04 Mar 2010 14:37:51 -0800." <63ac96a51003041437o3fe7ddc7i78acae067263a5c7@mail.gmail.com> References: <63ac96a51003041437o3fe7ddc7i78acae067263a5c7@mail.gmail.com> Message-ID: <201003042257.o24Mvvas086554@drugs.dv.isc.org> In message <63ac96a51003041437o3fe7ddc7i78acae067263a5c7 at mail.gmail.com>, Matth ew Petach writes: > Would anyone here know of any 24x7 contact at APNIC? The TXT records > indicate they just signed the reverse zone for 203.in-addr.arpa today, and > the delegations for our IP blocks disappeared when they did; and the helpdesk > is > currently not answering the phones: > > http://www.apnic.net/services/services-apnic-provides/helpdesk > > Trying to find someone there who can fix the delegations within the > 84.203.in-addr.arpa. zone for 222 and 223 for us, and am running > into dead ends. :/ Any pointers would be appreciated. > > Thanks! > > Matt I would just try now. APNIC is based in Brisbane which is UTC +10:00. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From cvuljanic at gmail.com Thu Mar 4 16:59:30 2010 From: cvuljanic at gmail.com (Craig) Date: Thu, 4 Mar 2010 17:59:30 -0500 Subject: Alcatel-Lucent In-Reply-To: <20100304142238.1B9D28FE@resin14.mta.everyone.net> References: <20100304142238.1B9D28FE@resin14.mta.everyone.net> Message-ID: Very good routers. We have been using them for several years now. Very solid product, and very easy to setup services: ie vprn/ vpls/ epipe, etc. The qos on the box is very scalable. I could talk more about them off line with you or discuss more over phone. On Mar 4, 2010, at 5:22 PM, "Scott Weeks" wrote: > > > --- lists at iamchriswallace.com wrote: > I am hoping to get some peoples opinions on Alcatel-Lucent routers. > We are looking at the 7750 SR line and the 7450 ESS line. We are > currently a Cisco shop but these would be deployed in a completely > new network delivering mostly MPLS based services and DIA. Any > comments are welcome, good and bad. > --------------------------------------------------- > > > We deploy these. They are very different from cisco (so there will > be a big learning curve) and kick ass. Be sure to go to > 7. as cflowd (their netflow) does not report correctly on > things like ASN. > > scott > From mirotrem at gmail.com Thu Mar 4 17:14:46 2010 From: mirotrem at gmail.com (Chadwick Sorrell) Date: Thu, 4 Mar 2010 18:14:46 -0500 Subject: Alcatel-Lucent In-Reply-To: References: <20100304142238.1B9D28FE@resin14.mta.everyone.net> Message-ID: I'll have to second everything everyone is saying. Absolutely pleased with everything about them. Just wish I had more 7750s instead of 7450s. On Thu, Mar 4, 2010 at 5:59 PM, Craig wrote: > Very good routers. We have been using them for several years now. Very solid > product, and very easy to setup services: ie vprn/ vpls/ epipe, etc. > > The qos on the box is very scalable. I could talk more about them off line > with you or discuss more over phone. > > > > > > On Mar 4, 2010, at 5:22 PM, "Scott Weeks" wrote: > >> >> >> --- lists at iamchriswallace.com wrote: >> I am hoping to get some peoples opinions on Alcatel-Lucent routers. ?We >> are looking at the 7750 SR line and the 7450 ESS line. ?We are currently a >> Cisco shop but these would be deployed in a completely new network >> delivering mostly MPLS based services and DIA. ?Any comments are welcome, >> ?good and bad. >> --------------------------------------------------- >> >> >> We deploy these. ?They are very different from cisco (so there will be a >> big learning curve) and kick ass. ?Be sure to go to 7. as cflowd >> (their netflow) does not report correctly on things like ASN. >> >> scott >> > > From afx66 at hotmail.com Thu Mar 4 17:16:01 2010 From: afx66 at hotmail.com (Kaveh .) Date: Thu, 4 Mar 2010 15:16:01 -0800 Subject: Cisco hardware question In-Reply-To: References: , <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com>, , <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com>, Message-ID: Thanks for the feedback. Let me clarify a few things regarding issues that this thread has addressed so far: A) Pre-existing configs: What Tim and Joe mentioned is apparently correct. I was on phone with a few Cisco tech-reps earlier today and they told me that since version 8.2, they have been shipping ASAs with a default configuration, which explains the existence of private IP addresses on the inside interface, etc ... . B) What Cisco reps could NOT explain was the existence of a number of FSCK000#.REC files on these appliances. To be more specific each of ASAs in question contains 4 extra files: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, FSCK0003.REC). I said 'extra' because I asked the Cisco reps on phone to provide me a complete list of files that should exist on a brand new ASA, and the 4 files above were not part of the list and I think even they got confused when I mentioned the existence of these files. I could not find much info on these files, but a simple Google search indicates that these files may be 'recovery files' of Disks operating under Unix/Linux/BSD/etc /... kernel, indicating a dying hard drive. That would be enough to freak me out! Anyone can confirm this? C) SmarNet issue: I am a little confused on this. Since this purchase was for NEW equipment, and the devices were shipped by Cisco (at least that is what I read on the box; a Cisco warehouse in TX), then my understanding is that the devices came with the first 12 months of Smarnet anyway. So I will be surprised if they decline the contract renewal after the first year. After all they sold us the appliances as if they were new. How can decline renewal if I can prove that I paid them for new? D) Reseller: Yes, I appreciate the input. I will stick with a bigger name like CDW, next time, but again it appears to me that the devices were shipped from a Cisco warehouse in Texas, and not from the reseller's location. I would greatly appreciate any input, especially on B) Thank you Best regards > Subject: RE: Cisco hardware question > Date: Thu, 4 Mar 2010 14:27:04 -0800 > From: MAdcock at hisna.com > To: ken.gilmour at gmail.com > CC: nanog at nanog.org > > According to previous conversations with my Cisco rep the answer is no - Cisco won't support it. I'm blind copying him on this and will pass on his response. > > Thanks, > Matt > > ________________________________ > > From: Ken Gilmour [mailto:ken.gilmour at gmail.com] > Sent: Thu 3/4/2010 4:17 PM > To: Adcock, Matt [HISNA] > Cc: nanog at nanog.org > Subject: Re: Cisco hardware question > > > So if one were to purchase equipment, which is explicitly sold as "Refurbished" from, say www.impulsetech.us and they were to offer Smartnet on it, there is no guarantee that even if you paid for it, that Cisco would fulfil their support contract? > > Regards, > > Ken > > > On 4 March 2010 15:22, Adcock, Matt [HISNA] wrote: > > > > Don't deploy the equipment, demand a refund, and report the reseller to Cisco. I agree completely with Brian - find a good Cisco partner and stick with them. Also, you can't legally buy used Cisco equipment and use the operating system. You can buy the equipment but the OS is absolutely non-transferrable. If you try to get SMARTNet on it red flags will go up and Cisco won't support it. > > Thanks, > Matt > > > > Matt Adcock, Manager > 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com > 700 Hyundai Blvd. / Montgomery, AL 36105 > > P > The average office worker uses 10,000 sheets of paper = 1.2 trees, per year > By not printing this email, you've saved paper, ink and millions of trees > > > > From: Brian Feeny [mailto:bfeeny at mac.com] > Sent: Thu 3/4/2010 3:05 PM > To: Kaveh . > Cc: nanog at nanog.org > Subject: Re: Cisco hardware question > > > > > > If you are getting Cisco hardware with configs on it or crashfiles, etc. Then no it is NOT new equipment. Who are you buying from? Are they a Gold partner on Cisco's partner locator? If not, then I have seen some seedy things, and of course i have seen seedy things with Gold partners too, I am just pointing out that the ability to compete and make margin get more and more difficult the lower the partner is on the totem pole and so desperation can drive certain behavior. > > In general from a cisco Gold partner you can expect as good as 35-40% or so on new equipment for a discount for regular deals. Special pricing for special projects you may be able to get a bit better, and maybe 1% or so better for general products from CDW or a big box company like them. If you are paying 50-60% off list for just individual items you order, then its likely not new and there is likely something shady going on, as no partner is going to get you some special discount pricing on a single 3845 for example. > > All of your good gold partners are going to charge around the same give or take a few percent on material. So find someone you can trust and just build a relationship. If your paying new prices for used gear then yes you are getting ripped off. > > I would be glad to recommend to you a reputable gold partner if you email me off list. > > > Brian > > > On Mar 4, 2010, at 3:48 PM, Kaveh . wrote: > > > > > Hello, > > > > I apologize if this is an unusual topic but I would like to know what this expert community thinks about this issue: > > > > We have noticed that a number of Cisco appliances we have recently purchased and paid (AS NEW), are being shipped as if they have been already used/refurbished. In other words, several times we have seen brand new Cisco hardware, out of the box, that has pre-existing configuration (Interfaces with Private IP addresses, static routes, etc ...) and in some cases even non-system files, like 'crashdump.txt' or additional IOS images. Most importantly our latest purchase; 2 'new' ASAs, contain a series of files named: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, etc ... . Based on some research it seems like that these files are 'recovery files' signaling bad/failing hard disks in these appliances. > > Anyone on thhis group has seen this before and if yes, are we supposed to blindly trust the vendor saying the hardware is new, safe and secure? > > > > The only way I can explain this is that the hardware has been refurbished or previously configured for reasons unknown to me. I think if customers pays for new hardware, they should get new hardware, even if refurbished hardware may be covered by Smartnet. > > > > Any thoughts or recommendations anyone? The last thing we want to do is to deploy faulty (or non secure) security appliances in production. :) > > > > Thank you > > > > Best regards > > > > > > > The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments > > > > Hotmail: Free, trusted and rich email service. > > http://clk.atdmt.com/GBL/go/201469228/direct/01/ > > > > > > > > > > > _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/201469230/direct/01/ From ernesto at cs.fiu.edu Thu Mar 4 17:23:03 2010 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 4 Mar 2010 18:23:03 -0500 Subject: Cisco hardware question In-Reply-To: References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> Message-ID: <091ACE1A-B69E-4E6B-B180-9D3C8CD2C3A3@cs.fiu.edu> Step #2. Retain legal counsel or talk to general counsel. On Mar 4, 2010, at 4:22 PM, Adcock, Matt [HISNA] wrote: > > Don't deploy the equipment, demand a refund, and report the reseller to Cisco. I agree completely with Brian - find a good Cisco partner and stick with them. Also, you can't legally buy used Cisco equipment and use the operating system. You can buy the equipment but the OS is absolutely non-transferrable. If you try to get SMARTNet on it red flags will go up and Cisco won't support it. > > Thanks, > Matt > > > > Matt Adcock, Manager > 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com > 700 Hyundai Blvd. / Montgomery, AL 36105 > > P > The average office worker uses 10,000 sheets of paper = 1.2 trees, per year > By not printing this email, you?ve saved paper, ink and millions of trees > > > > From: Brian Feeny [mailto:bfeeny at mac.com] > Sent: Thu 3/4/2010 3:05 PM > To: Kaveh . > Cc: nanog at nanog.org > Subject: Re: Cisco hardware question > > > > > If you are getting Cisco hardware with configs on it or crashfiles, etc. Then no it is NOT new equipment. Who are you buying from? Are they a Gold partner on Cisco's partner locator? If not, then I have seen some seedy things, and of course i have seen seedy things with Gold partners too, I am just pointing out that the ability to compete and make margin get more and more difficult the lower the partner is on the totem pole and so desperation can drive certain behavior. > > In general from a cisco Gold partner you can expect as good as 35-40% or so on new equipment for a discount for regular deals. Special pricing for special projects you may be able to get a bit better, and maybe 1% or so better for general products from CDW or a big box company like them. If you are paying 50-60% off list for just individual items you order, then its likely not new and there is likely something shady going on, as no partner is going to get you some special discount pricing on a single 3845 for example. > > All of your good gold partners are going to charge around the same give or take a few percent on material. So find someone you can trust and just build a relationship. If your paying new prices for used gear then yes you are getting ripped off. > > I would be glad to recommend to you a reputable gold partner if you email me off list. > > > Brian > > > On Mar 4, 2010, at 3:48 PM, Kaveh . wrote: > >> >> Hello, >> >> I apologize if this is an unusual topic but I would like to know what this expert community thinks about this issue: >> >> We have noticed that a number of Cisco appliances we have recently purchased and paid (AS NEW), are being shipped as if they have been already used/refurbished. In other words, several times we have seen brand new Cisco hardware, out of the box, that has pre-existing configuration (Interfaces with Private IP addresses, static routes, etc ...) and in some cases even non-system files, like 'crashdump.txt' or additional IOS images. Most importantly our latest purchase; 2 'new' ASAs, contain a series of files named: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, etc ... . Based on some research it seems like that these files are 'recovery files' signaling bad/failing hard disks in these appliances. >> Anyone on thhis group has seen this before and if yes, are we supposed to blindly trust the vendor saying the hardware is new, safe and secure? >> >> The only way I can explain this is that the hardware has been refurbished or previously configured for reasons unknown to me. I think if customers pays for new hardware, they should get new hardware, even if refurbished hardware may be covered by Smartnet. >> >> Any thoughts or recommendations anyone? The last thing we want to do is to deploy faulty (or non secure) security appliances in production. :) >> >> Thank you >> >> Best regards >> >> > > The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments > >> Hotmail: Free, trusted and rich email service. >> http://clk.atdmt.com/GBL/go/201469228/direct/01/ > > > > > > > > From bc-list at beztech.net Thu Mar 4 17:23:57 2010 From: bc-list at beztech.net (Ben Carleton) Date: Thu, 4 Mar 2010 18:23:57 -0500 Subject: Cisco hardware question In-Reply-To: References: , <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com>, , <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com>, Message-ID: On Mar 4, 2010, at 6:16 PM, Kaveh . wrote: > > Thanks for the feedback. Let me clarify a few things regarding issues that this thread has addressed so far: > > A) Pre-existing configs: What Tim and Joe mentioned is apparently correct. I was on phone with a few Cisco tech-reps earlier today and they told me that since version 8.2, they have been shipping ASAs with a default configuration, which explains the existence of private IP addresses on the inside interface, etc ... . > > B) What Cisco reps could NOT explain was the existence of a number of FSCK000#.REC files on these appliances. To be more specific each of ASAs in question contains 4 extra files: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, FSCK0003.REC). I said 'extra' because I asked the Cisco reps on phone to provide me a complete list of files that should exist on a brand new ASA, and the 4 files above were not part of the list and I think even they got confused when I mentioned the existence of these files. > > I could not find much info on these files, but a simple Google search indicates that these files may be 'recovery files' of Disks operating under Unix/Linux/BSD/etc /... kernel, indicating a dying hard drive. That would be enough to freak me out! Anyone can confirm this? > > C) SmarNet issue: I am a little confused on this. Since this purchase was for NEW equipment, and the devices were shipped by Cisco (at least that is what I read on the box; a Cisco warehouse in TX), then my understanding is that the devices came with the first 12 months of Smarnet anyway. So I will be surprised if they decline the contract renewal after the first year. After all they sold us the appliances as if they were new. How can decline renewal if I can prove that I paid them for new? > > D) Reseller: Yes, I appreciate the input. I will stick with a bigger name like CDW, next time, but again it appears to me that the devices were shipped from a Cisco warehouse in Texas, and not from the reseller's location. > > > > I would greatly appreciate any input, especially on B) > > > > Thank you > > > > Best regards > > > >> Subject: RE: Cisco hardware question >> Date: Thu, 4 Mar 2010 14:27:04 -0800 >> From: MAdcock at hisna.com >> To: ken.gilmour at gmail.com >> CC: nanog at nanog.org >> >> According to previous conversations with my Cisco rep the answer is no - Cisco won't support it. I'm blind copying him on this and will pass on his response. >> >> Thanks, >> Matt >> >> ________________________________ >> >> From: Ken Gilmour [mailto:ken.gilmour at gmail.com] >> Sent: Thu 3/4/2010 4:17 PM >> To: Adcock, Matt [HISNA] >> Cc: nanog at nanog.org >> Subject: Re: Cisco hardware question >> >> >> So if one were to purchase equipment, which is explicitly sold as "Refurbished" from, say www.impulsetech.us and they were to offer Smartnet on it, there is no guarantee that even if you paid for it, that Cisco would fulfil their support contract? >> >> Regards, >> >> Ken >> >> >> On 4 March 2010 15:22, Adcock, Matt [HISNA] wrote: >> >> >> >> Don't deploy the equipment, demand a refund, and report the reseller to Cisco. I agree completely with Brian - find a good Cisco partner and stick with them. Also, you can't legally buy used Cisco equipment and use the operating system. You can buy the equipment but the OS is absolutely non-transferrable. If you try to get SMARTNet on it red flags will go up and Cisco won't support it. >> >> Thanks, >> Matt >> >> >> >> Matt Adcock, Manager >> 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com >> 700 Hyundai Blvd. / Montgomery, AL 36105 >> >> P >> The average office worker uses 10,000 sheets of paper = 1.2 trees, per year >> By not printing this email, you've saved paper, ink and millions of trees >> >> >> >> From: Brian Feeny [mailto:bfeeny at mac.com] >> Sent: Thu 3/4/2010 3:05 PM >> To: Kaveh . >> Cc: nanog at nanog.org >> Subject: Re: Cisco hardware question >> >> >> >> >> >> If you are getting Cisco hardware with configs on it or crashfiles, etc. Then no it is NOT new equipment. Who are you buying from? Are they a Gold partner on Cisco's partner locator? If not, then I have seen some seedy things, and of course i have seen seedy things with Gold partners too, I am just pointing out that the ability to compete and make margin get more and more difficult the lower the partner is on the totem pole and so desperation can drive certain behavior. >> >> In general from a cisco Gold partner you can expect as good as 35-40% or so on new equipment for a discount for regular deals. Special pricing for special projects you may be able to get a bit better, and maybe 1% or so better for general products from CDW or a big box company like them. If you are paying 50-60% off list for just individual items you order, then its likely not new and there is likely something shady going on, as no partner is going to get you some special discount pricing on a single 3845 for example. >> >> All of your good gold partners are going to charge around the same give or take a few percent on material. So find someone you can trust and just build a relationship. If your paying new prices for used gear then yes you are getting ripped off. >> >> I would be glad to recommend to you a reputable gold partner if you email me off list. >> >> >> Brian >> >> >> On Mar 4, 2010, at 3:48 PM, Kaveh . wrote: >> >>> >>> Hello, >>> >>> I apologize if this is an unusual topic but I would like to know what this expert community thinks about this issue: >>> >>> We have noticed that a number of Cisco appliances we have recently purchased and paid (AS NEW), are being shipped as if they have been already used/refurbished. In other words, several times we have seen brand new Cisco hardware, out of the box, that has pre-existing configuration (Interfaces with Private IP addresses, static routes, etc ...) and in some cases even non-system files, like 'crashdump.txt' or additional IOS images. Most importantly our latest purchase; 2 'new' ASAs, contain a series of files named: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, etc ... . Based on some research it seems like that these files are 'recovery files' signaling bad/failing hard disks in these appliances. >>> Anyone on thhis group has seen this before and if yes, are we supposed to blindly trust the vendor saying the hardware is new, safe and secure? >>> >>> The only way I can explain this is that the hardware has been refurbished or previously configured for reasons unknown to me. I think if customers pays for new hardware, they should get new hardware, even if refurbished hardware may be covered by Smartnet. >>> >>> Any thoughts or recommendations anyone? The last thing we want to do is to deploy faulty (or non secure) security appliances in production. :) >>> >>> Thank you >>> >>> Best regards >>> >>> >> >> >> The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments >> >> >>> Hotmail: Free, trusted and rich email service. >>> http://clk.atdmt.com/GBL/go/201469228/direct/01/ >> >> >> >> >> >> >> >> >> >> >> > > _________________________________________________________________ > Hotmail: Powerful Free email with security by Microsoft. > http://clk.atdmt.com/GBL/go/201469230/direct/01/ Kaveh: I can confirm with absolute certainty that fcsk is a Unix utility for determining if a hard disk is failing and optionally attempting a recovery. I have never heard of such output files, though. How big are they? If they are tiny, they could just be status reports or a save of the program's output. If they are large, they may represent backups of the flash memory. Ben From LarrySheldon at cox.net Thu Mar 4 17:30:07 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 04 Mar 2010 17:30:07 -0600 Subject: Spamcop Blocks Facebook? In-Reply-To: References: Message-ID: <4B90427F.5070904@cox.net> On 3/4/2010 2:35 PM, Dean Anderson wrote: > When there are 100 million facebook organizations, perhaps your > comparison will be appropriate. But even then, only if your friends > participate in all 100 million. Getting the occasional facebook, > linkedin, and plaxo invitation from your friends is not a DOS. Just > shows how you like to use inflamatory rhetoric. The strain of the > rhetoric is what exposes the scam, and your untoward willingness to go > along with the scammers. (Oh wait, that is the NANOG trademark, isn't > it?) Nobody said it would be a DOS. Some of us who know what we are talking about call it spam, since it meets every criterion for the term. I leave the NANOG trademark stuff to those of you who enjoy that. I took the liberty of stripping all the crosspos.....I mean CC:s off. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From afx66 at hotmail.com Thu Mar 4 17:36:22 2010 From: afx66 at hotmail.com (Kaveh .) Date: Thu, 4 Mar 2010 15:36:22 -0800 Subject: Cisco hardware question In-Reply-To: References: , <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com>, , <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com>, , Message-ID: Ben, Here is the output of # dir command - It includes all the files on disk0:/ ciscoasa# dir Directory of disk0:/ 134 -rwx 16275456 08:43:56 Jul 15 2009 asa821-k8.bin 135 -rwx 11348300 10:46:44 Jul 15 2009 asdm-621.bin 136 -rwx 20480 00:00:00 Jan 01 1980 FSCK0000.REC 3 drwx 4096 00:03:28 Jan 01 2003 log 10 drwx 4096 00:03:38 Jan 01 2003 crypto_archive 11 drwx 4096 00:04:00 Jan 01 2003 coredumpinfo 138 -rwx 61440 00:00:00 Jan 01 1980 FSCK0001.REC 139 -rwx 9526560 10:43:02 Jul 15 2009 csd_3.4.1108.pkg 140 drwx 4096 10:43:02 Jul 15 2009 sdesktop 141 -rwx 2397046 10:43:04 Jul 15 2009 anyconnect-wince-ARMv4I-2.3.0254-k9.pkg 142 -rwx 2648712 10:43:04 Jul 15 2009 anyconnect-win-2.3.0254-k9.pkg 143 -rwx 4217694 10:43:06 Jul 15 2009 anyconnect-macosx-i386-2.3.0254-k9.pkg 144 -rwx 4259411 10:43:10 Jul 15 2009 anyconnect-linux-2.3.0254-k9.pkg 145 -rwx 28672 00:00:00 Jan 01 1980 FSCK0002.REC 146 -rwx 4096 00:00:00 Jan 01 1980 FSCK0003.REC 255582208 bytes total (201719808 bytes free) Thanks > Subject: Re: Cisco hardware question > From: bc-list at beztech.net > Date: Thu, 4 Mar 2010 18:23:57 -0500 > To: afx66 at hotmail.com; nanog at nanog.org > > > On Mar 4, 2010, at 6:16 PM, Kaveh . wrote: > > > > > Thanks for the feedback. Let me clarify a few things regarding issues that this thread has addressed so far: > > > > A) Pre-existing configs: What Tim and Joe mentioned is apparently correct. I was on phone with a few Cisco tech-reps earlier today and they told me that since version 8.2, they have been shipping ASAs with a default configuration, which explains the existence of private IP addresses on the inside interface, etc ... . > > > > B) What Cisco reps could NOT explain was the existence of a number of FSCK000#.REC files on these appliances. To be more specific each of ASAs in question contains 4 extra files: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, FSCK0003.REC). I said 'extra' because I asked the Cisco reps on phone to provide me a complete list of files that should exist on a brand new ASA, and the 4 files above were not part of the list and I think even they got confused when I mentioned the existence of these files. > > > > I could not find much info on these files, but a simple Google search indicates that these files may be 'recovery files' of Disks operating under Unix/Linux/BSD/etc /... kernel, indicating a dying hard drive. That would be enough to freak me out! Anyone can confirm this? > > > > C) SmarNet issue: I am a little confused on this. Since this purchase was for NEW equipment, and the devices were shipped by Cisco (at least that is what I read on the box; a Cisco warehouse in TX), then my understanding is that the devices came with the first 12 months of Smarnet anyway. So I will be surprised if they decline the contract renewal after the first year. After all they sold us the appliances as if they were new. How can decline renewal if I can prove that I paid them for new? > > > > D) Reseller: Yes, I appreciate the input. I will stick with a bigger name like CDW, next time, but again it appears to me that the devices were shipped from a Cisco warehouse in Texas, and not from the reseller's location. > > > > > > > > I would greatly appreciate any input, especially on B) > > > > > > > > Thank you > > > > > > > > Best regards > > > > > > > >> Subject: RE: Cisco hardware question > >> Date: Thu, 4 Mar 2010 14:27:04 -0800 > >> From: MAdcock at hisna.com > >> To: ken.gilmour at gmail.com > >> CC: nanog at nanog.org > >> > >> According to previous conversations with my Cisco rep the answer is no - Cisco won't support it. I'm blind copying him on this and will pass on his response. > >> > >> Thanks, > >> Matt > >> > >> ________________________________ > >> > >> From: Ken Gilmour [mailto:ken.gilmour at gmail.com] > >> Sent: Thu 3/4/2010 4:17 PM > >> To: Adcock, Matt [HISNA] > >> Cc: nanog at nanog.org > >> Subject: Re: Cisco hardware question > >> > >> > >> So if one were to purchase equipment, which is explicitly sold as "Refurbished" from, say www.impulsetech.us and they were to offer Smartnet on it, there is no guarantee that even if you paid for it, that Cisco would fulfil their support contract? > >> > >> Regards, > >> > >> Ken > >> > >> > >> On 4 March 2010 15:22, Adcock, Matt [HISNA] wrote: > >> > >> > >> > >> Don't deploy the equipment, demand a refund, and report the reseller to Cisco. I agree completely with Brian - find a good Cisco partner and stick with them. Also, you can't legally buy used Cisco equipment and use the operating system. You can buy the equipment but the OS is absolutely non-transferrable. If you try to get SMARTNet on it red flags will go up and Cisco won't support it. > >> > >> Thanks, > >> Matt > >> > >> > >> > >> Matt Adcock, Manager > >> 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com > >> 700 Hyundai Blvd. / Montgomery, AL 36105 > >> > >> P > >> The average office worker uses 10,000 sheets of paper = 1.2 trees, per year > >> By not printing this email, you've saved paper, ink and millions of trees > >> > >> > >> > >> From: Brian Feeny [mailto:bfeeny at mac.com] > >> Sent: Thu 3/4/2010 3:05 PM > >> To: Kaveh . > >> Cc: nanog at nanog.org > >> Subject: Re: Cisco hardware question > >> > >> > >> > >> > >> > >> If you are getting Cisco hardware with configs on it or crashfiles, etc. Then no it is NOT new equipment. Who are you buying from? Are they a Gold partner on Cisco's partner locator? If not, then I have seen some seedy things, and of course i have seen seedy things with Gold partners too, I am just pointing out that the ability to compete and make margin get more and more difficult the lower the partner is on the totem pole and so desperation can drive certain behavior. > >> > >> In general from a cisco Gold partner you can expect as good as 35-40% or so on new equipment for a discount for regular deals. Special pricing for special projects you may be able to get a bit better, and maybe 1% or so better for general products from CDW or a big box company like them. If you are paying 50-60% off list for just individual items you order, then its likely not new and there is likely something shady going on, as no partner is going to get you some special discount pricing on a single 3845 for example. > >> > >> All of your good gold partners are going to charge around the same give or take a few percent on material. So find someone you can trust and just build a relationship. If your paying new prices for used gear then yes you are getting ripped off. > >> > >> I would be glad to recommend to you a reputable gold partner if you email me off list. > >> > >> > >> Brian > >> > >> > >> On Mar 4, 2010, at 3:48 PM, Kaveh . wrote: > >> > >>> > >>> Hello, > >>> > >>> I apologize if this is an unusual topic but I would like to know what this expert community thinks about this issue: > >>> > >>> We have noticed that a number of Cisco appliances we have recently purchased and paid (AS NEW), are being shipped as if they have been already used/refurbished. In other words, several times we have seen brand new Cisco hardware, out of the box, that has pre-existing configuration (Interfaces with Private IP addresses, static routes, etc ...) and in some cases even non-system files, like 'crashdump.txt' or additional IOS images. Most importantly our latest purchase; 2 'new' ASAs, contain a series of files named: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, etc ... . Based on some research it seems like that these files are 'recovery files' signaling bad/failing hard disks in these appliances. > >>> Anyone on thhis group has seen this before and if yes, are we supposed to blindly trust the vendor saying the hardware is new, safe and secure? > >>> > >>> The only way I can explain this is that the hardware has been refurbished or previously configured for reasons unknown to me. I think if customers pays for new hardware, they should get new hardware, even if refurbished hardware may be covered by Smartnet. > >>> > >>> Any thoughts or recommendations anyone? The last thing we want to do is to deploy faulty (or non secure) security appliances in production. :) > >>> > >>> Thank you > >>> > >>> Best regards > >>> > >>> > >> > >> > >> The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments > >> > >> > >>> Hotmail: Free, trusted and rich email service. > >>> http://clk.atdmt.com/GBL/go/201469228/direct/01/ > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > _________________________________________________________________ > > Hotmail: Powerful Free email with security by Microsoft. > > http://clk.atdmt.com/GBL/go/201469230/direct/01/ > > Kaveh: > > I can confirm with absolute certainty that fcsk is a Unix utility for determining if a hard disk is failing and optionally attempting a recovery. I have never heard of such output files, though. How big are they? If they are tiny, they could just be status reports or a save of the program's output. If they are large, they may represent backups of the flash memory. > > Ben _________________________________________________________________ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/201469228/direct/01/ From bruns at 2mbit.com Thu Mar 4 17:46:48 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 04 Mar 2010 16:46:48 -0700 Subject: Cisco hardware question In-Reply-To: References: , <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com>, , <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com>, Message-ID: <4B904668.4020305@2mbit.com> On 3/4/10 4:23 PM, Ben Carleton wrote: > > Kaveh: > > I can confirm with absolute certainty that fcsk is a Unix utility for > determining if a hard disk is failing and optionally attempting a > recovery. I have never heard of such output files, though. How big > are they? If they are tiny, they could just be status reports or a > save of the program's output. If they are large, they may represent > backups of the flash memory. > > Ben fsck is not just for failing hard drives. fsck is used any time you want to check a disk (may it be ssd, optical, magnetic) for any kind of errors or inconsistencies. It's a standard part of any UNIX toolkit. On Linux systems with ext2/3, you'll see lost+found, which is where stuff ends up if it can't be connected to an actual file entry. Sounds exactly like what those FSCK files are - DOS used to do this with scandisk. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From LarrySheldon at cox.net Thu Mar 4 17:50:46 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 04 Mar 2010 17:50:46 -0600 Subject: Spamcop Blocks Facebook? In-Reply-To: <16550.1267737299@localhost> References: <16550.1267737299@localhost> Message-ID: <4B904756.1070603@cox.net> On 3/4/2010 3:14 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 04 Mar 2010 15:35:47 EST, Dean Anderson said: >> elided. > > My To: list: > > To: jim deleskie Cc: nanog at nanog.org > > Your To: list: > > To: Valdis.Kletnieks at vt.edu, Shon Elliott , Adam > Stasiniewicz , Reed Loden , > Noel Butler , jim deleskie > , Matthew Dodd , > Benjamin Billon, Bob Poortinga > , Seth Mattinen , > Rich Kulawiec , "Tomas L. Byrnes" , > Michelle Sullivan , Jay Hennigan , > Larry Sheldon Cc: nanog at nanog.org, Betty Burke > > > And you *know* the cc: to nanog won't work. Sending mail to places > you *know* don't want it is the trademark of a spammer. No wonder > you whine so much about "it's not a DDoS/spam". Now I am really confused. When I said "Reply to all" ("reply to list" didn't light, because it turns out the list name was not in the bunch any place, so I deleted all the CC:s and added a "To: ". My usual practice is to delete all the To:s and Cc:s, leaving only the CC: nanog at nanog.org which seems to work fine. It would be nice if people would just reply to the list and leave all the CC;s from prior list traffic off. > Congrats. Only one or two people manage to exceed my legendary > patience and earn a personal entry in my procmailrc pointing to > /dev/null. Have a nice day. I'm surprised that I haven't been admonished--I have never been allowed to talk about operational stuff this long before. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From gordslater at ieee.org Thu Mar 4 17:54:11 2010 From: gordslater at ieee.org (gordon b slater) Date: Thu, 04 Mar 2010 23:54:11 +0000 Subject: Cisco hardware question In-Reply-To: <4B904668.4020305@2mbit.com> References: , <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> , , <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com> , <4B904668.4020305@2mbit.com> Message-ID: <1267746851.16514.5.camel@ub-g-d2> On Thu, 2010-03-04 at 16:46 -0700, Brielle Bruns wrote: > fsck is not just for failing hard drives. fsck is used any time you > want to check a disk (may it be ssd, optical, magnetic) for any kind of > errors or inconsistencies. It's a standard part of any UNIX toolkit. > > On Linux systems with ext2/3, you'll see lost+found, which is where > stuff ends up if it can't be connected to an actual file entry. Sounds > exactly like what those FSCK files are - DOS used to do this with scandisk. > beat me to it by a minute or two :) I'd guess (from a *nix-yness background) that the appliance is set up to automatically fsck a disk if it's dirty - `dirtiness` can be caused by thing like unexpected power cut as well as nasty things like hardware troubles. Appliances are prone to "power pulls" as they are usually headless. Some "diskless" appliances don't even bother to check , somewhat dismayingly. Not sure what the exact fs is on those boxes - anyone happen to know? - but from experience, I wouldn't be worrying too much (though I'd be very curious of course). Gord -- snort, snort, oink, oink From surfer at mauigateway.com Thu Mar 4 17:54:52 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Mar 2010 15:54:52 -0800 Subject: Alcatel-Lucent Message-ID: <20100304155452.1B9D3B7A@resin14.mta.everyone.net> --- mirotrem at gmail.com wrote: I'll have to second everything everyone is saying. Absolutely pleased with everything about them. Just wish I had more 7750s instead of 7450s. ---------------------------------------------- That reminds me of one thing that adds more complexity. We carry our internet in a VPRN for various reasons. The 7450s don't do BGP AFAIK in a VPRN. So, if your downstream BGP customers will physically attach to the 7450 you'll have to epipe over to a 7750 to terminate BGP. Then, since the epipe doesn't go down, you'll have to do BFD with the customer. Many customers say "do what?"... ;-) If you don't do BFD they'll have to wait for the BGP session to time out. scott From surfer at mauigateway.com Thu Mar 4 18:02:14 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 4 Mar 2010 16:02:14 -0800 Subject: Cisco hardware question Message-ID: <20100304160214.1B9D3859@resin14.mta.everyone.net> --- afx66 at hotmail.com wrote: B) What Cisco reps could NOT explain was the existence of a number of FSCK000#.REC files on these appliances. To be more specific each of ASAs in question contains 4 extra files: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, FSCK0003.REC). I said 'extra' because I asked the Cisco reps on phone to provide me a complete list of files that should exist on a brand new ASA, and the 4 files above were not part of the list and I think even they got confused when I mentioned the existence of these files. I could not find much info on these files, but a simple Google search indicates that these files may be 'recovery files' of Disks operating under Unix/Linux/BSD/etc /... kernel, indicating a dying hard drive. That would be enough to freak me out! Anyone can confirm this? [...] I would greatly appreciate any input, especially on B) --------------------------------------------------------- Send the files to a *nix box and run it through "strings". scott From netfortius at gmail.com Thu Mar 4 18:02:54 2010 From: netfortius at gmail.com (Stefan) Date: Thu, 4 Mar 2010 18:02:54 -0600 Subject: Cisco hardware question In-Reply-To: <1267746851.16514.5.camel@ub-g-d2> References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com> <4B904668.4020305@2mbit.com> <1267746851.16514.5.camel@ub-g-d2> Message-ID: Take the S/Ns and run them over by Cisco. On 3/4/10, gordon b slater wrote: > On Thu, 2010-03-04 at 16:46 -0700, Brielle Bruns wrote: > >> fsck is not just for failing hard drives. fsck is used any time you >> want to check a disk (may it be ssd, optical, magnetic) for any kind of >> errors or inconsistencies. It's a standard part of any UNIX toolkit. >> >> On Linux systems with ext2/3, you'll see lost+found, which is where >> stuff ends up if it can't be connected to an actual file entry. Sounds >> exactly like what those FSCK files are - DOS used to do this with >> scandisk. >> > > beat me to it by a minute or two :) > > I'd guess (from a *nix-yness background) that the appliance is set up to > automatically fsck a disk if it's dirty - `dirtiness` can be caused by > thing like unexpected power cut as well as nasty things like hardware > troubles. Appliances are prone to "power pulls" as they are usually > headless. > Some "diskless" appliances don't even bother to check , somewhat > dismayingly. > > Not sure what the exact fs is on those boxes - anyone happen to know? - > but from experience, I wouldn't be worrying too much (though I'd be very > curious of course). > > Gord > > -- > snort, snort, oink, oink > > > > > -- Sent from my mobile device ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From jfbeam at gmail.com Thu Mar 4 18:16:34 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 04 Mar 2010 19:16:34 -0500 Subject: Cisco hardware question In-Reply-To: References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com> Message-ID: On Thu, 04 Mar 2010 18:16:01 -0500, Kaveh . wrote: > A) Pre-existing configs: What Tim and Joe mentioned is apparently > correct. I was on phone with a few Cisco tech-reps earlier today and > they told me that since version 8.2, they have been shipping ASAs with a > default configuration, which explains the existence of private IP > addresses on the inside interface, etc ... . The Pix 501 was like that too. It was usable "out of the box". ... > I could not find much info on these files, but a simple Google search > indicates that these files may be 'recovery files' of Disks operating > under Unix/Linux/BSD/etc /... kernel, indicating a dying hard drive. > That would be enough to freak me out! Anyone can confirm this? It's not a "disk", but a CF (256M in your case.) It's a DOS FAT filesystem. The underlying linux OS runs dosfsck on every boot. There are *lots* of reasons why it would find things to recover. It's not necessarily an indication of Badness(tm). > C) SmarNet issue: I am a little confused on this. Since this purchase > was for NEW equipment, and the devices were shipped by Cisco (at least > that is what I read on the box; a Cisco warehouse in TX)... Not necessarily. I've seen a lot of boxes that appear to have come "direct" from Cisco, however, I know they came from a wholesaler's warehouse. (only one came direct from Cisco. from the factory in Malaysia.) From sethm at rollernet.us Thu Mar 4 18:20:08 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 04 Mar 2010 16:20:08 -0800 Subject: Cisco hardware question In-Reply-To: References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com> Message-ID: <4B904E38.4090607@rollernet.us> On 3/4/2010 16:16, Ricky Beam wrote: > > Not necessarily. I've seen a lot of boxes that appear to have come > "direct" from Cisco, however, I know they came from a wholesaler's > warehouse. (only one came direct from Cisco. from the factory in Malaysia.) > A lot of counterfeits come direct from the factory, too. ;) ~Seth From michael.holstein at csuohio.edu Thu Mar 4 18:42:39 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 04 Mar 2010 19:42:39 -0500 Subject: Spamcop Blocks Facebook? In-Reply-To: References: Message-ID: <4B90537F.6090709@csuohio.edu> > The evesdroppring reported below on csuohio.edu end-users Email is a > prima facie violation of the Electronic Communications Privacy Act. > I'm not sure why this got under your skin so badly, but aggregate statistics != eavesdropping. The SPAM appliance vendor software gathers these statistics, and actually includes the "good/bad" percentage on every junk summary that goes to the end users. Oh .. and what's up with this ? : http://www.av8.com/unauthtemplate Cheers, Michael Holstein Cleveland State University PS: I *am* abuse at . From gordslater at ieee.org Thu Mar 4 18:50:43 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 05 Mar 2010 00:50:43 +0000 Subject: Cisco hardware question In-Reply-To: References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com> Message-ID: <1267750243.16514.22.camel@ub-g-d2> On Thu, 2010-03-04 at 19:16 -0500, Ricky Beam wrote: > It's a DOS FAT > filesystem. hmmmm. hmmmmmmmmmm. FAT. Ah well, there must be a reason I guess. Not exactly what I'd choose for a high security snort box ;) But, horses for courses I suppose. Yes, as others say, good idea to check the s/n's with Cisco directly. You can _never_ be _too_ careful, both security-wise and financially. It's not exactly a cheap piece of equipment, service contracts and licences considered (and I don't mean the GPL one haha ) You can't rreally blame the frontline reps for not knowing what a fsck is, its a new tech concept. Post-80's on fact. Oops, another boot-up un in there, sorry. Humour aside, in fairness, I'm not sure an average rep would know much about QNX dumps either. *nix-y stuff puts you very close to the hardware and architectures. You see it all fly by in the logs and dmesg. Companies like cisco probably like to keep you at arms length from it. In this case you don't see the hardware so much but you "see" the bottom line of the invoice. That gives you all the right in the world to ask deep probing questions whenever you find things like this. A good manufacturer and supplier will answer them fully, though it may take some time to find the right clued-up tech internally. eg: Until you use ZFS you'd never believe the error rates on seemingly good hard drive systems, especially through "high-end" kit with supposedly safe "error correction". What you don't see doesn't worry you. Gord -- oink. oink. alert. oink. snort From MAdcock at hisna.com Thu Mar 4 19:17:36 2010 From: MAdcock at hisna.com (Adcock, Matt [HISNA]) Date: Thu, 4 Mar 2010 17:17:36 -0800 Subject: Cisco hardware question References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com> <4B904E38.4090607@rollernet.us> Message-ID: That's very true. They ship some out one door for Cisco and some out another door for gray/black market. One other thing to note - the discounts shown on the Web site previously mentioned here are not that greater than the ones I know Cisco gives many companies. Is it really worth taking a chance with one of the most critical parts of your infrastructure to save 10% or 15%. In my industry (automotive) and I think in many others the answer is absoutely not. Matt Matt Adcock, Manager 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com 700 Hyundai Blvd. / Montgomery, AL 36105 P The average office worker uses 10,000 sheets of paper = 1.2 trees, per year By not printing this email, you?ve saved paper, ink and millions of trees From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Thu 3/4/2010 6:20 PM To: nanog at nanog.org Subject: Re: Cisco hardware question On 3/4/2010 16:16, Ricky Beam wrote: > > Not necessarily. I've seen a lot of boxes that appear to have come > "direct" from Cisco, however, I know they came from a wholesaler's > warehouse. (only one came direct from Cisco. from the factory in Malaysia.) > A lot of counterfeits come direct from the factory, too. ;) ~Seth The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1391 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1745 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1418 bytes Desc: not available URL: From bfeeny at mac.com Thu Mar 4 19:21:01 2010 From: bfeeny at mac.com (Brian Feeny) Date: Thu, 04 Mar 2010 20:21:01 -0500 Subject: Cisco hardware question In-Reply-To: References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com> Message-ID: On Mar 4, 2010, at 6:16 PM, Kaveh . wrote: > > Thanks for the feedback. Let me clarify a few things regarding issues that this thread has addressed so far: > > A) Pre-existing configs: What Tim and Joe mentioned is apparently correct. I was on phone with a few Cisco tech-reps earlier today and they told me that since version 8.2, they have been shipping ASAs with a default configuration, which explains the existence of private IP addresses on the inside interface, etc ... . > > C) SmarNet issue: I am a little confused on this. Since this purchase was for NEW equipment, and the devices were shipped by Cisco (at least that is what I read on the box; a Cisco warehouse in TX), then my understanding is that the devices came with the first 12 months of Smarnet anyway. So I will be surprised if they decline the contract renewal after the first year. After all they sold us the appliances as if they were new. How can decline renewal if I can prove that I paid them for new? > Cisco devices don't "come" with SmartNet. They come with a manufacturer warranty which does not entitle you to the same support as smartnet (TAC support, software upgrades, 4 or 8 hour replacement, etc). You need to purchase SmartNet which is recommended. > D) Reseller: Yes, I appreciate the input. I will stick with a bigger name like CDW, next time, but again it appears to me that the devices were shipped from a Cisco warehouse in Texas, and not from the reseller's location. > > Buying from CDW is not worth the extra 1% or whatever. What I meant was find a good partner that has account managers that are there for you, engineers you can lean on for pre-sales support, and treats you with customer service. That could be anyone, but you have to find these partners as not every company these days understands what customer service is. They will answer all these types of questions you posted here as well. Brian > > I would greatly appreciate any input, especially on B) > > > > Thank you > > > > Best regards > > > >> Subject: RE: Cisco hardware question >> Date: Thu, 4 Mar 2010 14:27:04 -0800 >> From: MAdcock at hisna.com >> To: ken.gilmour at gmail.com >> CC: nanog at nanog.org >> >> According to previous conversations with my Cisco rep the answer is no - Cisco won't support it. I'm blind copying him on this and will pass on his response. >> >> Thanks, >> Matt >> >> ________________________________ >> >> From: Ken Gilmour [mailto:ken.gilmour at gmail.com] >> Sent: Thu 3/4/2010 4:17 PM >> To: Adcock, Matt [HISNA] >> Cc: nanog at nanog.org >> Subject: Re: Cisco hardware question >> >> >> So if one were to purchase equipment, which is explicitly sold as "Refurbished" from, say www.impulsetech.us and they were to offer Smartnet on it, there is no guarantee that even if you paid for it, that Cisco would fulfil their support contract? >> >> Regards, >> >> Ken >> >> >> On 4 March 2010 15:22, Adcock, Matt [HISNA] wrote: >> >> >> >> Don't deploy the equipment, demand a refund, and report the reseller to Cisco. I agree completely with Brian - find a good Cisco partner and stick with them. Also, you can't legally buy used Cisco equipment and use the operating system. You can buy the equipment but the OS is absolutely non-transferrable. If you try to get SMARTNet on it red flags will go up and Cisco won't support it. >> >> Thanks, >> Matt >> >> >> >> Matt Adcock, Manager >> 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com >> 700 Hyundai Blvd. / Montgomery, AL 36105 >> >> P >> The average office worker uses 10,000 sheets of paper = 1.2 trees, per year >> By not printing this email, you've saved paper, ink and millions of trees >> >> >> >> From: Brian Feeny [mailto:bfeeny at mac.com] >> Sent: Thu 3/4/2010 3:05 PM >> To: Kaveh . >> Cc: nanog at nanog.org >> Subject: Re: Cisco hardware question >> >> >> >> >> >> If you are getting Cisco hardware with configs on it or crashfiles, etc. Then no it is NOT new equipment. Who are you buying from? Are they a Gold partner on Cisco's partner locator? If not, then I have seen some seedy things, and of course i have seen seedy things with Gold partners too, I am just pointing out that the ability to compete and make margin get more and more difficult the lower the partner is on the totem pole and so desperation can drive certain behavior. >> >> In general from a cisco Gold partner you can expect as good as 35-40% or so on new equipment for a discount for regular deals. Special pricing for special projects you may be able to get a bit better, and maybe 1% or so better for general products from CDW or a big box company like them. If you are paying 50-60% off list for just individual items you order, then its likely not new and there is likely something shady going on, as no partner is going to get you some special discount pricing on a single 3845 for example. >> >> All of your good gold partners are going to charge around the same give or take a few percent on material. So find someone you can trust and just build a relationship. If your paying new prices for used gear then yes you are getting ripped off. >> >> I would be glad to recommend to you a reputable gold partner if you email me off list. >> >> >> Brian >> >> >> On Mar 4, 2010, at 3:48 PM, Kaveh . wrote: >> >>> >>> Hello, >>> >>> I apologize if this is an unusual topic but I would like to know what this expert community thinks about this issue: >>> >>> We have noticed that a number of Cisco appliances we have recently purchased and paid (AS NEW), are being shipped as if they have been already used/refurbished. In other words, several times we have seen brand new Cisco hardware, out of the box, that has pre-existing configuration (Interfaces with Private IP addresses, static routes, etc ...) and in some cases even non-system files, like 'crashdump.txt' or additional IOS images. Most importantly our latest purchase; 2 'new' ASAs, contain a series of files named: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, etc ... . Based on some research it seems like that these files are 'recovery files' signaling bad/failing hard disks in these appliances. >>> Anyone on thhis group has seen this before and if yes, are we supposed to blindly trust the vendor saying the hardware is new, safe and secure? >>> >>> The only way I can explain this is that the hardware has been refurbished or previously configured for reasons unknown to me. I think if customers pays for new hardware, they should get new hardware, even if refurbished hardware may be covered by Smartnet. >>> >>> Any thoughts or recommendations anyone? The last thing we want to do is to deploy faulty (or non secure) security appliances in production. :) >>> >>> Thank you >>> >>> Best regards >>> >>> >> >> >> The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments >> >> >>> Hotmail: Free, trusted and rich email service. >>> http://clk.atdmt.com/GBL/go/201469228/direct/01/ >> >> >> >> >> >> >> >> >> >> >> > > _________________________________________________________________ > Hotmail: Powerful Free email with security by Microsoft. > http://clk.atdmt.com/GBL/go/201469230/direct/01/ From bfeeny at mac.com Thu Mar 4 19:25:56 2010 From: bfeeny at mac.com (Brian Feeny) Date: Thu, 04 Mar 2010 20:25:56 -0500 Subject: Cisco hardware question In-Reply-To: References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com> <4B904E38.4090607@rollernet.us> Message-ID: <02FDFBCC-71E6-444B-80CB-45B462E88C71@mac.com> On most transactions, good reputable cisco partners are making about 3% on the front end. Most good partners make their money off services, and they hire highly trained engineers to deliver projects. Cisco hardware is like any other retail business, there is not deep margins. So trying to get 38% off from CDW vs. taking 37% off from the hometown team you can trust, meet face to face with, talk to the "boss" if you need to......its just not worth it. This same thing holds true with network operators to some extent. Some of the best businesses to goto for good support, colocation, transit, etc. Are you mid tier guys with highly clued staff and the need to deliver good service in order to stay competitive. Brian On Mar 4, 2010, at 8:17 PM, Adcock, Matt [HISNA] wrote: > > That's very true. They ship some out one door for Cisco and some out another door for gray/black market. > > One other thing to note - the discounts shown on the Web site previously mentioned here are not that greater than the ones I know Cisco gives many companies. Is it really worth taking a chance with one of the most critical parts of your infrastructure to save 10% or 15%. In my industry (automotive) and I think in many others the answer is absoutely not. > > Matt > > > > Matt Adcock, Manager > 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com > 700 Hyundai Blvd. / Montgomery, AL 36105 > > P > The average office worker uses 10,000 sheets of paper = 1.2 trees, per year > By not printing this email, you?ve saved paper, ink and millions of trees > > > > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Thu 3/4/2010 6:20 PM > To: nanog at nanog.org > Subject: Re: Cisco hardware question > > > > On 3/4/2010 16:16, Ricky Beam wrote: >> >> Not necessarily. I've seen a lot of boxes that appear to have come >> "direct" from Cisco, however, I know they came from a wholesaler's >> warehouse. (only one came direct from Cisco. from the factory in Malaysia.) >> > > A lot of counterfeits come direct from the factory, too. ;) > > ~Seth > > > > > > > > The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments > > From owen at delong.com Thu Mar 4 19:55:26 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Mar 2010 09:55:26 +0800 Subject: IP4 Space In-Reply-To: <4B9004A7.2090907@rollernet.us> References: <4B9004A7.2090907@rollernet.us> Message-ID: <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> Folks, I know that IPv4 is down to bread crumbs. That's why I'm ready for IPv6 and hopefully the rest of you are or will be soon. However, let's consider how much address space is saved by going from /30 to /31 on every point-to-point link in the internet... Let's assume that there are ~1 million routers on the internet with an average of 8 point to point interfaces. (I think there are probably more like 1/4 million and the average is probably more like 2, but, absent real numbers, I'll be uber-conservative). 8 million /30s is 32 million IPs, or, 2 /8s world-wide. 8 million /31s is 16 million IPs, or, 1 /8 world-wide. We burn roughly 14 /8s per year in new allocations and assignments. So, assuming: 1. There are actually 8 million point to point links in the internet 2. All of them are currently /30s 3. Absolutely optimum use of addresses for all those links 4. All of them are converted to /31s (none of these assumptions is likely in fact) The most we could achieve would be to extend IPv4 freepool lifespan by roughly 26 days. Given the amount of effort sqeezing useful addresses out of such a conversion would require, I proffer that such effort is better spent moving towards IPv6 dual stack on your networks. Owen From Valdis.Kletnieks at vt.edu Thu Mar 4 20:18:59 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Mar 2010 21:18:59 -0500 Subject: Spamcop Blocks Facebook? In-Reply-To: Your message of "Thu, 04 Mar 2010 19:42:39 EST." <4B90537F.6090709@csuohio.edu> References: <4B90537F.6090709@csuohio.edu> Message-ID: <8348.1267755539@localhost> On Thu, 04 Mar 2010 19:42:39 EST, Michael Holstein said: > > > The evesdroppring reported below on csuohio.edu end-users Email is a > > prima facie violation of the Electronic Communications Privacy Act. > > > > I'm not sure why this got under your skin so badly, but aggregate > statistics != eavesdropping. The SPAM appliance vendor software gathers > these statistics, and actually includes the "good/bad" percentage on > every junk summary that goes to the end users. IANAL, but a quick summary (if the details actually matter, run it past a lawyer you're paying): When it's in flight on the wire, courts have held that the various wiretap statutes apply. Once you stick it in somebody's mailbox and it's doing 7200RPM on oxide waiting for the user to read it, ECPA applies. There's been a lot of case law on this already, because the paperwork needed (subpoena or wiretap order) for an LEO is different in each case. Now, if you're doing summary info on From:/To: info, you're almost certainly doing it while the mail is still "in flight" as you receive it, so the wiretap rules apply. And 18 USC 2511 (2)(a)(i) specifically says: "It shall not be unlawful under this chapter for an operator of a switchboard, or an officer, employee, or agent of a provider of wire or electronic communication service, whose facilities are used in the transmission of a wire or electronic communication, to intercept, disclose, or use that communication in the normal course of his employment while engaged in any activity which is a necessary incident to the rendition of his service or to the protection of the rights or property of the provider of that service, except that a provider of wire communication service to the public shall not utilize service observing or random monitoring except for mechanical or service quality control checks." csuohio's monitoring is arguably "service monitoring" - but keeping track of aggregate traffic levels so you can manage them is equally obviously a "service quality control check". (And "quality control check" apparently covers almost any aggregate statistics you keep as input for operational config/tuning decisions). http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00002511----000-.html (Again, IANAL, and I'm sure somebody who IAL will correct me if I've egregiously mis-stated the above. :) > PS: I *am* abuse at . Admittedly, I'm not - but he's got the cubicle across the aisle from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From newton at internode.com.au Thu Mar 4 20:30:22 2010 From: newton at internode.com.au (Mark Newton) Date: Fri, 5 Mar 2010 13:00:22 +1030 Subject: IP4 Space In-Reply-To: <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> Message-ID: <57A9820F-A2F0-4497-8909-1D2676AD5F0F@internode.com.au> On 05/03/2010, at 12:25 PM, Owen DeLong wrote: > The most we could achieve would be to extend IPv4 freepool lifespan > by roughly 26 days. Given the amount of effort sqeezing useful > addresses out of such a conversion would require, I proffer that > such effort is better spent moving towards IPv6 dual stack on your > networks. ... and, unstated behind that, is the observation that pretty much any proposed effort to squeeze more time out of IPv4 will inevitably have the same answer :-) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From Valdis.Kletnieks at vt.edu Thu Mar 4 20:35:44 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 04 Mar 2010 21:35:44 -0500 Subject: IP4 Space In-Reply-To: Your message of "Fri, 05 Mar 2010 09:55:26 +0800." <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> Message-ID: <8849.1267756544@localhost> On Fri, 05 Mar 2010 09:55:26 +0800, Owen DeLong said: > So, assuming: > 1. There are actually 8 million point to point links in the internet > 2. All of them are currently /30s > 3. Absolutely optimum use of addresses for all those links > 4. All of them are converted to /31s > > (none of these assumptions is likely in fact) In particular, if your site has 256 PTP links, you can convert from /30s to / 31s, save 128 IPs, but then trying to *actually use them* effectively outside your AS ends up sounding like this: "Eat your Brussel sprouts. Don't you know there's kids starving in Africa" "OK, you can send my sprouts to them..." :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tmagill at providecommerce.com Thu Mar 4 20:41:17 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Thu, 4 Mar 2010 18:41:17 -0800 Subject: IP4 Space In-Reply-To: <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> Message-ID: >The most we could achieve would be to extend IPv4 freepool lifespan >by roughly 26 days. Given the amount of effort sqeezing useful >addresses out of such a conversion would require, I proffer that >such effort is better spent moving towards IPv6 dual stack on your >networks. A /8 sounded like a decent amount until you put it that way. Nice empirical data, even though its based completely on assumptions. But if it is even in the ballpark.. It is pretty obvious it isn't worth the effort. I just didn't have even have a guess at the number /30s out there. I've been on board with rolling out IP6 but the SPs I've talked to are all '...about to start trying to possibly think about extending a beta to a small portion of some customers' or something along those lines. This led me to believe that SPs are way behind on this considering the expected exhaustion of IP4 space. Also, and not sure how to phrase this, but is there any behind-the-scenes push to start moving closed systems that run over the Internet to IP6 with the goal of freeing up any of the IP4 space for more public-facing systems and end-users? Is the thought of anyone giving up IP4 space after they have moved to IP6 just a silly notion? I could see a future where infrastructure services like voice run on IP6 while common 'web services' stay on IP4. Once again, sorry if I'm bringing up anything that has been beaten to death. I just come from the corporate side of this and the SP side is just a point of interest for me so I like to hear that point of view. From steve at ibctech.ca Thu Mar 4 21:05:43 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 04 Mar 2010 22:05:43 -0500 Subject: IP4 Space In-Reply-To: <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> Message-ID: <4B907507.800@ibctech.ca> On 2010.03.04 20:55, Owen DeLong wrote: > Folks, I know that IPv4 is down to bread crumbs. > > That's why I'm ready for IPv6 and hopefully the rest of you are or will be soon. > > However, let's consider how much address space is saved by going from /30 to /31 > on every point-to-point link in the internet... > > Let's assume that there are ~1 million routers on the internet with an average of 8 > point to point interfaces. (I think there are probably more like 1/4 million and the > average is probably more like 2, but, absent real numbers, I'll be uber-conservative). > > 8 million /30s is 32 million IPs, or, 2 /8s world-wide. > 8 million /31s is 16 million IPs, or, 1 /8 world-wide. > > We burn roughly 14 /8s per year in new allocations and assignments. > > So, assuming: > 1. There are actually 8 million point to point links in the internet > 2. All of them are currently /30s > 3. Absolutely optimum use of addresses for all those links > 4. All of them are converted to /31s > > (none of these assumptions is likely in fact) > > The most we could achieve would be to extend IPv4 freepool lifespan > by roughly 26 days. Given the amount of effort sqeezing useful > addresses out of such a conversion would require, I proffer that > such effort is better spent moving towards IPv6 dual stack on your > networks. Owen, thanks for this picturesque description. Whoever recommended the FAQ, add this equation into it. I *wholeheartedly* agree with Owen's assessment. Even spending time trying to calculate a rebuttal to his numbers is better spent moving toward dual-stack ;) Nice. Steve ps. and I'm just tiny. I just enjoy seeing reports of the big boys moving forward, and watching my v6 routing table grow... From rubensk at gmail.com Thu Mar 4 21:22:18 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 5 Mar 2010 00:22:18 -0300 Subject: Cisco hardware question In-Reply-To: References: Message-ID: <6bb5f5b11003041922t158be6acm9f66ad89953af113@mail.gmail.com> > We have noticed that a number of Cisco appliances we have recently purchased and paid (AS NEW), are being shipped as if they have been already used/refurbished. In other words, several times we have seen brand new Cisco hardware, out of the box, that has pre-existing configuration (Interfaces with Private IP addresses, static routes, etc ?) and in some cases even non-system files, like ?crashdump.txt? or additional IOS images. Most importantly our latest purchase; 2 'new' ASAs, contain a series of files named: FSCK0000.REC, FSCK0001.REC, FSCK0002.REC, etc ... . Based on some research it seems like that these files are 'recovery files' signaling bad/failing hard disks in these appliances. May be you purchased a truly brand new Cisco appliance where the HDD is refurbished, possibly due to: - Cisco cutting costs on parts procurement - Cisco supplier cutting costs by refurbishing HDD - Cisco contractor that does assembly making extra revenue by selling new HDDs that Cisco bought and replacing them with refurbished ones Rubens From steve at ibctech.ca Thu Mar 4 21:26:57 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 04 Mar 2010 22:26:57 -0500 Subject: IP4 Space In-Reply-To: <3c3e3fca1003041353q4e8a1945p72d57ef1303b62d0@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <84B6A1D7-8BAC-4542-A4C9-B3B7F5FC7F9C@academ.com> <3c3e3fca1003041353q4e8a1945p72d57ef1303b62d0@mail.gmail.com> Message-ID: <4B907A01.5040606@ibctech.ca> On 2010.03.04 16:53, William Herrin wrote: > On Thu, Mar 4, 2010 at 4:44 PM, Stan Barber wrote: >>> On Mar 4, 2010, at 1:30 PM, William Herrin wrote: >>> Because we expect far fewer end users to multihome tomorrow than do today? >> >> I would suggest that the ratio of folks that will multihome under IPv6 >> versus those that won't will get smaller. I base that on an assumption that >> NAT (as we know it today) will be less prevalent as IPv6 usage grows. > > Alrighty then... heh. Stan, you've got things backwards, no matter which direction you are looking at things from. I'm thinking that you may have written the sentence incorrectly. It's unfortunate, but it is reality. Have you reviewed your RIR policy lately? v6 will be flying out the window soon, and your local RIR may be assigning PI space like candy. Welcome IPv6. Steve From steve at ibctech.ca Thu Mar 4 21:29:28 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Thu, 04 Mar 2010 22:29:28 -0500 Subject: IP4 Space In-Reply-To: <4B907A01.5040606@ibctech.ca> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <84B6A1D7-8BAC-4542-A4C9-B3B7F5FC7F9C@academ.com> <3c3e3fca1003041353q4e8a1945p72d57ef1303b62d0@mail.gmail.com> <4B907A01.5040606@ibctech.ca> Message-ID: <4B907A98.7080802@ibctech.ca> On 2010.03.04 22:26, Steve Bertrand wrote: > On 2010.03.04 16:53, William Herrin wrote: >> On Thu, Mar 4, 2010 at 4:44 PM, Stan Barber wrote: >>>> On Mar 4, 2010, at 1:30 PM, William Herrin wrote: >>>> Because we expect far fewer end users to multihome tomorrow than do today? >>> >>> I would suggest that the ratio of folks that will multihome under IPv6 >>> versus those that won't will get smaller. I base that on an assumption that >>> NAT (as we know it today) will be less prevalent as IPv6 usage grows. >> >> Alrighty then... > > heh. > > Stan, you've got things backwards, no matter which direction you are > looking at things from. I'm thinking that you may have written the > sentence incorrectly. > > It's unfortunate, but it is reality. > > Have you reviewed your RIR policy lately? v6 will be flying out the > window soon, and your local RIR may be assigning PI space like candy. > > Welcome IPv6. fwiw, it didn't appear clear to me that my own comments reflected my feelings that the migration was a good thing ;) STeve From drc at virtualized.org Thu Mar 4 22:15:23 2010 From: drc at virtualized.org (David Conrad) Date: Thu, 4 Mar 2010 23:15:23 -0500 Subject: IP4 Space In-Reply-To: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> Message-ID: <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> On Mar 4, 2010, at 2:30 PM, William Herrin wrote: > Because we expect far fewer end users to multihome tomorrow than do today? We do? Why do we expect this? Regards, -drc From drc at virtualized.org Thu Mar 4 22:20:54 2010 From: drc at virtualized.org (David Conrad) Date: Thu, 4 Mar 2010 23:20:54 -0500 Subject: IP4 Space In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> Message-ID: <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> On Mar 4, 2010, at 9:41 PM, Thomas Magill wrote: >> The most we could achieve would be to extend IPv4 freepool lifespan >> by roughly 26 days. Given the amount of effort sqeezing useful >> addresses out of such a conversion would require, I proffer that >> such effort is better spent moving towards IPv6 dual stack on your >> networks. > > A /8 sounded like a decent amount until you put it that way. Nice > empirical data, even though its based completely on assumptions. But if > it is even in the ballpark.. It is pretty obvious it isn't worth the > effort. When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort. Extrapolations of current IPv4 address space consumption become precisely useless when the existing policy regimes no longer apply. This is not to say folks shouldn't be aggressively pursuing IPv6 deployment, merely that there is a vast installed base that will continue to require IPv4 addresses even after the RIRs allocate the last block they control. Regards, -drc From newton at internode.com.au Thu Mar 4 22:46:12 2010 From: newton at internode.com.au (Mark Newton) Date: Fri, 5 Mar 2010 15:16:12 +1030 Subject: IP4 Space In-Reply-To: <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> Message-ID: On 05/03/2010, at 2:50 PM, David Conrad wrote: > When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort. Only to the extent that the cost of IPv6 migration exceeds the cost of recovering space. There's sure to be an upper-bound on the cost of v4 space, limited by the magnitude of effort required to do whatever you want to do without v4. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From morrowc.lists at gmail.com Thu Mar 4 23:10:41 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 5 Mar 2010 00:10:41 -0500 Subject: IP4 Space In-Reply-To: <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> Message-ID: <75cb24521003042110x23bb6fe9md7889630857d6c92@mail.gmail.com> On Thu, Mar 4, 2010 at 11:15 PM, David Conrad wrote: > On Mar 4, 2010, at 2:30 PM, William Herrin wrote: >> Because we expect far fewer end users to multihome tomorrow than do today? > > We do? yea, it doesn't seem to follow based on what I'd seen at a large network provider, more people multihome over time, for reasons related to business continuity... (the comments about multihoming and nat just seem sideways, as well) -chris From ggm at apnic.net Thu Mar 4 23:53:16 2010 From: ggm at apnic.net (George Michaelson) Date: Fri, 5 Mar 2010 13:53:16 +0800 Subject: Desperately Seeking APNIC In-Reply-To: <63ac96a51003041437o3fe7ddc7i78acae067263a5c7@mail.gmail.com> References: <63ac96a51003041437o3fe7ddc7i78acae067263a5c7@mail.gmail.com> Message-ID: <596D9095-BE91-42B2-B105-38B60A2F695E@apnic.net> Hi. it's been handled, so sorry for a bit of delay, which is due to the APNIC/Apricot meeting going on in KL. This problem was caused by missing WHOIS "domain" objects. APNIC staff are helping Matthew to resolve the problem. -George On 05/03/2010, at 6:37 AM, Matthew Petach wrote: > Would anyone here know of any 24x7 contact at APNIC? The TXT records > indicate they just signed the reverse zone for 203.in-addr.arpa today, and > the delegations for our IP blocks disappeared when they did; and the helpdesk is > currently not answering the phones: > > http://www.apnic.net/services/services-apnic-provides/helpdesk > > Trying to find someone there who can fix the delegations within the > 84.203.in-addr.arpa. zone for 222 and 223 for us, and am running > into dead ends. :/ Any pointers would be appreciated. > > Thanks! > > Matt > From joelja at bogus.com Thu Mar 4 23:57:59 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 04 Mar 2010 21:57:59 -0800 Subject: IP4 Space In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> Message-ID: <4B909D67.7070409@bogus.com> On 03/04/2010 06:41 PM, Thomas Magill wrote: > I've been on board with rolling out IP6 but the SPs I've talked to are > all '...about to start trying to possibly think about extending a beta > to a small portion of some customers' or something along those lines. > This led me to believe that SPs are way behind on this considering the > expected exhaustion of IP4 space. Note, that no operator on this list or any other has had a request approved but not fulfilled by an RIR due to a lack of numbers to assign. When that happens if not before you can can expect behavioral change to occur. denial anger bargaining depression acceptance decide which step you're on... joel From LarrySheldon at cox.net Fri Mar 5 00:04:59 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 05 Mar 2010 00:04:59 -0600 Subject: IP4 Space In-Reply-To: <4B909D67.7070409@bogus.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> Message-ID: <4B909F0B.9030802@cox.net> On 3/4/2010 11:57 PM, Joel Jaeggli wrote: > Note, that no operator on this list or any other has had a request > approved but not fulfilled by an RIR due to a lack of numbers to assign. > When that happens if not before you can can expect behavioral change to > occur. > > denial > anger > bargaining > depression > acceptance > > decide which step you're on... Or which step exhausts your funding. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From owen at delong.com Fri Mar 5 00:15:13 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Mar 2010 14:15:13 +0800 Subject: IP4 Space In-Reply-To: <4B909D67.7070409@bogus.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> Message-ID: <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> On Mar 5, 2010, at 1:57 PM, Joel Jaeggli wrote: > > > On 03/04/2010 06:41 PM, Thomas Magill wrote: >> I've been on board with rolling out IP6 but the SPs I've talked to are >> all '...about to start trying to possibly think about extending a beta >> to a small portion of some customers' or something along those lines. >> This led me to believe that SPs are way behind on this considering the >> expected exhaustion of IP4 space. > > Note, that no operator on this list or any other has had a request > approved but not fulfilled by an RIR due to a lack of numbers to assign. > When that happens if not before you can can expect behavioral change to > occur. > > denial > anger > bargaining > depression acceptance <--- My dual-stacked network and I are here. Owen From shon at unwiredbb.com Fri Mar 5 01:27:53 2010 From: shon at unwiredbb.com (Shon Elliott) Date: Thu, 04 Mar 2010 23:27:53 -0800 Subject: Spamcop Blocks Facebook? In-Reply-To: References: Message-ID: <4B90B279.8090406@unwiredbb.com> Dean, I started the thread with the original question, and after not hearing a suitable response from either Spamcop or someone from the networking side of Facebook, I gave up on this thread when people like Michelle started chiming in their opinion. This thread wasn't meant to be an opinion-fest, but a technical issue that definitely hampers my customers, which apparently, everyone completely lost sight of. So really, my customers, and myself are victims of Spamcop's blocking of Facebook. -S Dean Anderson wrote: > What a load of BS from the "scammer/counterfeit-antispammer" crowd, > otherwise described as con-artists and frauds. > > "You're not authorized to solicit bulk email on behalf of third > parties: only they are" > > Huh? In this case, the third party (the user) authorized sending the > mail on //their// behalf to //their// contacts. This email doesn't go > out except by action of the user. The *recipients* of the email have > indeed solicited email from the user; they are the contacts of the user. > > Basically, what the (well-known) con-artists are trying to say is that > Facebook can't be authorized by its own user to send email from the user > to the contacts of that user. Finally, Linkedin, plaxo and other social > networking sites do the same thing. ISPs also send email on behalf of > their users, and have done so for many years. > > Last, just imagine if each of your contacts had to authorize which ISP > you could use to send them email. Facebook is just an ISP in the email > transaction, offering a service to the user; so that the user can send > email to their contacts. Obviously both the user and Facebook benefit, > but there is nothing wrong with that. Its not spam because its sent at > the request of the user to people the user is already in contact with. > > Blocking facebook is a scam; an effort to shakedown Facebook for > money/services/etc. > > Jim: Are you starting to see a pattern, yet? There is no point in > arguing with con-artists. > > --Dean > > On Thu, 4 Mar 2010, Rich Kulawiec wrote: > >> On Thu, Mar 04, 2010 at 03:16:25PM -0400, jim deleskie wrote: >>> If I leave all boxes checked to send mail/notices/app requests to >>> everyone in my list, or if I give FB my gmail password to pull all my >>> contacts and send them an invite, its pure @ my request, sure FB is >>> happy I do it, but it is no way spam. >> This is dead wrong. You're not authorized to solicit bulk email on behalf >> of third parties: only they are. In the absence of solicitation from >> the *recipients*, bulk email is spam -- by definition. >> >> ---Rsk >> >> >> >> > From graeme at graemef.net Fri Mar 5 02:28:06 2010 From: graeme at graemef.net (Graeme Fowler) Date: Fri, 05 Mar 2010 08:28:06 +0000 Subject: Spamcop Blocks Facebook? In-Reply-To: <4B90B279.8090406@unwiredbb.com> References: <4B90B279.8090406@unwiredbb.com> Message-ID: <1267777686.8163.8.camel@ernie.internal.graemef.net> On Thu, 2010-03-04 at 23:27 -0800, Shon Elliott wrote: > So really, my customers, and myself are victims of > Spamcop's blocking of Facebook. I forget how far back in this thread someone said: Spamcop *listed* Facebook for valid reasons according to their published listing criteria. Other people blocked it. Not Spamcop. FWIW outright blocking on a Spamcop listing is a particularly risky business; best to use a listing as an intelligence point towards a decision whether to block a given message or not. That's why Spamcop is referred to by the default SpamAssassin ruleset, but not in a big enough way to block outright. Fresh operational content: one of the reasons services like Spamcop occasionally list services like Facebook is that they don't honour 5xx responses to RCPT TO:. I'd offer some statistics but I'm concerned that the legal brigade will jump down my throat, but I suggest that anyone running a system like an academic mail platform take a look at the number of invalid recipients services like Facebook try to deliver. If they stopped doing that they'd be a long way towards better behaviour, IMO. Graeme From andy at nosignal.org Fri Mar 5 06:22:17 2010 From: andy at nosignal.org (Andy Davidson) Date: Fri, 05 Mar 2010 12:22:17 +0000 Subject: IP4 Space In-Reply-To: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> Message-ID: <4B90F779.7030809@nosignal.org> On 04/03/2010 19:30, William Herrin wrote: > On Thu, Mar 4, 2010 at 2:12 PM, Joel Jaeggli wrote: >> handling the v6 table is not currently hard (~2600 prefixes) while long >> term the temptation to do TE is roughly that same in v6 as in v4, the >> prospect of having a bunch of non-aggregatable direct assignments should >> be much lower... > Because we expect far fewer end users to multihome tomorrow than do today? The opposite, but a clean slate means multihomed networks with many v4 prefixes may be able to be a multihomed network with just one v6 prefix. Andy From rsk at gsp.org Fri Mar 5 06:40:34 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 5 Mar 2010 07:40:34 -0500 Subject: Spamcop Blocks Facebook? In-Reply-To: <4B90B279.8090406@unwiredbb.com> References: <4B90B279.8090406@unwiredbb.com> Message-ID: <20100305124034.GA28088@gsp.org> On Thu, Mar 04, 2010 at 11:27:53PM -0800, Shon Elliott wrote: > This thread wasn't meant to be an opinion-fest, but a technical > issue that definitely hampers my customers, which apparently, everyone > completely lost sight of. So really, my customers, and myself are victims of > Spamcop's blocking of Facebook. 1. I would suggest taking this discussion to spam-l, which is where the world's leading experts on spam may be found. If you describe your problem correctly and in detail (see next point) then it's very likely that you can get the technical assistance you're seeking. 2. You're still making an anti-spam 101 level mistake here, by erroneously claiming that Spamcop blocks Facebook: Spamcop doesn't, because they can't. If *your* customers can't get mail from Facebook, then it's because something within *your* operation (presumably under the control of someone within *your* operation) is blocking it. ---Rsk From bmanning at vacation.karoshi.com Fri Mar 5 06:39:19 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 5 Mar 2010 12:39:19 +0000 Subject: IP4 Space - the lie In-Reply-To: <4B907507.800@ibctech.ca> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> Message-ID: <20100305123919.GA20227@vacation.karoshi.com.> On Thu, Mar 04, 2010 at 10:05:43PM -0500, Steve Bertrand wrote: > On 2010.03.04 20:55, Owen DeLong wrote: > > > > I proffer that > > such effort is better spent moving towards IPv6 dual stack on your > > networks. > > I *wholeheartedly* agree with Owen's assessment. Even spending time > trying to calculate a rebuttal to his numbers is better spent moving > toward dual-stack ;) > > Nice. > > Steve er... what part of dual-stack didn't you understand? dual-stack consumes exactly the same number of v4 and v6 addresses. if you expect to dual-stack everything - you need to look again. either you are going to need: lots more IPv4 space stealing ports to mux addresses run straight-up native IPv6 - no IPv4 (unless you need to talk to a v4-only host - then use IVI or similar..) imho - the path through the woods is an IVI-like solution. --bill From bill at herrin.us Fri Mar 5 07:24:15 2010 From: bill at herrin.us (William Herrin) Date: Fri, 5 Mar 2010 08:24:15 -0500 Subject: IP4 Space In-Reply-To: <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> Message-ID: <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> On Thu, Mar 4, 2010 at 11:15 PM, David Conrad wrote: > On Mar 4, 2010, at 2:30 PM, William Herrin wrote: >> Because we expect far fewer end users to multihome tomorrow than do today? > > We do? > > Why do we expect this? David, Well, I don't know that "we" do, but Joel made a remarkable assertion that non-aggregable assignments to end users, the ones still needed for multihoming, would go down under IPv6. I wondered about his reasoning. Stan then offered the surprising clarification that a reduction in the use of NAT would naturally result in a reduction of multihoming. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tdurack at gmail.com Fri Mar 5 07:55:29 2010 From: tdurack at gmail.com (Tim Durack) Date: Fri, 5 Mar 2010 08:55:29 -0500 Subject: IP4 Space In-Reply-To: <4B90F779.7030809@nosignal.org> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <4B90F779.7030809@nosignal.org> Message-ID: <9e246b4d1003050555r4e13d2f8k668dc549f1e78444@mail.gmail.com> On Fri, Mar 5, 2010 at 7:22 AM, Andy Davidson wrote: > On 04/03/2010 19:30, William Herrin wrote: >> On Thu, Mar 4, 2010 at 2:12 PM, Joel Jaeggli wrote: >>> handling the v6 table is not currently hard (~2600 prefixes) while long >>> term the temptation to do TE is roughly that same in v6 as in v4, the >>> prospect of having a bunch of non-aggregatable direct assignments should >>> be much lower... >> Because we expect far fewer end users to multihome tomorrow than do today? > > The opposite, but a clean slate means multihomed networks with many v4 > prefixes may be able to be a multihomed network with just one v6 prefix. Assuming RIR policy allows multi-homers to be allocated/assigned enough v6 to grow appreciably without having to go back to the RIR. As a multi-homed end-user, I don't currently find that to be the case. -- Tim:> From MAdcock at hisna.com Fri Mar 5 08:07:45 2010 From: MAdcock at hisna.com (Adcock, Matt [HISNA]) Date: Fri, 5 Mar 2010 06:07:45 -0800 Subject: Cisco hardware question References: <2D5569D0-B3A3-468B-BD64-0C85E4C24158@mac.com> <5b6f80201003041417y19e921bco78ce625e3225d61e@mail.gmail.com> <4B904E38.4090607@rollernet.us> Message-ID: Response from my Cisco rep: "I has to be "Cisco Certified" refurbished. If it isn't it cannot have Smartnet placed on it without an inspection (which comes with an inspection fee) and the licensing paid for as well. When you combine these two cost items together with the selling price of the gear you're about back to the cost of a brand new piece of equipment. The most difficult part of buying this "gray market" or even "black market" gear is that you don't really know where it came from. The Department of Defense has found some of this "black market" gear (a fake) in the networks of their vendors. In some cases they have found a "phone home" feature that pokes a hole in the firewall and then allows outside users (Chinese) into the network. Once in they can siphon off data from your network." Thanks, Matt ? ?Matt Adcock, Manager 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com 700 Hyundai Blvd.?/ Montgomery, AL 36105 P The average office worker uses 10,000 sheets of paper = 1.2 trees, per year By not printing this email, you?ve saved paper, ink and millions of trees ? From: Adcock, Matt [HISNA] Sent: Thu 3/4/2010 7:17 PM To: Seth Mattinen; nanog at nanog.org Subject: RE: Cisco hardware question That's very true. They ship some out one door for Cisco and some out another door for gray/black market. One other thing to note - the discounts shown on the Web site previously mentioned here are not that greater than the ones I know Cisco gives many companies. Is it really worth taking a chance with one of the most critical parts of your infrastructure to save 10% or 15%. In my industry (automotive) and I think in many others the answer is absoutely not. Matt The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information.?If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited.??We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message.?We cannot accept liability for any loss or damage caused by software viruses.?If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Thu 3/4/2010 6:20 PM To: nanog at nanog.org Subject: Re: Cisco hardware question On 3/4/2010 16:16, Ricky Beam wrote: > > Not necessarily. I've seen a lot of boxes that appear to have come > "direct" from Cisco, however, I know they came from a wholesaler's > warehouse. (only one came direct from Cisco. from the factory in Malaysia.) > A lot of counterfeits come direct from the factory, too. ;) ~Seth ? ? -------------- next part -------------- A non-text attachment was scrubbed... Name: vertical_bar.gif Type: image/gif Size: 1391 bytes Desc: vertical_bar.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.gif Type: image/gif Size: 1745 bytes Desc: logo.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: horizontal_bar.gif Type: image/gif Size: 1418 bytes Desc: horizontal_bar.gif URL: From drc at virtualized.org Fri Mar 5 08:36:12 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 5 Mar 2010 09:36:12 -0500 Subject: IP4 Space In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> Message-ID: Mark, On Mar 4, 2010, at 11:46 PM, Mark Newton wrote: > On 05/03/2010, at 2:50 PM, David Conrad wrote: >> When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort. > > Only to the extent that the cost of IPv6 migration exceeds the cost > of recovering space. You're remembering to include the cost of migrating both sides, for all combinations of sides interested in communicating, right? In some cases, that cost for one of those sides will be quite high. > There's sure to be an upper-bound on the cost of v4 space, limited by the > magnitude of effort required to do whatever you want to do without v4. The interesting question is at what point _can_ you do what you want without IPv4. It seems obvious that that point will be after the IPv4 free pool is exhausted, and as such, allocated-but-not-efficiently-used addresses will likely become worth the effort to reclaim. Regards, -drc From jeffm at iglou.com Fri Mar 5 08:37:46 2010 From: jeffm at iglou.com (Jeff McAdams) Date: Fri, 05 Mar 2010 09:37:46 -0500 Subject: IP4 Space In-Reply-To: <9e246b4d1003050555r4e13d2f8k668dc549f1e78444@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <4B90F779.7030809@nosignal.org> <9e246b4d1003050555r4e13d2f8k668dc549f1e78444@mail.gmail.com> Message-ID: <4B91173A.3090109@iglou.com> On 3/5/10 8:55 AM, Tim Durack wrote: > On Fri, Mar 5, 2010 at 7:22 AM, Andy Davidson wrote: >> On 04/03/2010 19:30, William Herrin wrote: >>> On Thu, Mar 4, 2010 at 2:12 PM, Joel Jaeggli wrote: >>>> handling the v6 table is not currently hard (~2600 prefixes) while long >>>> term the temptation to do TE is roughly that same in v6 as in v4, the >>>> prospect of having a bunch of non-aggregatable direct assignments should >>>> be much lower... >>> Because we expect far fewer end users to multihome tomorrow than do today? >> >> The opposite, but a clean slate means multihomed networks with many v4 >> prefixes may be able to be a multihomed network with just one v6 prefix. > > Assuming RIR policy allows multi-homers to be allocated/assigned > enough v6 to grow appreciably without having to go back to the RIR. As > a multi-homed end-user, I don't currently find that to be the case. It will be the case for many mid-sized businesses. Both my previous and current employer, in switching from IPv4 to IPv6 will drop from 7 and 4 advertisements (fully aggregated) to 1. I don't anticipate either ever having needs larger than the single initial allocation they have or would get. Both are multi-homed. -- Jeff McAdams jeffm at iglou.com From cb.list6 at gmail.com Fri Mar 5 08:38:02 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 5 Mar 2010 06:38:02 -0800 Subject: IP4 Space - the lie In-Reply-To: <20100305123919.GA20227@vacation.karoshi.com.> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> Message-ID: On Fri, Mar 5, 2010 at 4:39 AM, wrote: > On Thu, Mar 04, 2010 at 10:05:43PM -0500, Steve Bertrand wrote: >> On 2010.03.04 20:55, Owen DeLong wrote: >> > >> > I proffer that >> > such effort is better spent moving towards IPv6 dual stack on your >> > networks. >> >> I *wholeheartedly* agree with Owen's assessment. Even spending time >> trying to calculate a rebuttal to his numbers is better spent moving >> toward dual-stack ;) >> >> Nice. >> >> Steve > > > ? ? ? ?er... what part of dual-stack didn't you understand? > ? ? ? ?dual-stack consumes exactly the same number of v4 and v6 addresses. > > ? ? ? ?if you expect to dual-stack everything - you need to look again. > ? ? ? ?either you are going to need: > > ? ? ? ?lots more IPv4 space > > ? ? ? ?stealing ports to mux addresses > > ? ? ? ?run straight-up native IPv6 - no IPv4 (unless you need to talk to > ? ? ? ?a v4-only host - then use IVI or similar..) > > ? ? ? ?imho - the path through the woods is an IVI-like solution. I have a similar perspective. Your point about dual-stack is spot-on. Thats why the future, IMHO, will look like CGN / LSN meaning: NAT444, NAT64, and DS-lite. I am very focused on NAT64 since i believe all the right incentives are in place in that solution for both service providers and content folks to move to IPv6 as quickly as possible, while maintaining some level of IPv4 functions. The major limitation here is that some old-school and fringe applications are IPv4-only while the major applications (major web browsers, email clients, ...). The IPv6 capable applications have reached the tipping point where it is now viable to do IPv6-only + NAT64. There is one of other catch with NAT64 and IPv6-only. It breaks communications with IPv4 literals. Now, you might says that IPv4 literals in URLs are very seldom.... well ... have a look at how Akamai does a lot of their streaming. I just hope it does not come to a show-down where networks move to IPv6-only since IPv4 is a goner and now Akamai content is not available while IPv6 early adopters like Google and Limelight laugh all the way to bank. Hint: Akamai -- stop using IPv4 literals, and and if you can't use IPv6 then please use FQDNs so you don't break services to your customers. IVI is stateless, which means it requires 1 to 1 IPv4 to IPv6 mapping. NAT64 allows multiplexing. > > --bill > > From dwhite at olp.net Fri Mar 5 08:40:19 2010 From: dwhite at olp.net (Dan White) Date: Fri, 5 Mar 2010 08:40:19 -0600 Subject: IP4 Space - the lie In-Reply-To: <20100305123919.GA20227@vacation.karoshi.com.> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> Message-ID: <20100305144019.GA4695@dan.olp.net> On 05/03/10?12:39?+0000, bmanning at vacation.karoshi.com wrote: >> I *wholeheartedly* agree with Owen's assessment. Even spending time >> trying to calculate a rebuttal to his numbers is better spent moving >> toward dual-stack ;) >> >> Nice. >> >> Steve > > > er... what part of dual-stack didn't you understand? > dual-stack consumes exactly the same number of v4 and v6 addresses. I would expect the number of v6 addresses assigned to a host to be a multiple of the number of v4 addresses, depending on the type of host. > if you expect to dual-stack everything - you need to look again. > either you are going to need: > > lots more IPv4 space > > stealing ports to mux addresses > > run straight-up native IPv6 - no IPv4 (unless you need to talk to > a v4-only host - then use IVI or similar..) > > imho - the path through the woods is an IVI-like solution. Or, dual stack today. When you've run out of IPv4 addresses for new end users, set them up an IPv6 HTTP proxy, SMTP relay and DNS resolver and/or charge a premium for IPv4 addresses when you start to sweat. -- Dan White From bmanning at vacation.karoshi.com Fri Mar 5 09:01:56 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 5 Mar 2010 15:01:56 +0000 Subject: IP4 Space - the lie In-Reply-To: <20100305144019.GA4695@dan.olp.net> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> Message-ID: <20100305150156.GA21422@vacation.karoshi.com.> On Fri, Mar 05, 2010 at 08:40:19AM -0600, Dan White wrote: > On 05/03/10 12:39 +0000, bmanning at vacation.karoshi.com wrote: > > er... what part of dual-stack didn't you understand? > > dual-stack consumes exactly the same number of v4 and v6 addresses. > > I would expect the number of v6 addresses assigned to a host to be a > multiple of the number of v4 addresses, depending on the type of host. true that... i was being - perhaps - too literal. > > imho - the path through the woods is an IVI-like solution. > > Or, dual stack today. When you've run out of IPv4 addresses for new end > users, set them up an IPv6 HTTP proxy, SMTP relay and DNS resolver and/or > charge a premium for IPv4 addresses when you start to sweat. > and then we are back to drc's comments. > -- > Dan White From michael.holstein at csuohio.edu Fri Mar 5 09:08:25 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Fri, 05 Mar 2010 10:08:25 -0500 Subject: Spamcop Blocks Facebook? In-Reply-To: <1267777686.8163.8.camel@ernie.internal.graemef.net> References: <4B90B279.8090406@unwiredbb.com> <1267777686.8163.8.camel@ernie.internal.graemef.net> Message-ID: <4B911E69.7060707@csuohio.edu> > the legal brigade will jump down my throat, but I suggest that anyone > running a system like an academic mail platform take a look at the > number of invalid recipients services like Facebook try to deliver. Out of ~1.5m emails on the 3rd, it was only 4 invalid recipients here. There was one more from a misspelling of facebook that had to be a spam probe. For @*myspace* it was 17 messages. For @*linkedin* it was 20 messages. Not too big of an issue, IMHO. Cheers, Michael Holstein Cleveland State University From dave at mvn.net Fri Mar 5 09:08:49 2010 From: dave at mvn.net (David E. Smith) Date: Fri, 5 Mar 2010 09:08:49 -0600 Subject: Spamcop Blocks Facebook? In-Reply-To: <1267777686.8163.8.camel@ernie.internal.graemef.net> References: <4B90B279.8090406@unwiredbb.com> <1267777686.8163.8.camel@ernie.internal.graemef.net> Message-ID: <8b731a021003050708n135e16a4ja955948f01a795c1@mail.gmail.com> On Fri, Mar 5, 2010 at 02:28, Graeme Fowler wrote: > Fresh operational content: one of the reasons services like Spamcop > occasionally list services like Facebook is that they don't honour 5xx > responses to RCPT TO:. I'd offer some statistics but I'm concerned that > the legal brigade will jump down my throat, but I suggest that anyone > running a system like an academic mail platform take a look at the > number of invalid recipients services like Facebook try to deliver. If > they stopped doing that they'd be a long way towards better behaviour, > IMO. > > As long as we're going off-topic, might as well go all the way :V How long should a sender (say, Facebook) retain a database of 5xx SMTP responses? Just because jimbob at school.edu doesn't exist today, doesn't mean that James Robert Jones won't enroll in the fall and get jimbob@ as his school-provided email address. David Smith MVN.net From woolf at isc.org Fri Mar 5 09:21:53 2010 From: woolf at isc.org (Suzanne Woolf) Date: Fri, 5 Mar 2010 15:21:53 +0000 Subject: IP4 Space - the lie Message-ID: <20100305152153.GA10496@farside.isc.org> On Fri, Mar 05, 2010 at 12:39:19PM +0000, bmanning at vacation.karoshi.com wrote: > er... what part of dual-stack didn't you understand? > dual-stack consumes exactly the same number of v4 and v6 addresses. > > if you expect to dual-stack everything - you need to look again. > either you are going to need: > > lots more IPv4 space > > stealing ports to mux addresses > > run straight-up native IPv6 - no IPv4 (unless you need to talk to > a v4-only host - then use IVI or similar..) > > imho - the path through the woods is an IVI-like solution. There are several IPv4/IPv6 co-existence technologies under development that attempt to resolve the asymmetry Bill notes here, where IPv4 addresses are already scarce and IPv6 addresses may reasonably be treated as less so. They include IVI, NAT64/DNS64, and dual-stack lite. See for example the lightning talk last Wednesday in Austin on AFTR, ISC's free, open source implementation of dual-stack lite, or the panel discussion at APRICOT earlier this week. It's only been in the last couple of years that the IETF and the vendors have been taking seriously the problem of moving IPv4-IPv6 co-existence mechanisms into the network, away from host-based dual-stack and into use cases where legacy infrastructure has to co-exist with the need for growth. But now that they have, there's an embarrassment of what we can hope turn out to be riches in this area....or at least a pony amongst the, err, bulk of material. Suzanne From bmanning at vacation.karoshi.com Fri Mar 5 09:37:49 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 5 Mar 2010 15:37:49 +0000 Subject: IP4 Space - the lie In-Reply-To: <20100305152153.GA10496@farside.isc.org> References: <20100305152153.GA10496@farside.isc.org> Message-ID: <20100305153749.GB21422@vacation.karoshi.com.> On Fri, Mar 05, 2010 at 03:21:53PM +0000, Suzanne Woolf wrote: > > On Fri, Mar 05, 2010 at 12:39:19PM +0000, bmanning at vacation.karoshi.com wrote: > > er... what part of dual-stack didn't you understand? > > dual-stack consumes exactly the same number of v4 and v6 addresses. > > > > if you expect to dual-stack everything - you need to look again. > > either you are going to need: > > > > lots more IPv4 space > > > > stealing ports to mux addresses > > > > run straight-up native IPv6 - no IPv4 (unless you need to talk to > > a v4-only host - then use IVI or similar..) > > > > imho - the path through the woods is an IVI-like solution. > > There are several IPv4/IPv6 co-existence technologies under > development that attempt to resolve the asymmetry Bill notes here, > where IPv4 addresses are already scarce and IPv6 addresses may > reasonably be treated as less so. They include IVI, NAT64/DNS64, and > dual-stack lite. > > See for example the lightning talk last Wednesday in Austin on AFTR, > ISC's free, open source implementation of dual-stack lite, or the > panel discussion at APRICOT earlier this week. > > It's only been in the last couple of years that the IETF and the > vendors have been taking seriously the problem of moving IPv4-IPv6 > co-existence mechanisms into the network, away from host-based > dual-stack and into use cases where legacy infrastructure has to > co-exist with the need for growth. But now that they have, there's an > embarrassment of what we can hope turn out to be riches in this > area....or at least a pony amongst the, err, bulk of material. > there is a real danger here ... wholesale adoption of a translation technology, esp one that is integrated into the network kind of ensures that it will never get pulled out - or that the enduser will have a devil of a time routing around it when it no longer works for her - but the ISP sees her as a statistically anomaly. I would argue that the right/correct place for such translation technology is very close to the edge - in much the same way as NAT technology is roughl an "edge" technology. (ok - it used to be but w/ CGN .. its clearly moved. we -need- the technologies - but only for a while. otherwise they become a drug that we are dependent on. and we will be stuck on the dual-stack plateau for a much longer time that we should. imho of coure ... YM (and business models) MV --bill > > Suzanne From jasongurtz at npumail.com Fri Mar 5 09:39:35 2010 From: jasongurtz at npumail.com (Jason Gurtz) Date: Fri, 5 Mar 2010 10:39:35 -0500 Subject: FreeAxez raised flooring? Message-ID: A consultant has recommended FreeAxez for the raised floor in a new data center. I checked it out and have concerns since it says it does NOT create a plenum and cannot be used as an air handling space; it's a low-profile flooring system. How would cooling be done in this scenario? Open air (with intake/exhaust mixing) seems like a step backwards in terms of efficiency. Descriptions of any operation experience with this product will be gratefully accepted. ~JasonG -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5103 bytes Desc: not available URL: From graeme at graemef.net Fri Mar 5 09:44:16 2010 From: graeme at graemef.net (Graeme Fowler) Date: Fri, 05 Mar 2010 15:44:16 +0000 Subject: Spamcop Blocks Facebook? In-Reply-To: <8b731a021003050708n135e16a4ja955948f01a795c1@mail.gmail.com> References: <4B90B279.8090406@unwiredbb.com> <1267777686.8163.8.camel@ernie.internal.graemef.net> <8b731a021003050708n135e16a4ja955948f01a795c1@mail.gmail.com> Message-ID: <1267803856.3161.20.camel@localhost> On Fri, 2010-03-05 at 09:08 -0600, David E. Smith wrote: > As long as we're going off-topic, might as well go all the way :V Well, the conversation has continued here despite repeated mentions of mailop at mailop.org so unless the MLC deem it off-topic and squash the thread I guess it'll rumble on. My reply below, although based on email, is most definitely on-topic as it covers "good neighbo(u)r" behaviour and could just as easily apply to all manner of bits and protocols which members of this list shovel around daily. Anyway: > How long should a sender (say, Facebook) retain a database of 5xx SMTP > responses? Just because jimbob at school.edu doesn't exist today, doesn't > mean that James Robert Jones won't enroll in the fall and get jimbob@ > as his school-provided email address. Then that would be spam, would it not? The incoming jimbob isn't the one who left. The incoming jimbob doesn't want to hear about the old jimbob's friends "fun night out", or be invited to their stag parties, or receive discriminatory, lewd or offensive material. Context: in $dayjob we have a delay before re-using usernames. Student email addresses are never re-used, but many students use the "short" form - user at domain - of their email address to register with Facebook. [As a consequence of this problem alone, their ability to do so is being phased out] This academic year alone I have had to request Facebook strip an address from an account several times, 2 of which were for accounts which expired here over 12 months previously. In each of those cases, Facebook had been repeatedly attempting delivery of notifications/invitations and so on since the account had expired. *That's* why I mentioned it. If they had any decency they would trap those 5xx errors and do something to the account with the failing address after some period/number of failures. You know, a bit like Mailman, Sympa and other decent mailing list applications do. And yes, in at least one of the aforementioned cases the incoming recipient was clearly very upset at the emails they were receiving. So it isn't that surprising that they occasionally hit spamtraps or have complaints made against them which result in DNSBL entries. If they played nicely and observed the responses to their outgoing email stream, then it would be far less likely to happen. I guess the return question is: how long should a given operator return 5xx responses to increasing numbers of Facebook emails before trying to do something about it? Graeme From joelja at bogus.com Fri Mar 5 09:44:32 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 05 Mar 2010 07:44:32 -0800 Subject: IP4 Space In-Reply-To: <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> Message-ID: <4B9126E0.5070607@bogus.com> On 03/05/2010 05:24 AM, William Herrin wrote: > On Thu, Mar 4, 2010 at 11:15 PM, David Conrad wrote: >> On Mar 4, 2010, at 2:30 PM, William Herrin wrote: >>> Because we expect far fewer end users to multihome tomorrow than do today? >> >> We do? >> >> Why do we expect this? > > David, > > Well, I don't know that "we" do, but Joel made a remarkable assertion > that non-aggregable assignments to end users, the ones still needed > for multihoming, would go down under IPv6. A couple of months ago my then employer went to arin to get a direct v6 assignmentment. on the basis of the number of pops the resulting assignment was a /43. It'll be a while I imagine before another prefix is required. They like many organizations receiving direct assignments will not in all likelyhood end up with the handful of assignments (as it has in ipv4), because assignment number one is of sufficient size to support their subnetting needs for quite some time. As I also said the temptation to engage in deaggregate for traffic engineering purposes is there. If this is done right, direct assignment holders and ISPs are issued sufficiently large prefixes such that the prefix count per entity remains small. > I wondered about his > reasoning. Stan then offered the surprising clarification that a > reduction in the use of NAT would naturally result in a reduction of > multihoming. > > Regards, > Bill > From bill at herrin.us Fri Mar 5 09:55:19 2010 From: bill at herrin.us (William Herrin) Date: Fri, 5 Mar 2010 10:55:19 -0500 Subject: IP4 Space In-Reply-To: <4B9126E0.5070607@bogus.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <4B9126E0.5070607@bogus.com> Message-ID: <3c3e3fca1003050755n3242d973sc0854c100bdd1511@mail.gmail.com> On Fri, Mar 5, 2010 at 10:44 AM, Joel Jaeggli wrote: > On 03/05/2010 05:24 AM, William Herrin wrote: >> Joel made a remarkable assertion >> that non-aggregable assignments to end users, the ones still needed >> for multihoming, would go down under IPv6. > > A couple of months ago my then employer went to arin to get a direct v6 > assignmentment. on the basis of the number of pops the resulting > assignment was a /43. It'll be a while I imagine before another prefix > is required. Ah, I follow your reasoning. I'll be interested to learn whether the numbers agree. ARIN staff has reported before that the vast majority of IPv4 end user assignments go to organizations which do not subsequently return for additional assignments. In general it's the ISPs who come back for more allocations... I wonder if the minority of end-user orgs who do request additional space request enough additional blocks to make a difference in the routing tables. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From james at freedomnet.co.nz Fri Mar 5 09:57:11 2010 From: james at freedomnet.co.nz (James Jones) Date: Fri, 05 Mar 2010 10:57:11 -0500 Subject: NANOG job board In-Reply-To: <4B9126E0.5070607@bogus.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <4B9126E0.5070607@bogus.com> Message-ID: <4B9129D7.2040503@freedomnet.co.nz> Is there a NANOG supported/endorsed/recommended job board/list ? I am sorry if this a bit offtopic. From Dawood_Iqbal at hotmail.com Fri Mar 5 09:57:42 2010 From: Dawood_Iqbal at hotmail.com (Dawood Iqbal) Date: Fri, 5 Mar 2010 18:57:42 +0300 Subject: Best VPN Appliance Message-ID: Hello All, Is it possible to get your ideas on what VPN appliances are good to have in enterprise network? Requirements are; SSL IPSec Client and Web VPN support (Win/MAC/iPhone/Android) If webvpn is used, then when any user connects via webvpn, we should be able to re-direct him to any and ONLY specific application i.e SAP. If 2 boxes are installed then they should replicate data seamlessly. Regards, dI From dhetzel at gmail.com Fri Mar 5 10:14:48 2010 From: dhetzel at gmail.com (Dorn Hetzel) Date: Fri, 5 Mar 2010 11:14:48 -0500 Subject: FreeAxez raised flooring? In-Reply-To: References: Message-ID: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> What is the purpose of raised flooring if it *doesn't *create a plenum? On Fri, Mar 5, 2010 at 10:39 AM, Jason Gurtz wrote: > A consultant has recommended FreeAxez for the raised floor in a new data > center. I checked it out and have concerns since it says it does NOT > create a plenum and cannot be used as an air handling space; it's a > low-profile flooring system. > > How would cooling be done in this scenario? Open air (with intake/exhaust > mixing) seems like a step backwards in terms of efficiency. > > Descriptions of any operation experience with this product will be > gratefully accepted. > > ~JasonG > > > From drais at icantclick.org Fri Mar 5 10:26:23 2010 From: drais at icantclick.org (david raistrick) Date: Fri, 5 Mar 2010 11:26:23 -0500 (EST) Subject: FreeAxez raised flooring? In-Reply-To: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> Message-ID: On Fri, 5 Mar 2010, Dorn Hetzel wrote: > What is the purpose of raised flooring if it *doesn't *create a plenum? ...cabling? (though I think working under a floor to route cables vs overhead ladder is a pain..but mixing cabling AND air underfloor is much worse) > On Fri, Mar 5, 2010 at 10:39 AM, Jason Gurtz wrote: >> How would cooling be done in this scenario? Open air (with intake/exhaust >> mixing) seems like a step backwards in terms of efficiency. The usual methods of overhead (or possibly underfloor if you have enough height) distribution: Ductwork. :) Feed cold air into your cold aisle, and depending on your density and ceiling height use a general hot air return that pulls from the top of the ceiling (likely the same way you're used to seeing it done for most raised floor installs) OR drop additional hot air returns right over your hot aisles. Further hot/cold seperation is entirely possible, too, to support higher densities... Personally I'm not a fan of using raised floor for a cold air plenum for reasons I'm not inclined to go into right now. :) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From acv at miniguru.ca Fri Mar 5 10:38:05 2010 From: acv at miniguru.ca (acv) Date: Fri, 5 Mar 2010 11:38:05 -0500 Subject: FreeAxez raised flooring? In-Reply-To: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> Message-ID: <20100305163805.GI43985@miniguru.ca> > What is the purpose of raised flooring if it *doesn't *create a plenum? Cable management, low(er) install costs and high-load bearing capacity. Frankly if you're gonna go with that, you're better off bolting the racks directly to the concrete slab and use Snake Trays for cable management, easier to access. Alex On Fri, Mar 05, 2010 at 11:14:48AM -0500, Dorn Hetzel wrote: > Date: Fri, 5 Mar 2010 11:14:48 -0500 > Subject: Re: FreeAxez raised flooring? > From: Dorn Hetzel > To: nanog at nanog.org > > What is the purpose of raised flooring if it *doesn't *create a plenum? > > On Fri, Mar 5, 2010 at 10:39 AM, Jason Gurtz wrote: > > > A consultant has recommended FreeAxez for the raised floor in a new data > > center. I checked it out and have concerns since it says it does NOT > > create a plenum and cannot be used as an air handling space; it's a > > low-profile flooring system. > > > > How would cooling be done in this scenario? Open air (with intake/exhaust > > mixing) seems like a step backwards in terms of efficiency. > > > > Descriptions of any operation experience with this product will be > > gratefully accepted. > > > > ~JasonG > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From Chris.Campbell at nebulassolutions.com Fri Mar 5 10:35:56 2010 From: Chris.Campbell at nebulassolutions.com (Chris Campbell) Date: Fri, 5 Mar 2010 16:35:56 +0000 Subject: Best VPN Appliance In-Reply-To: References: Message-ID: The Juniper SA is by far and away the market leader and in my opinion the best end user experience. On 5 Mar 2010, at 15:57, Dawood Iqbal wrote: > Hello All, > > > > Is it possible to get your ideas on what VPN appliances are good to have in > enterprise network? > > > > Requirements are; > > SSL > > IPSec > > Client and Web VPN support (Win/MAC/iPhone/Android) > > If webvpn is used, then when any user connects via webvpn, we should be able > to re-direct him to any and ONLY specific application i.e SAP. > > If 2 boxes are installed then they should replicate data seamlessly. > > > > > > Regards, > > dI > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3953 bytes Desc: not available URL: From rspott at cspott.com Fri Mar 5 10:40:13 2010 From: rspott at cspott.com (Ryan Spott) Date: Fri, 5 Mar 2010 08:40:13 -0800 Subject: FreeAxez raised flooring? In-Reply-To: <20100305163805.GI43985@miniguru.ca> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> <20100305163805.GI43985@miniguru.ca> Message-ID: <8a462a021003050840w56e681efuc6924edec6243384@mail.gmail.com> < http://serverspecs.blogs.techtarget.com/2007/07/10/data-center-raised-floor-vs-solid-debate/> is an excellent article on the matter. ryan On Fri, Mar 5, 2010 at 8:38 AM, acv wrote: > > What is the purpose of raised flooring if it *doesn't *create a plenum? > > Cable management, low(er) install costs and high-load bearing capacity. > > Frankly if you're gonna go with that, you're better off bolting the racks > directly to the concrete slab and use Snake Trays for cable management, > easier to access. > > Alex > > On Fri, Mar 05, 2010 at 11:14:48AM -0500, Dorn Hetzel wrote: > > Date: Fri, 5 Mar 2010 11:14:48 -0500 > > Subject: Re: FreeAxez raised flooring? > > From: Dorn Hetzel > > To: nanog at nanog.org > > > > What is the purpose of raised flooring if it *doesn't *create a plenum? > > > > On Fri, Mar 5, 2010 at 10:39 AM, Jason Gurtz > wrote: > > > > > A consultant has recommended FreeAxez for the raised floor in a new > data > > > center. I checked it out and have concerns since it says it does NOT > > > create a plenum and cannot be used as an air handling space; it's a > > > low-profile flooring system. > > > > > > How would cooling be done in this scenario? Open air (with > intake/exhaust > > > mixing) seems like a step backwards in terms of efficiency. > > > > > > Descriptions of any operation experience with this product will be > > > gratefully accepted. > > > > > > ~JasonG > > > > > > > > > > From alex at blastro.com Fri Mar 5 10:46:23 2010 From: alex at blastro.com (Alex Thurlow) Date: Fri, 05 Mar 2010 10:46:23 -0600 Subject: Redundant BGP for lower cost In-Reply-To: <2ad0f9f61003040923q7e8e644cw83b20b5a3796b3f0@mail.gmail.com> References: <4B8FEB0F.5060107@blastro.com> <2ad0f9f61003040923q7e8e644cw83b20b5a3796b3f0@mail.gmail.com> Message-ID: <4B91355F.4060608@blastro.com> I have to say that this looks like a nice solution to me, and I've definitely had many people point me to OSPF. One problem is that I've never run OSPF before. Some googling brings of a few results on implementation, but can someone recommend a good place to look or a book to get to really get it all figured out? Thanks, Alex On 3/4/2010 11:23 AM, Jack Carrozzo wrote: > If you want to keep it cheap, roll out another Quagga edge - one to > each peer. Drop default into OSPF from both edges, iBGP over a GE > between them. If one toasts you'll only lose half your routes for > 1s-ish, or however long you set your OSPF keepalives. > > While you're at it, add extra fans and run the edge systems off solid > state disks or CF cards. > > Or, buy $real hardware. > > -Jack Carrozzo > > On Thu, Mar 4, 2010 at 12:17 PM, Alex Thurlow > wrote: > > Let me preface this by saying that I'm not a full time network > admin, but we're a small company and I'm the only one handling > this. Our budget is also not huge, but we're at the point where > extended downtime would cost us enough money that we can spend > some money to fix the problem. > > Here's my situation: I have two providers, each handing me > gigabit ethernet. I'm getting full BGP feeds and handling them > with a Linux/Quagga router. We max out at about 100kpps, as we're > mostly pushing video which gives us a large packet size. It works > fine, and I've been happy with it so far. But, we've gotten to > the point where I want a backup router of some sort in case > something happens to that one, what with the fans and disks that > could fail. I see a few options. > > 1. Just set up another Quagga box and use keepalived or some other > HA solution. > 2. Buy a Cisco/Juniper/whatever and then have the Quagga box as > backup. > 3. I have a 6500 behind the router that's just doing switching. > Could I have something switch that to static route all traffic to > one of my providers if something happened to the router? The 6500 > has Sup1A with MSFC2 running IOS native. > > On the Cisco side, I see that we could probably run a 7200VXR with > NPE-G1 (about $6000 on ebay). Moving to the Sup720, even used is > probably out of our price range. > > What do you guys think I should use here? > > Thanks, > Alex > > > From bclark at spectraaccess.com Fri Mar 5 10:57:47 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 05 Mar 2010 11:57:47 -0500 Subject: Redundant BGP for lower cost In-Reply-To: <4B91355F.4060608@blastro.com> References: <4B8FEB0F.5060107@blastro.com> <2ad0f9f61003040923q7e8e644cw83b20b5a3796b3f0@mail.gmail.com> <4B91355F.4060608@blastro.com> Message-ID: <1267808267.2221.14.camel@acer> OPSF (in this scenario) is easier to set up then BGP...but check out http://www.openmaniak.com/quagga.php. On Fri, 2010-03-05 at 10:46 -0600, Alex Thurlow wrote: > I have to say that this looks like a nice solution to me, and I've > definitely had many people point me to OSPF. One problem is that I've > never run OSPF before. Some googling brings of a few results on > implementation, but can someone recommend a good place to look or a book > to get to really get it all figured out? > > Thanks, > Alex > > > On 3/4/2010 11:23 AM, Jack Carrozzo wrote: > > If you want to keep it cheap, roll out another Quagga edge - one to > > each peer. Drop default into OSPF from both edges, iBGP over a GE > > between them. If one toasts you'll only lose half your routes for > > 1s-ish, or however long you set your OSPF keepalives. > > > > While you're at it, add extra fans and run the edge systems off solid > > state disks or CF cards. > > > > Or, buy $real hardware. > > > > -Jack Carrozzo > > > > On Thu, Mar 4, 2010 at 12:17 PM, Alex Thurlow > > wrote: > > > > Let me preface this by saying that I'm not a full time network > > admin, but we're a small company and I'm the only one handling > > this. Our budget is also not huge, but we're at the point where > > extended downtime would cost us enough money that we can spend > > some money to fix the problem. > > > > Here's my situation: I have two providers, each handing me > > gigabit ethernet. I'm getting full BGP feeds and handling them > > with a Linux/Quagga router. We max out at about 100kpps, as we're > > mostly pushing video which gives us a large packet size. It works > > fine, and I've been happy with it so far. But, we've gotten to > > the point where I want a backup router of some sort in case > > something happens to that one, what with the fans and disks that > > could fail. I see a few options. > > > > 1. Just set up another Quagga box and use keepalived or some other > > HA solution. > > 2. Buy a Cisco/Juniper/whatever and then have the Quagga box as > > backup. > > 3. I have a 6500 behind the router that's just doing switching. > > Could I have something switch that to static route all traffic to > > one of my providers if something happened to the router? The 6500 > > has Sup1A with MSFC2 running IOS native. > > > > On the Cisco side, I see that we could probably run a 7200VXR with > > NPE-G1 (about $6000 on ebay). Moving to the Sup720, even used is > > probably out of our price range. > > > > What do you guys think I should use here? > > > > Thanks, > > Alex > > > > > > From jay at west.net Fri Mar 5 10:57:59 2010 From: jay at west.net (Jay Hennigan) Date: Fri, 05 Mar 2010 08:57:59 -0800 Subject: 5xx responses and sender lists (was facebook...) In-Reply-To: <8b731a021003050708n135e16a4ja955948f01a795c1@mail.gmail.com> References: <4B90B279.8090406@unwiredbb.com> <1267777686.8163.8.camel@ernie.internal.graemef.net> <8b731a021003050708n135e16a4ja955948f01a795c1@mail.gmail.com> Message-ID: <4B913817.8030107@west.net> On 3/5/10 7:08 AM, David E. Smith wrote: > As long as we're going off-topic, might as well go all the way :V > > How long should a sender (say, Facebook) retain a database of 5xx SMTP > responses? Just because jimbob at school.edu doesn't exist today, doesn't mean > that James Robert Jones won't enroll in the fall and get jimbob@ as his > school-provided email address. They really don't need to retain it at all, other than perhaps to count a few messages to determine to remove the address. A 5xx response is a permanent failure. "The specific message you are sending to this address *right now* will never be delivered, don't keep trying to send this specific message." This usually means that the address does not exist, is administratively prohibited from receiving messages, the MTA is blocking the sender, etc. It is possible but unlikely that a future message from the same sender to the same recipient will succeed. Some mail systems with "dirty word" filters may return 5xx to a specific message and allow another with different content. These aren't all that common. Things like a user going over quota or a temporary failure should not return 5xx but 4xx. Facebook (and legitimate senders of periodic subscription emails) should remove that address from their subscriber lists after receiving 5xx responses. Some subscription services will delete an address only after a series of 5XX rejects (three in a row for example) rather than just one to guard against a fluke erroneous response. If in the future jimbob@ gets assigned that address and chooses to subscribe, then it can be re-added. -- 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 cmadams at hiwaay.net Fri Mar 5 11:15:27 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 5 Mar 2010 11:15:27 -0600 Subject: IP4 Space In-Reply-To: <4B91173A.3090109@iglou.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <4B90F779.7030809@nosignal.org> <9e246b4d1003050555r4e13d2f8k668dc549f1e78444@mail.gmail.com> <4B91173A.3090109@iglou.com> Message-ID: <20100305171527.GC1380869@hiwaay.net> Once upon a time, Jeff McAdams said: > Both my previous and current employer, in switching from IPv4 to IPv6 > will drop from 7 and 4 advertisements (fully aggregated) to 1. I don't > anticipate either ever having needs larger than the single initial > allocation they have or would get. Both are multi-homed. That brings a question to mind. As an ISP, with IPv4, end sites that are multihoming can justify a /24 from us (or another upstream) and announce it through multiple providers. With IPv6, are they supposed to get their block from ARIN directly if they are multihoming? In other words, should I _never_ allow customers to announce smaller blocks of my IPv6 ARIN block? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From tmagill at providecommerce.com Fri Mar 5 11:37:31 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Fri, 5 Mar 2010 09:37:31 -0800 Subject: IP4 Space In-Reply-To: <20100305171527.GC1380869@hiwaay.net> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com><4B90F779.7030809@nosignal.org><9e246b4d1003050555r4e13d2f8k668dc549f1e78444@mail.gmail.com><4B91173A.3090109@iglou.com> <20100305171527.GC1380869@hiwaay.net> Message-ID: >That brings a question to mind. As an ISP, with IPv4, end sites that >are multihoming can justify a /24 from us (or another upstream) and >announce it through multiple providers. With IPv6, are they supposed to >get their block from ARIN directly if they are multihoming? In other >words, should I _never_ allow customers to announce smaller blocks of my >IPv6 ARIN block? According to ARIN, you must meet their IPv4 requirements for an ARIN block to get an IPv6 ARIN block. That leads me to believe that the same customers who need v4 space from you would also need v6 space from you. From owen at delong.com Fri Mar 5 11:51:53 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 01:51:53 +0800 Subject: IP4 Space In-Reply-To: References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com><4B90F779.7030809@nosignal.org><9e246b4d1003050555r4e13d2f8k668dc549f1e78444@mail.gmail.com><4B91173A.3090109@iglou.com> <20100305171527.GC1380869@hiwaay.net> Message-ID: On Mar 6, 2010, at 1:37 AM, Thomas Magill wrote: >> That brings a question to mind. As an ISP, with IPv4, end sites that >> are multihoming can justify a /24 from us (or another upstream) and >> announce it through multiple providers. With IPv6, are they supposed > to >> get their block from ARIN directly if they are multihoming? In other >> words, should I _never_ allow customers to announce smaller blocks of > my >> IPv6 ARIN block? > > According to ARIN, you must meet their IPv4 requirements for an ARIN > block to get an IPv6 ARIN block. That leads me to believe that the same > customers who need v4 space from you would also need v6 space from you. > Um, not exactly. According to ARIN, _IF_ you meet their requirements for obtaining an IPv4 block, then, you ALSO automatically meet their requirements for obtaining an IPv6 block. There are ALSO other ways to qualify for an IPv6 block, completely independent of the qualification for or possession of an IPv4 block. As to the question about what you should or should not allow your customers to announce, that is up to you. However, there is a specific block being used to issue ARIN end-user assignments, and, many ISPs filter that more liberally (/48) than they filter blocks used for allocation (/32). As such, your customers who are multihomed _MAY_ have a better chance of having their prefix seen if they use an ARIN direct assignment. However, there is at least 1 provider (hello, AS701) that blocks nearly all prefixes longer than /32 in IPv6, so, customers that are multihomed and announcing a more specific from your space would appear as if they are single-homed to Verizon customers, while they would be invisible to Verizon customers if they use ARIN space. There may be other providers with similar filtration policies. Hurricane Electric will accept routes either way. I cannot speak in detail about the conduct of other providers, as I do not know their policies. Owen From owen at delong.com Fri Mar 5 11:54:00 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 01:54:00 +0800 Subject: FreeAxez raised flooring? In-Reply-To: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> Message-ID: Not sure about the purpose of a raised floor if it doesn't create a plenum, but, the step forward from raised-floor plenum is hot-aisle/cold-aisle which requires a good bit more discipline in your datacenter, but, is substantially more efficient. Owen On Mar 6, 2010, at 12:14 AM, Dorn Hetzel wrote: > What is the purpose of raised flooring if it *doesn't *create a plenum? > > On Fri, Mar 5, 2010 at 10:39 AM, Jason Gurtz wrote: > >> A consultant has recommended FreeAxez for the raised floor in a new data >> center. I checked it out and have concerns since it says it does NOT >> create a plenum and cannot be used as an air handling space; it's a >> low-profile flooring system. >> >> How would cooling be done in this scenario? Open air (with intake/exhaust >> mixing) seems like a step backwards in terms of efficiency. >> >> Descriptions of any operation experience with this product will be >> gratefully accepted. >> >> ~JasonG >> >> >> From tmagill at providecommerce.com Fri Mar 5 12:06:53 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Fri, 5 Mar 2010 10:06:53 -0800 Subject: IP4 Space In-Reply-To: References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com><4B90F779.7030809@nosignal.org><9e246b4d1003050555r4e13d2f8k668dc549f1e78444@mail.gmail.com><4B91173A.3090109@iglou.com> <20100305171527.GC1380869@hiwaay.net> Message-ID: >According to ARIN, _IF_ you meet their requirements for obtaining an IPv4 >block, then, you ALSO automatically meet their requirements for obtaining >an IPv6 block. Thank you for the clarification. I am obviously in the very early stage of planning IPv6 for our company with hopes of at least having peers up this summer after our peak holiday season (mothers day). I would prefer to get an ARIN block so that we feel less locked down to a provider by using their space. >However, there is a specific block being used to issue ARIN end-user >assignments, and, many ISPs filter that more liberally (/48) than they >filter blocks used for allocation (/32). As such, your customers who are >multihomed _MAY_ have a better chance of having their prefix seen if >they use an ARIN direct assignment. So what seems to be the standard for the longest advertised prefix for v6 (compared to /24 for v4)? If I get a /48 from ARIN how many non-aggregated prefixes should I expect to have? This sounds like you are saying /48 is as specific at it would get. From owen at delong.com Fri Mar 5 12:08:11 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 02:08:11 +0800 Subject: IP4 Space In-Reply-To: <3c3e3fca1003050755n3242d973sc0854c100bdd1511@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <4B9126E0.5070607@bogus.com> <3c3e3fca1003050755n3242d973sc0854c100bdd1511@mail.gmail.com> Message-ID: On Mar 5, 2010, at 11:55 PM, William Herrin wrote: > On Fri, Mar 5, 2010 at 10:44 AM, Joel Jaeggli wrote: >> On 03/05/2010 05:24 AM, William Herrin wrote: >>> Joel made a remarkable assertion >>> that non-aggregable assignments to end users, the ones still needed >>> for multihoming, would go down under IPv6. >> >> A couple of months ago my then employer went to arin to get a direct v6 >> assignmentment. on the basis of the number of pops the resulting >> assignment was a /43. It'll be a while I imagine before another prefix >> is required. > > Ah, I follow your reasoning. I'll be interested to learn whether the > numbers agree. ARIN staff has reported before that the vast majority > of IPv4 end user assignments go to organizations which do not > subsequently return for additional assignments. In general it's the > ISPs who come back for more allocations... I wonder if the minority of > end-user orgs who do request additional space request enough > additional blocks to make a difference in the routing tables. Well, between that, and, the fact that ISPs should be asking for additional space a _LOT_ less frequently and all cases should be more likely to get an aggregable expansion of their allocation/assignment now that we are delegating by bisection, I think both of those things will reduce the rate at which growth within organizations increases the routing table by quite a bit. Owen From owen at delong.com Fri Mar 5 12:11:49 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 02:11:49 +0800 Subject: IP4 Space - the lie In-Reply-To: <20100305144019.GA4695@dan.olp.net> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> Message-ID: If I can try to re-rail the train of this discussion a bit... 1. Yes, dual-stacking may require as many IPv4 addresses as IPv6 addresses. However, in this case, I was referring to dual-stacking as meaning adding IPv6 capabilities to your existing IPv4 hosts and infrastructure, thus, implying that the IPv4 addresses were already present on said hosts. 2. If we dual-stack enough of the IPv4 network quickly (and it really isn't that hard, folks), then, adding IPv6-only hosts later really isn't nearly as bad as it is perceived today. After all, the major drawback to adding an IPv6-only host today is that it can't reach all the IPv4-only servers it may want to get stuff from. If we dual-stack most or all of those servers (which already have IPv4 addresses on them now, so, no additional IPv4 depletion is required on that part), then, when we're out of IPv4 for new hosts, an IPv6-only host is not a uselessly crippled host. Owen On Mar 5, 2010, at 10:40 PM, Dan White wrote: > On 05/03/10 12:39 +0000, bmanning at vacation.karoshi.com wrote: >>> I *wholeheartedly* agree with Owen's assessment. Even spending time >>> trying to calculate a rebuttal to his numbers is better spent moving >>> toward dual-stack ;) >>> Nice. >>> Steve >> >> >> er... what part of dual-stack didn't you understand? >> dual-stack consumes exactly the same number of v4 and v6 addresses. > > I would expect the number of v6 addresses assigned to a host to be a > multiple of the number of v4 addresses, depending on the type of host. > >> if you expect to dual-stack everything - you need to look again. >> either you are going to need: >> >> lots more IPv4 space >> >> stealing ports to mux addresses >> >> run straight-up native IPv6 - no IPv4 (unless you need to talk to a v4-only host - then use IVI or similar..) >> >> imho - the path through the woods is an IVI-like solution. > > Or, dual stack today. When you've run out of IPv4 addresses for new end > users, set them up an IPv6 HTTP proxy, SMTP relay and DNS resolver and/or > charge a premium for IPv4 addresses when you start to sweat. > > -- > Dan White From joelja at bogus.com Fri Mar 5 12:14:35 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 05 Mar 2010 10:14:35 -0800 Subject: Redundant BGP for lower cost In-Reply-To: <4B91355F.4060608@blastro.com> References: <4B8FEB0F.5060107@blastro.com> <2ad0f9f61003040923q7e8e644cw83b20b5a3796b3f0@mail.gmail.com> <4B91355F.4060608@blastro.com> Message-ID: <4B914A0B.6010806@bogus.com> http://ws.afnog.org/afnog2009/sie/detail.html monday afternoon and tuesdays workshop materials cover introduction to dynamic routing and ospf. thursdays includes the ospf/ibgp intergration materials. On 03/05/2010 08:46 AM, Alex Thurlow wrote: > I have to say that this looks like a nice solution to me, and I've > definitely had many people point me to OSPF. One problem is that I've > never run OSPF before. Some googling brings of a few results on > implementation, but can someone recommend a good place to look or a book > to get to really get it all figured out? > > Thanks, > Alex > > > On 3/4/2010 11:23 AM, Jack Carrozzo wrote: >> If you want to keep it cheap, roll out another Quagga edge - one to >> each peer. Drop default into OSPF from both edges, iBGP over a GE >> between them. If one toasts you'll only lose half your routes for >> 1s-ish, or however long you set your OSPF keepalives. >> >> While you're at it, add extra fans and run the edge systems off solid >> state disks or CF cards. >> >> Or, buy $real hardware. >> >> -Jack Carrozzo >> >> On Thu, Mar 4, 2010 at 12:17 PM, Alex Thurlow > > wrote: >> >> Let me preface this by saying that I'm not a full time network >> admin, but we're a small company and I'm the only one handling >> this. Our budget is also not huge, but we're at the point where >> extended downtime would cost us enough money that we can spend >> some money to fix the problem. >> >> Here's my situation: I have two providers, each handing me >> gigabit ethernet. I'm getting full BGP feeds and handling them >> with a Linux/Quagga router. We max out at about 100kpps, as we're >> mostly pushing video which gives us a large packet size. It works >> fine, and I've been happy with it so far. But, we've gotten to >> the point where I want a backup router of some sort in case >> something happens to that one, what with the fans and disks that >> could fail. I see a few options. >> >> 1. Just set up another Quagga box and use keepalived or some other >> HA solution. >> 2. Buy a Cisco/Juniper/whatever and then have the Quagga box as >> backup. >> 3. I have a 6500 behind the router that's just doing switching. >> Could I have something switch that to static route all traffic to >> one of my providers if something happened to the router? The 6500 >> has Sup1A with MSFC2 running IOS native. >> >> On the Cisco side, I see that we could probably run a 7200VXR with >> NPE-G1 (about $6000 on ebay). Moving to the Sup720, even used is >> probably out of our price range. >> >> What do you guys think I should use here? >> >> Thanks, >> Alex >> >> >> > From owen at delong.com Fri Mar 5 12:16:09 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 02:16:09 +0800 Subject: IP4 Space - the lie In-Reply-To: <20100305153749.GB21422@vacation.karoshi.com.> References: <20100305152153.GA10496@farside.isc.org> <20100305153749.GB21422@vacation.karoshi.com.> Message-ID: > > there is a real danger here ... wholesale adoption of a > translation technology, esp one that is integrated into > the network kind of ensures that it will never get pulled out - > or that the enduser will have a devil of a time routing around > it when it no longer works for her - but the ISP sees her as a > statistically anomaly. > > I would argue that the right/correct place for such translation > technology is very close to the edge - in much the same way as > NAT technology is roughl an "edge" technology. (ok - it used to be but w/ > CGN .. its clearly moved. > > we -need- the technologies - but only for a while. otherwise they > become a drug that we are dependent on. and we will be stuck on the > dual-stack plateau for a much longer time that we should. > > imho of coure ... YM (and business models) MV > Bill, While the DS-LIte mechanism does involve moving the NAT towards the Core instead of leaving it at the edge, the advantage is that you can route around it very easily as an end-user. Every thing the end user sends to an IPv6 destination bypasses the NAT box completely and only IPv4 is afflicted. I think that will be fairly easy to deprecate over time vs. many many edge-NATs and layers of NATs near the edge. Owen From owen at delong.com Fri Mar 5 12:21:05 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 02:21:05 +0800 Subject: IP4 Space In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> Message-ID: <59AEDC03-BCC7-4027-8818-CF6353455BE8@delong.com> On Mar 5, 2010, at 10:36 PM, David Conrad wrote: > Mark, > > On Mar 4, 2010, at 11:46 PM, Mark Newton wrote: >> On 05/03/2010, at 2:50 PM, David Conrad wrote: >>> When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort. >> >> Only to the extent that the cost of IPv6 migration exceeds the cost >> of recovering space. > > You're remembering to include the cost of migrating both sides, for all combinations of sides interested in communicating, right? In some cases, that cost for one of those sides will be quite high. > >> There's sure to be an upper-bound on the cost of v4 space, limited by the >> magnitude of effort required to do whatever you want to do without v4. > > The interesting question is at what point _can_ you do what you want without IPv4. It seems obvious that that point will be after the IPv4 free pool is exhausted, and as such, allocated-but-not-efficiently-used addresses will likely become worth the effort to reclaim. > Ah, but, that assumes that the need is located in a similar part of the network to the reclamation, or, that the point of reclamation can be sufficiently motivated to do so by the money offered by the point of need. I suspect the organizations that have excess space and know where it is are likely to hold onto it as a hedge against their future needs, or, try to extract a very high market premium for it. Owen From bill at herrin.us Fri Mar 5 12:24:37 2010 From: bill at herrin.us (William Herrin) Date: Fri, 5 Mar 2010 13:24:37 -0500 Subject: IP4 Space In-Reply-To: <20100305171527.GC1380869@hiwaay.net> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <4B90F779.7030809@nosignal.org> <9e246b4d1003050555r4e13d2f8k668dc549f1e78444@mail.gmail.com> <4B91173A.3090109@iglou.com> <20100305171527.GC1380869@hiwaay.net> Message-ID: <3c3e3fca1003051024t6f27ec7bmb836de3f059bac72@mail.gmail.com> On Fri, Mar 5, 2010 at 12:15 PM, Chris Adams wrote: > Once upon a time, Jeff McAdams said: >> Both my previous and current employer, in switching from IPv4 to IPv6 >> will drop from 7 and 4 advertisements (fully aggregated) to 1. ?I don't >> anticipate either ever having needs larger than the single initial >> allocation they have or would get. ?Both are multi-homed. > > That brings a question to mind. ?As an ISP, with IPv4, end sites that > are multihoming can justify a /24 from us (or another upstream) and > announce it through multiple providers. ?With IPv6, are they supposed to > get their block from ARIN directly if they are multihoming? There are three ARIN policy proposals on the table which attempt to address that issue right now: https://www.arin.net/policy/proposals/2010_8.html 6.5.8.2. Criteria for initial assignment to Internet connected end-users b. Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; https://www.arin.net/policy/proposals/2010_7.html 6.2.3.2 X-Small (/48) To qualify for a /48 allocation or assignment, an organization must: * Be Multihomed per section 2.7, and qualify for an ASN per section 5; or https://www.arin.net/policy/proposals/2010_4.html 6.5.1.2. Criteria for initial allocation to ISPs Organizations may justify an initial allocation for the purpose of assigning addresses to other organizations or customers that it will provide IPv6 Internet connectivity to, with an intent to provide global reachability for the allocation within 12 months, by meeting one of the following additional criteria: b. Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; I'm personally partial to 2010-7 since it also makes TE filtering practical. > In other > words, should I _never_ allow customers to announce smaller blocks of my > IPv6 ARIN block? In my opinion, and this is just my opinion, you should never allow customers to announce IPv6 cutouts from your block. Cutouts are hard to programmatically distinguish from traffic engineering and there are 16 bits of potential traffic engineering from the minimum size ISP block if you can't filter until /48. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Fri Mar 5 12:23:59 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 02:23:59 +0800 Subject: IP4 Space - the lie In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> Message-ID: <4BB3D876-628A-4052-BC91-7635045BC5B5@delong.com> > > IVI is stateless, which means it requires 1 to 1 IPv4 to IPv6 mapping. > NAT64 allows multiplexing. > I didn't fully understand it, but, Ma Yan presented IVI with multiplexing in a stateless environment at APNIC 29. Owen (who is very glad these are technologies OTHER people will use) From woolf at isc.org Fri Mar 5 12:36:24 2010 From: woolf at isc.org (Suzanne Woolf) Date: Fri, 5 Mar 2010 18:36:24 +0000 Subject: IP4 Space - the lie In-Reply-To: <4BB3D876-628A-4052-BC91-7635045BC5B5@delong.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <4BB3D876-628A-4052-BC91-7635045BC5B5@delong.com> Message-ID: <20100305183624.GC14980@farside.isc.org> On Sat, Mar 06, 2010 at 02:23:59AM +0800, Owen DeLong wrote: > > Owen (who is very glad these are technologies OTHER people will use) > :) My point was not really to push a particular technology, although we believe ds-lite is worth looking at or ISC wouldn't have implemented and released it. (Among other things it does put the pain of figuring out deployment in more or less the same place that IPv4 exhaustion will be felt: in service-provider networks that will need to grow after the end of the unallocated IPv4 without leaving behind legacy customers.) My point was more that there *are* alternatives in this space that didn't exist until fairly recently, there's now a much bigger solution space for the gap between IPv4 runout and global-scale native IPv6 deployment than maybe people think.... But it's going to take some effort to find and use the technology that's right for you and your network, so start allocating that resource now if you haven't yet. Suzanne From bill at herrin.us Fri Mar 5 12:41:42 2010 From: bill at herrin.us (William Herrin) Date: Fri, 5 Mar 2010 13:41:42 -0500 Subject: FreeAxez raised flooring? In-Reply-To: References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> Message-ID: <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> On Fri, Mar 5, 2010 at 12:54 PM, Owen DeLong wrote: > Not sure about the purpose of a raised floor if it doesn't create a plenum, but, the > step forward from raised-floor plenum is hot-aisle/cold-aisle which requires a good > bit more discipline in your datacenter, but, is substantially more efficient. Hi Owen, Hot-aisle/cold-aisle is a separate issue from a raised floor plenum. They're mutually supportive but not mutually dependent. Raised floor has pros and cons which make it good or bad depending on the environment. If you haven't yet started implementing hot aisle/cold aisle, on the other hand, you're already the better part of a decade out of date and your equipment is suffering for it. For the original question: Non-plenum short raised floor can be useful if you want to separate your power and data wiring. Other than that, I can't see any advantage versus a solid floor and either snake tray or other overhead wiring systems. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Fri Mar 5 12:38:24 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 02:38:24 +0800 Subject: IP4 Space In-Reply-To: References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com><4B90F779.7030809@nosignal.org><9e246b4d1003050555r4e13d2f8k668dc549f1e78444@mail.gmail.com><4B91173A.3090109@iglou.com> <20100305171527.GC1380869@hiwaay.net> Message-ID: <71DCE6AD-85B0-4C79-AC15-B61752EE6C66@delong.com> On Mar 6, 2010, at 2:06 AM, Thomas Magill wrote: >> According to ARIN, _IF_ you meet their requirements for obtaining an > IPv4 >> block, then, you ALSO automatically meet their requirements for > obtaining >> an IPv6 block. > > Thank you for the clarification. I am obviously in the very early stage > of planning IPv6 for our company with hopes of at least having peers up > this summer after our peak holiday season (mothers day). I would prefer > to get an ARIN block so that we feel less locked down to a provider by > using their space. > Seems reasonable. That's precisely why I created the original and co-authored the final version of the first Provider Independent End-User IPv6 policy. >> However, there is a specific block being used to issue ARIN end-user >> assignments, and, many ISPs filter that more liberally (/48) than they >> filter blocks used for allocation (/32). As such, your customers who > are >> multihomed _MAY_ have a better chance of having their prefix seen if >> they use an ARIN direct assignment. > > So what seems to be the standard for the longest advertised prefix for > v6 (compared to /24 for v4)? If I get a /48 from ARIN how many > non-aggregated prefixes should I expect to have? This sounds like you > are saying /48 is as specific at it would get. Uh, 1. If you need multiple discreet networks, you should probably get a /48 for each of them from ARIN. Owen From bill at herrin.us Fri Mar 5 12:43:34 2010 From: bill at herrin.us (William Herrin) Date: Fri, 5 Mar 2010 13:43:34 -0500 Subject: FreeAxez raised flooring? In-Reply-To: <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> Message-ID: <3c3e3fca1003051043y3f345090x92a0ce4afa52b222@mail.gmail.com> On Fri, Mar 5, 2010 at 1:41 PM, William Herrin wrote: > For the original question: Non-plenum short raised floor can be useful > if you want to separate your power and data wiring. Other than that, I > can't see any advantage versus a solid floor and either snake tray or > other overhead wiring systems. Correction: short raised floor is also useful in a general office environment. It allows you to quickly and cleanly reconfigure your cube 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 cscora at apnic.net Fri Mar 5 12:50:57 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Mar 2010 04:50:57 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201003051850.o25Iovnu024989@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 06 Mar, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 313470 Prefixes after maximum aggregation: 144980 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 152997 Total ASes present in the Internet Routing Table: 33474 Prefixes per ASN: 9.36 Origin-only ASes present in the Internet Routing Table: 29055 Origin ASes announcing only one prefix: 14167 Transit ASes present in the Internet Routing Table: 4419 Transit-only ASes present in the Internet Routing Table: 103 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 22 Max AS path prepend of ASN (32374) 19 Prefixes from unregistered ASNs in the Routing Table: 909 Unregistered ASNs in the Routing Table: 144 Number of 32-bit ASNs allocated by the RIRs: 455 Prefixes from 32-bit ASNs in the Routing Table: 452 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 216 Number of addresses announced to Internet: 2195830208 Equivalent to 130 /8s, 225 /16s and 181 /24s Percentage of available address space announced: 59.2 Percentage of allocated address space announced: 65.8 Percentage of available address space allocated: 90.0 Percentage of address space in use by end-sites: 81.5 Total number of prefixes smaller than registry allocations: 150774 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 75227 Total APNIC prefixes after maximum aggregation: 26054 APNIC Deaggregation factor: 2.89 Prefixes being announced from the APNIC address blocks: 71896 Unique aggregates announced from the APNIC address blocks: 31752 APNIC Region origin ASes present in the Internet Routing Table: 3979 APNIC Prefixes per ASN: 18.07 APNIC Region origin ASes announcing only one prefix: 1086 APNIC Region transit ASes present in the Internet Routing Table: 622 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 498721568 Equivalent to 29 /8s, 185 /16s and 227 /24s Percentage of available APNIC address space announced: 78.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 130980 Total ARIN prefixes after maximum aggregation: 68073 ARIN Deaggregation factor: 1.92 Prefixes being announced from the ARIN address blocks: 104722 Unique aggregates announced from the ARIN address blocks: 39847 ARIN Region origin ASes present in the Internet Routing Table: 13541 ARIN Prefixes per ASN: 7.73 ARIN Region origin ASes announcing only one prefix: 5233 ARIN Region transit ASes present in the Internet Routing Table: 1339 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 740075552 Equivalent to 44 /8s, 28 /16s and 168 /24s Percentage of available ARIN address space announced: 63.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, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 72277 Total RIPE prefixes after maximum aggregation: 42038 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 65114 Unique aggregates announced from the RIPE address blocks: 42977 RIPE Region origin ASes present in the Internet Routing Table: 14179 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 7343 RIPE Region transit ASes present in the Internet Routing Table: 2129 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 416772736 Equivalent to 24 /8s, 215 /16s and 114 /24s Percentage of available RIPE address space announced: 77.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 27616 Total LACNIC prefixes after maximum aggregation: 6640 LACNIC Deaggregation factor: 4.16 Prefixes being announced from the LACNIC address blocks: 25976 Unique aggregates announced from the LACNIC address blocks: 13520 LACNIC Region origin ASes present in the Internet Routing Table: 1247 LACNIC Prefixes per ASN: 20.83 LACNIC Region origin ASes announcing only one prefix: 406 LACNIC Region transit ASes present in the Internet Routing Table: 211 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 71116288 Equivalent to 4 /8s, 61 /16s and 38 /24s Percentage of available LACNIC address space announced: 70.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6696 Total AfriNIC prefixes after maximum aggregation: 1770 AfriNIC Deaggregation factor: 3.78 Prefixes being announced from the AfriNIC address blocks: 5037 Unique aggregates announced from the AfriNIC address blocks: 1453 AfriNIC Region origin ASes present in the Internet Routing Table: 347 AfriNIC Prefixes per ASN: 14.52 AfriNIC Region origin ASes announcing only one prefix: 99 AfriNIC Region transit ASes present in the Internet Routing Table: 76 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 14840832 Equivalent to 0 /8s, 226 /16s and 116 /24s Percentage of available AfriNIC address space announced: 44.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1853 8533 472 Korea Telecom (KIX) 17488 1293 132 137 Hathway IP Over Cable Interne 4755 1284 287 136 TATA Communications formerly 18101 1075 221 39 Reliance Infocom Ltd Internet 4134 1018 19605 397 CHINANET-BACKBONE 9583 997 75 498 Sify Limited 7545 952 199 99 TPG Internet Pty Ltd 17974 928 282 18 PT TELEKOMUNIKASI INDONESIA 9829 841 684 22 BSNL National Internet Backbo 4808 837 1582 212 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4059 3842 314 bellsouth.net, inc. 4323 3791 1084 395 Time Warner Telecom 1785 1796 698 129 PaeTec Communications, Inc. 7018 1558 5757 1003 AT&T WorldNet Services 20115 1554 1493 663 Charter Communications 2386 1318 602 936 AT&T Data Communications Serv 3356 1209 10944 419 Level 3 Communications, LLC 11492 1146 222 14 Cable One 6478 1129 242 205 AT&T Worldnet Services 22773 1128 2602 69 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 585 40 5 United Telecom of Georgia 3292 452 1900 393 TDC Tele Danmark 30890 450 101 205 Evolva Telecom 702 424 1870 336 UUNET - Commercial IP service 8551 396 353 37 Bezeq International 8866 386 112 21 Bulgarian Telecommunication C 3320 363 7072 317 Deutsche Telekom AG 3301 354 1413 315 TeliaNet Sweden 3215 347 3206 103 France Telecom Transpac 12479 332 576 5 Uni2 Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1577 2893 236 UniNet S.A. de C.V. 10620 1010 227 156 TVCABLE BOGOTA 28573 901 698 85 NET Servicos de Comunicao S.A 7303 679 359 98 Telecom Argentina Stet-France 22047 529 310 15 VTR PUNTO NET S.A. 6503 499 167 193 AVANTEL, S.A. 7738 477 922 30 Telecomunicacoes da Bahia S.A 11830 474 308 56 Instituto Costarricense de El 3816 446 194 69 Empresa Nacional de Telecomun 11172 446 99 70 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 993 445 10 TEDATA 24863 715 144 41 LINKdotNET AS number 36992 581 131 169 Etisalat MISR 3741 275 855 234 The Internet Solution 33776 251 14 11 Starcomms Nigeria Limited 2018 210 215 121 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 171 19 9 Ci Telecom Autonomous system 24835 133 78 11 RAYA Telecom - Egypt 29975 133 506 14 Vodacom Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4059 3842 314 bellsouth.net, inc. 4323 3791 1084 395 Time Warner Telecom 4766 1853 8533 472 Korea Telecom (KIX) 1785 1796 698 129 PaeTec Communications, Inc. 8151 1577 2893 236 UniNet S.A. de C.V. 7018 1558 5757 1003 AT&T WorldNet Services 20115 1554 1493 663 Charter Communications 2386 1318 602 936 AT&T Data Communications Serv 17488 1293 132 137 Hathway IP Over Cable Interne 4755 1284 287 136 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3791 3396 Time Warner Telecom 1785 1796 1667 PaeTec Communications, Inc. 4766 1853 1381 Korea Telecom (KIX) 8151 1577 1341 UniNet S.A. de C.V. 17488 1293 1156 Hathway IP Over Cable Interne 4755 1284 1148 TATA Communications formerly 11492 1146 1132 Cable One 22773 1128 1059 Cox Communications, Inc. 18566 1059 1049 Covad Communications 18101 1075 1036 Reliance Infocom Ltd Internet Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.77.236.0/22 23456 32-bit ASN transition 41.190.64.0/22 28683 Office des Postes et telecomm 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.216.32.0/19 28683 Office des Postes et telecomm 41.220.144.0/20 36918 ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 36918 ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 36938 Amsco Telecommunications Nige Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:25 /11:66 /12:188 /13:388 /14:661 /15:1234 /16:10950 /17:5156 /18:8716 /19:18094 /20:21993 /21:22160 /22:28483 /23:28273 /24:164098 /25:942 /26:1176 /27:584 /28:224 /29:14 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2627 4059 bellsouth.net, inc. 4323 2351 3791 Time Warner Telecom 4766 1466 1853 Korea Telecom (KIX) 1785 1258 1796 PaeTec Communications, Inc. 11492 1058 1146 Cable One 17488 1054 1293 Hathway IP Over Cable Interne 18566 1040 1059 Covad Communications 18101 947 1075 Reliance Infocom Ltd Internet 7018 938 1558 AT&T WorldNet Services 10620 916 1010 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:2 2:1 4:12 8:240 12:1981 13:10 15:22 16:3 17:8 20:39 24:1355 27:1 32:48 38:644 40:99 41:2059 44:3 46:1 47:26 52:6 55:2 56:2 57:23 58:640 59:632 60:400 61:1098 62:1053 63:1999 64:3818 65:2360 66:4150 67:1797 68:1042 69:2846 70:694 71:237 72:1880 73:2 74:2137 75:242 76:334 77:827 78:590 79:399 80:990 81:778 82:450 83:449 84:655 85:1023 86:385 87:683 88:425 89:1529 90:77 91:2700 92:435 93:1143 94:1397 95:528 96:234 97:302 98:503 99:26 100:1 109:389 110:296 111:449 112:239 113:241 114:373 115:574 116:1022 117:630 118:390 119:940 120:148 121:842 122:1380 123:865 124:1068 125:1285 128:208 129:205 130:141 131:486 132:204 133:17 134:195 135:43 136:226 137:171 138:240 139:92 140:474 141:135 142:379 143:347 144:413 145:51 146:407 147:168 148:573 149:209 150:151 151:168 152:257 153:167 154:2 155:278 156:178 157:327 158:99 159:358 160:305 161:177 162:270 163:166 164:311 165:495 166:506 167:390 168:783 169:161 170:710 171:46 172:2 173:529 174:542 175:60 178:3 180:351 182:24 183:228 184:13 186:306 187:223 188:1415 189:702 190:3526 192:5718 193:4527 194:3358 195:2803 196:1177 198:3553 199:3380 200:5259 201:1477 202:8042 203:8296 204:4074 205:2175 206:2507 207:3074 208:3913 209:3459 210:2544 211:1198 212:1703 213:1660 214:262 215:61 216:4472 217:1513 218:488 219:426 220:1074 221:380 222:304 End of report From web at typo.org Fri Mar 5 12:53:55 2010 From: web at typo.org (Wayne E. Bouchard) Date: Fri, 5 Mar 2010 11:53:55 -0700 Subject: FreeAxez raised flooring? In-Reply-To: <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> Message-ID: <20100305185355.GA48301@typo.org> On Fri, Mar 05, 2010 at 01:41:42PM -0500, William Herrin wrote: > On Fri, Mar 5, 2010 at 12:54 PM, Owen DeLong wrote: > > Not sure about the purpose of a raised floor if it doesn't create a plenum, but, the > > step forward from raised-floor plenum is hot-aisle/cold-aisle which requires a good > > bit more discipline in your datacenter, but, is substantially more efficient. > > Hi Owen, > > Hot-aisle/cold-aisle is a separate issue from a raised floor plenum. > They're mutually supportive but not mutually dependent. > > Raised floor has pros and cons which make it good or bad depending on > the environment. If you haven't yet started implementing hot > aisle/cold aisle, on the other hand, you're already the better part of > a decade out of date and your equipment is suffering for it. > > > For the original question: Non-plenum short raised floor can be useful > if you want to separate your power and data wiring. Other than that, I > can't see any advantage versus a solid floor and either snake tray or > other overhead wiring systems. Yeah, it made it easier to feed power by running whips instead of conduit and also got the power away from the data lines. The problem with running any wiring under the floor is it always becomes a place to hide the bodies. (Ever looked under a floor that's been there for 20 years?) If you also used it as a cold air plenum, bad wiring and so on also interferes with airflow and people removing tiles or having to cut tiles to get around this or that affects your static pressure and throws your AC off. So these days, I personally favor nothing but air under the floor and strict policies regarding movement of floor tiles. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From owen at delong.com Fri Mar 5 12:54:42 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 02:54:42 +0800 Subject: FreeAxez raised flooring? In-Reply-To: <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> Message-ID: <0DB35DA7-9BF8-40CC-A9E5-AB74D06CD5A9@delong.com> On Mar 6, 2010, at 2:41 AM, William Herrin wrote: > On Fri, Mar 5, 2010 at 12:54 PM, Owen DeLong wrote: >> Not sure about the purpose of a raised floor if it doesn't create a plenum, but, the >> step forward from raised-floor plenum is hot-aisle/cold-aisle which requires a good >> bit more discipline in your datacenter, but, is substantially more efficient. > > Hi Owen, > > Hot-aisle/cold-aisle is a separate issue from a raised floor plenum. > They're mutually supportive but not mutually dependent. > I've never seen anyone do hot asile/cold aisle using raised floor. Overhead cabling has become the norm in most modern installations and once you go to hot aisle/cold aisle, you no longer need the lower plenum, so, while they can be mutually supportive, neither requires the other, and, in practical modern usage, hot-aisle/cold-aisle usually precludes the need for the additional expense of raised floor. Absent the need for the expense of the raised floor, it's rarely installed in my experience, thus making them mutually exclusive for most practical terms. Owen From bill at herrin.us Fri Mar 5 13:10:28 2010 From: bill at herrin.us (William Herrin) Date: Fri, 5 Mar 2010 14:10:28 -0500 Subject: FreeAxez raised flooring? In-Reply-To: <0DB35DA7-9BF8-40CC-A9E5-AB74D06CD5A9@delong.com> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> <0DB35DA7-9BF8-40CC-A9E5-AB74D06CD5A9@delong.com> Message-ID: <3c3e3fca1003051110v4cf23802k94f64a5c01d50cc6@mail.gmail.com> On Fri, Mar 5, 2010 at 1:54 PM, Owen DeLong wrote: > On Mar 6, 2010, at 2:41 AM, William Herrin wrote: >> On Fri, Mar 5, 2010 at 12:54 PM, Owen DeLong wrote: >>> Not sure about the purpose of a raised floor if it doesn't create a plenum, but, the >>> step forward from raised-floor plenum is hot-aisle/cold-aisle which requires a good >>> bit more discipline in your datacenter, but, is substantially more efficient. >> >> Hi Owen, >> >> Hot-aisle/cold-aisle is a separate issue from a raised floor plenum. >> They're mutually supportive but not mutually dependent. >> > I've never seen anyone do hot asile/cold aisle using raised floor. Hi Owen, Switch & Data in Vienna VA does it that way, as do parts of Equinix in Ashburn VA. As often as not it's a retrofit where the raised floor was already in place. Even if you're not, though, the heat-density in the modern data center is simply too high to prevent the warm air from the prior cabinet from entering the top of the next cabinet unless you either generate a minor hurricane through the floor or use a hot-aisle/cold-aisle design so that nobody's breathing the other guy's warm air. > Overhead cabling has become the norm in most modern installations > and once you go to hot aisle/cold aisle, you no longer need the lower > plenum, so, while they can be mutually supportive, neither requires > the other, and, in practical modern usage, hot-aisle/cold-aisle usually > precludes the need for the additional expense of raised floor. The ductwork for hot aisle cold air can get in the way of access to your wiring, especially in a large room. A raised floor obviates the need for ductwork. In general, though, I agree with you: if you don't already have raised floor it isn't worth the additional expense, at least not in the data center. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From web at typo.org Fri Mar 5 13:15:39 2010 From: web at typo.org (Wayne E. Bouchard) Date: Fri, 5 Mar 2010 12:15:39 -0700 Subject: FreeAxez raised flooring? In-Reply-To: <0DB35DA7-9BF8-40CC-A9E5-AB74D06CD5A9@delong.com> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> <0DB35DA7-9BF8-40CC-A9E5-AB74D06CD5A9@delong.com> Message-ID: <20100305191539.GA48474@typo.org> On Sat, Mar 06, 2010 at 02:54:42AM +0800, Owen DeLong wrote: > > On Mar 6, 2010, at 2:41 AM, William Herrin wrote: > > > On Fri, Mar 5, 2010 at 12:54 PM, Owen DeLong wrote: > >> Not sure about the purpose of a raised floor if it doesn't create a plenum, but, the > >> step forward from raised-floor plenum is hot-aisle/cold-aisle which requires a good > >> bit more discipline in your datacenter, but, is substantially more efficient. > > > > Hi Owen, > > > > Hot-aisle/cold-aisle is a separate issue from a raised floor plenum. > > They're mutually supportive but not mutually dependent. > > > I've never seen anyone do hot asile/cold aisle using raised floor. > > Overhead cabling has become the norm in most modern installations > and once you go to hot aisle/cold aisle, you no longer need the lower > plenum, so, while they can be mutually supportive, neither requires > the other, and, in practical modern usage, hot-aisle/cold-aisle usually > precludes the need for the additional expense of raised floor. > > Absent the need for the expense of the raised floor, it's rarely > installed in my experience, thus making them mutually exclusive > for most practical terms. > > Owen Actually, my experience has been that most of the newer installations (last 5-7 years) that I have been able to see where raised floor is employed are also doing hot/cold rows. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From streiner at cluebyfour.org Fri Mar 5 14:36:43 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 5 Mar 2010 15:36:43 -0500 (EST) Subject: 1G/10G options over 130 km of fiber Message-ID: A dark fiber path was recently ordered to a remote location on our network, and to my surprise, the engineering report on the path is coming back at around 130 km, which is substantially longer than I expected the span to be. While I am researching gear that will drive a signal this far without a mid-span regen, I'm also inquiring with the carrier to see if there is any way to shorten the span, but I also have to be prepared for the chance that a shorter span is not possible. I've seen some pieces from MRV and Transition that might be up to the job, though most of the options I've seen are rated to 120 km, tops. That said, I'd be interested in hearing about what people who are driving similar spans. I don't think I'm going to have the budget to go out and buy Ciena/Infinera/Cisco ONS kit just for this, since I don't have any at the present time. The link is still being built, so I haven't gotten an engineering report yet. My gut tells me that the 2-point loss on the span at 1550nm will be somewhere around 30-35 dB. jms From jeroen at mompl.net Fri Mar 5 14:43:12 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 05 Mar 2010 12:43:12 -0800 Subject: Colocation Monterey bay area In-Reply-To: References: Message-ID: <4B916CE0.5040200@mompl.net> Hello, Does anyone know of a good colocation facility in the California Monterey Bay area? I know of got.net but I am looking for alternatives to get a good comparison. Thanks, Jeroen From dwcarder at wisc.edu Fri Mar 5 14:46:28 2010 From: dwcarder at wisc.edu (Dale W. Carder) Date: Fri, 05 Mar 2010 14:46:28 -0600 Subject: 1G/10G options over 130 km of fiber In-Reply-To: References: Message-ID: On Mar 5, 2010, at 2:36 PM, Justin M. Streiner wrote: > My gut tells me that the 2-point loss on the span at 1550nm will be somewhere around 30-35 dB. What's your measured chromatic dispersion? You might need to budget in the hit from compensation too. Some of the super long range optics have wide tolerance of dispersion, but probably not without a penalty. If you don't have a measurement, you can estimate w/ the values for that fiber type. Dale From akg1330 at gmail.com Fri Mar 5 14:53:32 2010 From: akg1330 at gmail.com (Andrew Gallo) Date: Fri, 05 Mar 2010 15:53:32 -0500 Subject: 1G/10G options over 130 km of fiber In-Reply-To: References: Message-ID: <4B916F4C.50705@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/5/2010 3:36 PM, Justin M. Streiner wrote: > A dark fiber path was recently ordered to a remote location on our > network, and to my surprise, the engineering report on the path is > coming back at around 130 km, which is substantially longer than I > expected the span to be. > > While I am researching gear that will drive a signal this far without a > mid-span regen, I'm also inquiring with the carrier to see if there is > any way to shorten the span, but I also have to be prepared for the > chance that a shorter span is not possible. > > I've seen some pieces from MRV and Transition that might be up to the > job, though most of the options I've seen are rated to 120 km, tops. > > That said, I'd be interested in hearing about what people who are > driving similar spans. I don't think I'm going to have the budget to go > out and buy Ciena/Infinera/Cisco ONS kit just for this, since I don't > have any at the present time. The link is still being built, so I > haven't gotten an engineering report yet. My gut tells me that the > 2-point loss on the span at 1550nm will be somewhere around 30-35 dB. > > jms > You have to be real careful running 10G at those distance. Loss isn't the only thing you have to worry about...you may need dispersion compensation, which by itself is going to add to your loss. If loss is your only worry, then you might be able to do a pre/post amplification. 130km is far, but you might be able to skip midspan amplification. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRb0wACgkQQr/gMVyFYyRolQCglE6LvTfj9fFcBGejAoCIrTGD R1EAn0p2LHd32OMbLzH+h83vjRkmcmE/ =bOT0 -----END PGP SIGNATURE----- From ctracy at es.net Fri Mar 5 14:58:53 2010 From: ctracy at es.net (Chris Tracy) Date: Fri, 5 Mar 2010 15:58:53 -0500 Subject: 1G/10G options over 130 km of fiber In-Reply-To: References: Message-ID: It would be helpful to know what type of fiber you are working with...SMF-28(e) G.652, NZDSF G.655, ...? You not only need to account for dB loss over the span, but also chromatic dispersion. At 1550nm, you can expect <= 0.22 dB/km for SMF-28 G.652 if you have a nice clean fiber path...possibly even <= 0.20 dB/km. (Got any OTDR or CD test results? Your provider might be able to give them to you...) 80km DWDM XFPs typically launch between -1 to +3 dBm, and are only sensitive down to about -24 to -25 dBm. Unfortunately, I don't have any data sheets on the 120km versions handy, but I suspect you will be close to the edge. :-) As Dale mentioned, long-reach optics typically have something like "path penalty at 1450 ps/nm = 2.5dB" in the optical characteristics, so you need to factor that into your budget as well. The amount of chromatic dispersion can either be measured or estimated -- but it will greatly depend on which type of fiber you are using. In general, find out what the maximum amount of chromatic dispersion the receiver can handle for whatever optics you are considering. Then look at a datasheet for the fiber you have (or actually measure it) to see if you are within the spec given in the transceiver datasheet. Cheers, -Chris On Mar 5, 2010, at 3:36 PM, Justin M. Streiner wrote: > A dark fiber path was recently ordered to a remote location on our network, and to my surprise, the engineering report on the path is coming back at around 130 km, which is substantially longer than I expected the span to be. > > While I am researching gear that will drive a signal this far without a mid-span regen, I'm also inquiring with the carrier to see if there is any way to shorten the span, but I also have to be prepared for the chance that a shorter span is not possible. > > I've seen some pieces from MRV and Transition that might be up to the job, though most of the options I've seen are rated to 120 km, tops. > > That said, I'd be interested in hearing about what people who are driving similar spans. I don't think I'm going to have the budget to go out and buy Ciena/Infinera/Cisco ONS kit just for this, since I don't have any at the present time. The link is still being built, so I haven't gotten an engineering report yet. My gut tells me that the 2-point loss on the span at 1550nm will be somewhere around 30-35 dB. > > jms > From surfer at mauigateway.com Fri Mar 5 15:09:07 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 5 Mar 2010 13:09:07 -0800 Subject: BFD vs BGP timers Message-ID: <20100305130907.2BF4BEF5@resin14.mta.everyone.net> We're having discussion of changing BGP timers rather than using BFD and I'd like to ask for your operational experiences on this. We have downstream BGP customers physically attaching to an L2/L3 switch that doesn't do BGP. So, we logical pipe them through MPLS to a router that can terminate the BGP session. The logical pipe never goes down, so the only thing that would cause the customer's session to go down in the event of a physical layer problem is the BGP timer. This is not acceptable, so I have been using BFD to time out the BGP session. However, we have limitations on the BFD pps and folks here are wanting to change the BGP timers instead. What're your experiences regarding this? scott From tdurack at gmail.com Fri Mar 5 15:11:10 2010 From: tdurack at gmail.com (Tim Durack) Date: Fri, 5 Mar 2010 16:11:10 -0500 Subject: FreeAxez raised flooring? In-Reply-To: <20100305191539.GA48474@typo.org> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> <0DB35DA7-9BF8-40CC-A9E5-AB74D06CD5A9@delong.com> <20100305191539.GA48474@typo.org> Message-ID: <9e246b4d1003051311j180cf409ya0fea8ef9531660f@mail.gmail.com> On Fri, Mar 5, 2010 at 2:15 PM, Wayne E. Bouchard wrote: > Actually, my experience has been that most of the newer installations > (last 5-7 years) that I have been able to see where raised floor is > employed are also doing hot/cold rows. We have/are building new datacenters with a raised floor plenum. Air is directed into the racks from below, and ducted out of the top. No hot/cold aisle, just lots of cold air to cool the equipment. It's an AFCO rack design. Seems to be efficient so far. -- Tim:> From zcfrederick at gmail.com Fri Mar 5 15:33:26 2010 From: zcfrederick at gmail.com (Zachary Frederick) Date: Fri, 5 Mar 2010 16:33:26 -0500 Subject: Problem from Comcast Network to The Planet Message-ID: <9805C6F4-6E91-4F47-9458-2005774D7C87@gmail.com> We have been having a problem emailing to a customer whose server is hosted by The Planet (http://www.theplanet.com/). Our mail server is hosted in-house on a comcast business connection. IP address of our server is: 173.13.45.23 Customers mail server is: 69.93.203.243 I cannot telnet to port 25 on their server, and they cannot telnet to port 25 on ours. If I try to connect to their mail server from a different network such as my home internet connection, I can connect. We do not do any firewalling that would block this in anyway. We were able to send and receive email to them when we used Qwest for our connection, before we switched to Comcast. Comcast has said the problem is not on their end because it times out at The Planet. The Planet doesn't have much interest in speaking with me, because I'm not their customer. Not sure what to do at this point. Below is a traceroute: traceroute to 69.93.203.243 (69.93.203.243), 64 hops max, 52 byte packets 1 223.254.254.75 (223.254.254.75) 2.610 ms 2.057 ms 2.033 ms 2 173-13-45-30-pennsylvania.hfc.comcastbusiness.net (173.13.45.30) 3.656 ms 2.997 ms 3.119 ms 3 * * * 4 68.85.72.129 (68.85.72.129) 10.497 ms 9.624 ms 12.245 ms 5 te-9-1-ur02.greensburg.pa.pitt.comcast.net (68.86.100.53) 9.935 ms 10.049 ms 10.505 ms 6 te-3-2-ar01.mckeesport.pa.pitt.comcast.net (68.86.100.49) 14.795 ms 12.846 ms 14.006 ms 7 te-0-4-0-5-cr01.mclean.va.ibone.comcast.net (68.86.91.129) 17.868 ms 16.278 ms 21.110 ms 8 pos-1-10-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.86.126) 43.022 ms 40.690 ms 39.818 ms 9 pos-1-15-0-0-cr01.dallas.tx.ibone.comcast.net (68.86.85.149) 58.980 ms 58.914 ms 59.673 ms 10 pos-0-0-0-0-pe01.1950stemmons.tx.ibone.comcast.net (68.86.86.90) 59.608 ms 60.322 ms 59.691 ms 11 theplanet-cr01.dallas.tx.ibone.comcast.net (75.149.228.2) 62.246 ms 61.320 ms 61.693 ms 12 te3-5.dsr01.dllstx3.theplanet.com (70.87.253.86) 61.431 ms te7-1.dsr02.dllstx3.theplanet.com (70.87.253.18) 58.859 ms 59.365 ms 13 76.fd.5746.static.theplanet.com (70.87.253.118) 62.690 ms te1-3.dsr02.dllstx2.theplanet.com (70.87.253.122) 68.123 ms te3-3.dsr02.dllstx2.theplanet.com (70.87.253.126) 59.382 ms 14 po1.car02.dllstx2.theplanet.com (70.87.254.82) 59.321 ms 60.268 ms 66.206 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 31 * * * 32 * * * 33 * * * 34 * * * 35 * *^C From jay at west.net Fri Mar 5 15:40:10 2010 From: jay at west.net (Jay Hennigan) Date: Fri, 05 Mar 2010 13:40:10 -0800 Subject: Problem from Comcast Network to The Planet In-Reply-To: <9805C6F4-6E91-4F47-9458-2005774D7C87@gmail.com> References: <9805C6F4-6E91-4F47-9458-2005774D7C87@gmail.com> Message-ID: <4B917A3A.80408@west.net> On 3/5/10 1:33 PM, Zachary Frederick wrote: > We have been having a problem emailing to a customer whose server is hosted by The Planet (http://www.theplanet.com/). Our mail server is hosted in-house on a comcast business connection. > > IP address of our server is: 173.13.45.23 > > Customers mail server is: 69.93.203.243 > > I cannot telnet to port 25 on their server, and they cannot telnet to port 25 on ours. > > If I try to connect to their mail server from a different network such as my home internet connection, I can connect. > We do not do any firewalling that would block this in anyway. We were able to send and receive email to them when we used Qwest for our connection, before we switched to Comcast. > > Comcast has said the problem is not on their end because it times out at The Planet. > The Planet doesn't have much interest in speaking with me, because I'm not their customer. Have the recipient who is a The Planet customer open a case with them. For what it's worth (not much, I know), it works from here. Mail server is likely behind a PIX with SMTP fixup enabled. ~ jay$ telnet 69.93.203.243 25 Trying 69.93.203.243... Connected to mx.insurancewebsitebuilder.com. Escape character is '^]'. 220 ******************************************************************************************** -- 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 smb at cs.columbia.edu Fri Mar 5 15:41:03 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 5 Mar 2010 16:41:03 -0500 Subject: Problem from Comcast Network to The Planet In-Reply-To: <9805C6F4-6E91-4F47-9458-2005774D7C87@gmail.com> References: <9805C6F4-6E91-4F47-9458-2005774D7C87@gmail.com> Message-ID: On Mar 5, 2010, at 4:33 PM, Zachary Frederick wrote: > We have been having a problem emailing to a customer whose server is hosted by The Planet (http://www.theplanet.com/). Our mail server is hosted in-house on a comcast business connection. > > IP address of our server is: 173.13.45.23 > > Customers mail server is: 69.93.203.243 > > I cannot telnet to port 25 on their server, and they cannot telnet to port 25 on ours. > > If I try to connect to their mail server from a different network such as my home internet connection, I can connect. > We do not do any firewalling that would block this in anyway. We were able to send and receive email to them when we used Qwest for our connection, before we switched to Comcast. > > Comcast has said the problem is not on their end because it times out at The Planet. > The Planet doesn't have much interest in speaking with me, because I'm not their customer. > > Not sure what to do at this point. > > Below is a traceroute: If you have a suitable platform, try tcptraceroute and see where port 25 is blocked. From chip.gwyn at gmail.com Fri Mar 5 15:41:20 2010 From: chip.gwyn at gmail.com (chip) Date: Fri, 5 Mar 2010 16:41:20 -0500 Subject: 1G/10G options over 130 km of fiber In-Reply-To: References: Message-ID: <64a8ad981003051341k418f0cadt3d5509782db10582@mail.gmail.com> That length you're probably going to need Raman amps. As others have mentioned, if you're planning on 10G or higher you'll need to think about Chromatic and Polarization dispersion. If the fiber is still in the process of being laid it shouldn't be too bad assuming the fiber is of high quality. --chip On Fri, Mar 5, 2010 at 3:58 PM, Chris Tracy wrote: > It would be helpful to know what type of fiber you are working > with...SMF-28(e) G.652, NZDSF G.655, ...? > > You not only need to account for dB loss over the span, but also chromatic > dispersion. > > At 1550nm, you can expect <= 0.22 dB/km for SMF-28 G.652 if you have a nice > clean fiber path...possibly even <= 0.20 dB/km. (Got any OTDR or CD test > results? Your provider might be able to give them to you...) > > 80km DWDM XFPs typically launch between -1 to +3 dBm, and are only > sensitive down to about -24 to -25 dBm. Unfortunately, I don't have any > data sheets on the 120km versions handy, but I suspect you will be close to > the edge. :-) > > As Dale mentioned, long-reach optics typically have something like "path > penalty at 1450 ps/nm = 2.5dB" in the optical characteristics, so you need > to factor that into your budget as well. The amount of chromatic dispersion > can either be measured or estimated -- but it will greatly depend on which > type of fiber you are using. In general, find out what the maximum amount > of chromatic dispersion the receiver can handle for whatever optics you are > considering. Then look at a datasheet for the fiber you have (or actually > measure it) to see if you are within the spec given in the transceiver > datasheet. > > Cheers, > -Chris > > > On Mar 5, 2010, at 3:36 PM, Justin M. Streiner wrote: > > > A dark fiber path was recently ordered to a remote location on our > network, and to my surprise, the engineering report on the path is coming > back at around 130 km, which is substantially longer than I expected the > span to be. > > > > While I am researching gear that will drive a signal this far without a > mid-span regen, I'm also inquiring with the carrier to see if there is any > way to shorten the span, but I also have to be prepared for the chance that > a shorter span is not possible. > > > > I've seen some pieces from MRV and Transition that might be up to the > job, though most of the options I've seen are rated to 120 km, tops. > > > > That said, I'd be interested in hearing about what people who are driving > similar spans. I don't think I'm going to have the budget to go out and buy > Ciena/Infinera/Cisco ONS kit just for this, since I don't have any at the > present time. The link is still being built, so I haven't gotten an > engineering report yet. My gut tells me that the 2-point loss on the span > at 1550nm will be somewhere around 30-35 dB. > > > > jms > > > > > > > > > -- Just my $.02, your mileage may vary, batteries not included, etc.... From JSaxe at briworks.com Fri Mar 5 15:45:57 2010 From: JSaxe at briworks.com (Jeff Saxe) Date: Fri, 5 Mar 2010 16:45:57 -0500 Subject: BFD vs BGP timers In-Reply-To: <20100305130907.2BF4BEF5@resin14.mta.everyone.net> References: <20100305130907.2BF4BEF5@resin14.mta.everyone.net> Message-ID: <4578A474-611F-4C5C-8FAF-D4F9EEBBB5B0@briworks.com> I've had no problems with it. We also have routers attached to Ethernet (both our own switches and external Layer 1 or Layer 2 Ethernet private circuits), and we had similar problems of uncomfortably long time-to-detection. Our routers were too old to run BFD, and I'm not sure what the likelihood is for asking an outside provider to perform BFD with us, so I just configured the BGP timers to much smaller. I chose what I believe was the minimum on our Cisco equipment at the time, keepalives every 10 seconds and die after 30 seconds. I have had no ill effects at all (no spurious BGP down/ups in the middle of the night), and it has actually shortened the detection time in one or maybe two unexpected failures, so I'd call it a success. router bgp 22070 timers bgp 10 30 This is global to the BGP process (i.e., all neighbors default), but there also appears to be a "neighbor x.x.x.x timers" command that can tweak it per neighbor. Note that you have to make the timers change in a maintenance window; BGP timers are negotiated between peering routers at the start of the BGP session, so changing the values might result in closing and reestablishing all those peers. Also note that a peer can declare a minimum acceptable hold time that they will accept from you, so if you would prefer the session to die after 30 seconds, but one of your peers says that's too short, I guess it's possible that the BGP session would try to come up and fail, over and over. None of our external peers objected when we set ourselves to 10 and 30. We do have more modern routers now, so maybe I should get off my behind and try BFD. I'm probably behind the curve here. -- Jeff Saxe, Network Engineer Blue Ridge InternetWorks, Charlottesville, VA CCIE # 9376 434-817-0707 ext. 2024 (work) / 434-882-3508 (cell) / JSaxe at briworks.com On Mar 5, 2010, at 4:09 PM, Scott Weeks wrote: > > > We're having discussion of changing BGP timers rather than using BFD > and I'd like to ask for your operational experiences on this. > > We have downstream BGP customers physically attaching to an L2/L3 > switch that doesn't do BGP. So, we logical pipe them through MPLS > to a router that can terminate the BGP session. The logical pipe > never goes down, so the only thing that would cause the customer's > session to go down in the event of a physical layer problem is the > BGP timer. > > This is not acceptable, so I have been using BFD to time out the BGP > session. However, we have limitations on the BFD pps and folks here > are wanting to change the BGP timers instead. > > What're your experiences regarding this? > > scott > From drc at virtualized.org Fri Mar 5 15:48:31 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 5 Mar 2010 16:48:31 -0500 Subject: IP4 Space In-Reply-To: <4B9126E0.5070607@bogus.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <4B9126E0.5070607@bogus.com> Message-ID: <56EBFD70-F0A6-4FD6-AF02-86E89CB2F66E@virtualized.org> On Mar 5, 2010, at 10:44 AM, Joel Jaeggli wrote: > If this is done right, direct assignment holders and ISPs are issued > sufficiently large prefixes such that the prefix count per entity > remains small. This sort of assumes Internet connectivity models of today, specifically that most address assignments are singly-homed and thus can be aggregatedd within a larger provider independent block, will remain the model of tomorrow. I have some skepticism this will be true. When entertainment, communications, monitoring, etc. are all provided via always-on IP connectivity, I suspect you'll see folks have less tolerance for even momentary outages. And that's not even considering mobility solutions that rely on the routing system (e.g., stuff like Boeing's Connexion (RIP)). We'll see I suppose. Regards, -drc From cidr-report at potaroo.net Fri Mar 5 16:00:04 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Mar 2010 22:00:04 GMT Subject: BGP Update Report Message-ID: <201003052200.o25M04bQ003134@wattle.apnic.net> BGP Update Report Interval: 25-Feb-10 -to- 04-Mar-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS17974 23415 1.3% 24.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 2 - AS31055 19604 1.1% 4901.0 -- CONSULTIX-AS Consultix GmbH 3 - AS6389 18071 1.0% 4.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 4 - AS22047 17001 1.0% 32.0 -- VTR BANDA ANCHA S.A. 5 - AS8346 16405 0.9% 1261.9 -- SONATEL-AS Autonomous System 6 - AS4323 15913 0.9% 3.6 -- TWTC - tw telecom holdings, inc. 7 - AS9829 15820 0.9% 18.8 -- BSNL-NIB National Internet Backbone 8 - AS6429 15706 0.9% 119.0 -- Telmex Chile Internet S.A. 9 - AS8452 13657 0.8% 13.6 -- TEDATA TEDATA 10 - AS14420 13432 0.8% 33.5 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 11 - AS7303 12543 0.7% 17.6 -- Telecom Argentina S.A. 12 - AS6471 11434 0.7% 28.2 -- ENTEL CHILE S.A. 13 - AS14117 10265 0.6% 23.6 -- Telefonica del Sur S.A. 14 - AS20115 8861 0.5% 5.7 -- CHARTER-NET-HKY-NC - Charter Communications 15 - AS17908 8395 0.5% 10.9 -- TCISL Tata Communications 16 - AS8151 8364 0.5% 5.2 -- Uninet S.A. de C.V. 17 - AS16569 7995 0.5% 3997.5 -- ASN-CITY-OF-CALGARY - City of Calgary 18 - AS4755 7837 0.5% 6.0 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 19 - AS7545 7579 0.4% 7.7 -- TPG-INTERNET-AP TPG Internet Pty Ltd 20 - AS7018 7461 0.4% 4.7 -- ATT-INTERNET4 - AT&T WorldNet Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS31055 19604 1.1% 4901.0 -- CONSULTIX-AS Consultix GmbH 2 - AS16569 7995 0.5% 3997.5 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - AS26025 6901 0.4% 3450.5 -- COC - City of Calgary 4 - AS7419 3938 0.2% 1969.0 -- MONMOUTH-AS - Monmouth University 5 - AS27097 5535 0.3% 1383.8 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 6 - AS8346 16405 0.9% 1261.9 -- SONATEL-AS Autonomous System 7 - AS45985 3581 0.2% 1193.7 -- DAEWOOSEC Daewoo Securities Co., Ltd. 8 - AS1619 776 0.0% 776.0 -- PLANET-DATA - Planet Data Solutions, Inc. 9 - AS27245 1205 0.1% 602.5 -- HEIDRICK-CHICAGO - HEIDRICK 10 - AS45960 543 0.0% 543.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 11 - AS35291 877 0.1% 438.5 -- ICOMM-AS SC Internet Communication Systems SRL 12 - AS28052 350 0.0% 350.0 -- Arte Radiotelevisivo Argentino 13 - AS42220 319 0.0% 319.0 -- SIAPI-AS SIAPI NETWORKS AS NUMBER 14 - AS4103 284 0.0% 284.0 -- APPOC - Headquarters, USAISC 15 - AS8657 1364 0.1% 272.8 -- CPRM CPRM Autonomous System 16 - AS12837 268 0.0% 268.0 -- OLDBANK-NET JSB Starokievsky Bank 17 - AS32794 518 0.0% 259.0 -- ICFG - International Church of the Foursquare Gospel 18 - AS45653 1964 0.1% 245.5 -- ACURE-AS-AP aCure Technology, Data Centres, Perth 19 - AS35714 1185 0.1% 237.0 -- INFOSERVICE-UA Infoservice Comp Private Venture, Internet Service Provider 20 - AS27094 470 0.0% 235.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 62.168.199.0/24 19565 0.9% AS31055 -- CONSULTIX-AS Consultix GmbH 2 - 208.98.230.0/24 7991 0.4% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - 208.98.231.0/24 6898 0.3% AS26025 -- COC - City of Calgary 4 - 208.154.200.0/24 5481 0.3% AS8346 -- SONATEL-AS Autonomous System 5 - 208.144.230.0/24 5462 0.3% AS8346 -- SONATEL-AS Autonomous System 6 - 214.15.217.0/24 5430 0.3% AS27097 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 7 - 208.154.199.0/24 5424 0.3% AS8346 -- SONATEL-AS Autonomous System 8 - 143.138.107.0/24 3434 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 9 - 199.114.154.0/24 3127 0.1% AS1733 -- CENTAF-SWA - 754th Electronic Systems Group 10 - 192.12.120.0/24 2545 0.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 11 - 41.235.80.0/24 2340 0.1% AS8452 -- TEDATA TEDATA 12 - 38.107.132.0/22 2122 0.1% AS7419 -- MONMOUTH-AS - Monmouth University 13 - 155.94.80.0/24 2006 0.1% AS17003 -- AHP - WYETH-AYERST/AMERICAN HOME PRODUCTS 14 - 24.38.48.0/22 1816 0.1% AS7419 -- MONMOUTH-AS - Monmouth University 15 - 212.220.14.0/24 1494 0.1% AS34875 -- YANFES OJSC "Uralsviazinform" 16 - 41.210.192.0/18 1367 0.1% AS37081 -- movicel-as AS8657 -- CPRM CPRM Autonomous System 17 - 63.84.91.0/24 1201 0.1% AS27245 -- HEIDRICK-CHICAGO - HEIDRICK 18 - 210.92.10.0/24 1195 0.1% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 19 - 210.92.4.0/24 1195 0.1% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 20 - 123.140.107.0/24 1191 0.1% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 5 16:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Mar 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201003052200.o25M009S003128@wattle.apnic.net> This report has been generated at Fri Mar 5 21:11:26 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 26-02-10 314600 193576 27-02-10 314835 193273 28-02-10 314692 193106 01-03-10 314460 193358 02-03-10 314824 193743 03-03-10 315117 194540 04-03-10 315596 194483 05-03-10 315456 194821 AS Summary 33779 Number of ASes in routing system 14388 Number of ASes announcing only one prefix 4391 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 93176320 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'). --- 05Mar10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 315792 194686 121106 38.3% All ASes AS6389 4060 317 3743 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4391 1855 2536 57.8% TWTC - tw telecom holdings, inc. AS4766 1853 486 1367 73.8% KIXS-AS-KR Korea Telecom AS1785 1796 648 1148 63.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1284 210 1074 83.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1128 74 1054 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1059 33 1026 96.9% COVAD - Covad Communications Co. AS17488 1293 361 932 72.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1578 661 917 58.1% Uninet S.A. de C.V. AS10620 1010 170 840 83.2% TV Cable S.A. AS19262 1071 242 829 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18101 1075 247 828 77.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1129 442 687 60.9% ATT-INTERNET3 - AT&T WorldNet Services AS8452 993 359 634 63.8% TEDATA TEDATA AS5668 801 193 608 75.9% AS-5668 - CenturyTel Internet Holdings, Inc. AS4804 678 72 606 89.4% MPX-AS Microplex PTY LTD AS4808 837 234 603 72.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 679 107 572 84.2% Telecom Argentina S.A. AS4134 1018 458 560 55.0% CHINANET-BACKBONE No.31,Jin-rong Street AS7018 1556 1004 552 35.5% ATT-INTERNET4 - AT&T WorldNet Services AS7545 972 428 544 56.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1210 668 542 44.8% LEVEL3 Level 3 Communications AS17908 768 230 538 70.1% TCISL Tata Communications AS24560 829 291 538 64.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS28573 901 367 534 59.3% NET Servicos de Comunicao S.A. AS35805 585 75 510 87.2% UTG-AS United Telecom AS AS4780 629 137 492 78.2% SEEDNET Digital United Inc. AS22047 529 41 488 92.2% VTR BANDA ANCHA S.A. AS17676 563 83 480 85.3% GIGAINFRA Softbank BB Corp. AS11492 1146 694 452 39.4% CABLEONE - CABLE ONE, INC. Total 37421 11187 26234 70.1% Top 30 total Possible Bogus Routes 2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.77.236.0/22 AS5.8 41.190.64.0/22 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 41.202.96.0/19 AS29571 CITelecom-AS 41.216.32.0/19 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 41.220.144.0/20 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.24.0/22 AS25747 VSC-SATELLITE-CO - VSC Satellite Co. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.193.160.0/19 AS22351 INTELSAT Intelsat Global BGP Routing Policy 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 80.250.32.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.34.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 81.91.224.0/20 AS28683 OPT-NTIC-AS Office des Postes et telecommunications du Benin 100.100.100.0/24 AS36992 ETISALAT-MISR 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering AS 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 172.7.0.0/24 AS36992 ETISALAT-MISR 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.129.127.0/24 AS6568 Ag para el Desarrollo de la Sociedad de la Inf en Bolivia - ADSIB 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.29.40.0/22 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 196.32.96.0/20 AS33787 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.254.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.216.4.0/22 AS23889 MAURITIUS-TELECOM-AS-AP 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS17233 ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 198.74.39.0/24 AS17233 ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 198.74.40.0/24 AS17233 ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.72.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.73.0/24 AS9425 CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.77.138.0/23 AS24487 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.184.0/23 AS24487 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.124.96.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.100.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.104.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.160.130.0/23 AS24487 203.160.140.0/24 AS45560 203.160.141.0/24 AS10026 ANC Asia Netcom Corporation 203.160.142.0/24 AS45560 203.160.143.0/24 AS10026 ANC Asia Netcom Corporation 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.108.96.0/19 AS577 BACOM - Bell Canada 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/24 AS31997 209.87.223.0/24 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.29.208.0/23 AS33774 DJAWEB 217.29.212.0/23 AS33774 DJAWEB Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cb.list6 at gmail.com Fri Mar 5 16:08:26 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 5 Mar 2010 14:08:26 -0800 Subject: IP4 Space - the lie In-Reply-To: References: <20100305152153.GA10496@farside.isc.org> <20100305153749.GB21422@vacation.karoshi.com.> Message-ID: On Fri, Mar 5, 2010 at 10:16 AM, Owen DeLong wrote: >> >> ? ? ? there is a real danger here ... wholesale adoption of a >> ? ? ? translation technology, esp one that is integrated into >> ? ? ? the network kind of ensures that it will never get pulled out - >> ? ? ? or that the enduser will have a devil of a time routing around >> ? ? ? it when it no longer works for her - but the ISP sees her as a >> ? ? ? statistically anomaly. >> >> ? ? ? I would argue that the right/correct place for such translation >> ? ? ? technology is very close to the edge - in much the same way as >> ? ? ? NAT technology is roughl an "edge" technology. ?(ok - it used to be but w/ >> ? ? ? CGN .. its clearly moved. >> >> ? ? ? we -need- the technologies - but only for a while. ?otherwise they >> ? ? ? become a drug that we are dependent on. and we will be stuck on the >> ? ? ? dual-stack plateau for a much longer time that we should. >> >> ? ? ? imho of coure ... YM (and business models) MV >> > Bill, > ? ? ? ?While the DS-LIte mechanism does involve moving the NAT > towards the Core instead of leaving it at the edge, the advantage > is that you can route around it very easily as an end-user. ?Every > thing the end user sends to an IPv6 destination bypasses the NAT > box completely and only IPv4 is afflicted. NAT64/DNS64 is the same way, it gracefully drops out of the network as more and more content provides publish their own AAAA records. Most mobile providers today do NAT44, so NAT64 from an IPv6-only host (phones) is very appealing and familiar The day we switch from NAT44 to NAT64 (it's not a flag day, one new device model at a time), we will have a substantial NET savings in NAT state since all the IPv6 content folks with AAAA will no longer have their content hobbled by the NAT44 that exists today. Mobile network operator will begin to see the light at the end of the NATx(x|y) tunnel. The end of the NAT tunnel means lower cost and higher availability. And once again, the content folks passing IPv4 literals may have heart burn since IPv6-only won't initiate a connection to an IPv4 literal address embedded in HTML / XML .... DNS64 helps with this in the normal FQDN case, but passing IPv4 literals breaks the model and communications fails. > > ? ? ? ?I think that will be fairly easy to deprecate over time vs. many > many edge-NATs and layers of NATs near the edge. > > Owen > > From drc at virtualized.org Fri Mar 5 16:08:50 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 5 Mar 2010 17:08:50 -0500 Subject: IP4 Space In-Reply-To: <59AEDC03-BCC7-4027-8818-CF6353455BE8@delong.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> <59AEDC03-BCC7-4027-8818-CF6353455BE8@delong.com> Message-ID: <03DBD526-6509-486B-ADB1-72C605D05637@virtualized.org> On Mar 5, 2010, at 1:21 PM, Owen DeLong wrote: >> The interesting question is at what point _can_ you do what you want without IPv4. It seems obvious that that point will be after the IPv4 free pool is exhausted, and as such, allocated-but-not-efficiently-used addresses will likely become worth the effort to reclaim. >> > Ah, but, that assumes that the need is located in a similar part of the network > to the reclamation, or, that the point of reclamation can be sufficiently motivated > to do so by the money offered by the point of need. Actually, no, not really. When you're dying of thirst, even muddy water can be mighty appealing. The fact that some prefixes you obtain may be filtered because they're too short merely means you have additional costs to reach the sites you care about. Don't know many ISPs that guarantee universal connectivity outside their own network today. Not sure why that would change in the future. > I suspect the organizations that have excess space and know where it is are > likely to hold onto it as a hedge against their future needs, or, try to extract > a very high market premium for it. Such folks will also have to take into consideration opportunity cost. Or they could make the strategic decision that all they really need is one or two ISP-provided public IPv4 addresses (in addition to IPv6) for their NATv4 box and public servers is all they really need and lease to their ISP the blocks they currently have in exchange for free connectivity or whatever. Etc. Myriad of possibilities. The point is that when the IPv4 free pool is exhausted, there will be disruptive change. It isn't clear to me that pretty much any of the existing policies or practices regarding IPv4 addressing will continue to apply. I've been disappointed that some folks in the RIR communities have been unable to understand this. Gave up arguing as I figure time will tell one way or the other. Regards, -drc From joelja at bogus.com Fri Mar 5 16:20:19 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 05 Mar 2010 14:20:19 -0800 Subject: IP4 Space In-Reply-To: <56EBFD70-F0A6-4FD6-AF02-86E89CB2F66E@virtualized.org> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <4B9126E0.5070607@bogus.com> <56EBFD70-F0A6-4FD6-AF02-86E89CB2F66E@virtualized.org> Message-ID: <4B9183A3.3070003@bogus.com> On 03/05/2010 01:48 PM, David Conrad wrote: > On Mar 5, 2010, at 10:44 AM, Joel Jaeggli wrote: >> If this is done right, direct assignment holders and ISPs are >> issued sufficiently large prefixes such that the prefix count per >> entity remains small. > > This sort of assumes Internet connectivity models of today, > specifically that most address assignments are singly-homed and thus > can be aggregatedd within a larger provider independent block, will > remain the model of tomorrow. I have some skepticism this will be > true. When entertainment, communications, monitoring, etc. are all > provided via always-on IP connectivity, I suspect you'll see folks > have less tolerance for even momentary outages. Multihoming while protecting your overall availabity isn't going to solve your momentary outage issue, convergence takes time (see bgp wedgies)... precomputed backup paths are of course the current cause celebre whether that be in intra-domain mpls or ipfrr. one can end-up quite deep down a rat-hole depending on the depth of the alternative paths that might be choosen to be computed. It would be deeply ironic I suppose of ipfrr were to produce new opportunities for instability that are more destructive than micro-loops currently are. > And that's not even > considering mobility solutions that rely on the routing system (e.g., > stuff like Boeing's Connexion (RIP)). Having the mobility agent for your airplane appear in the DFZ while cool was a fairly bad idea. There are in fact a surprisingly small number of objects which make rapid transcontinental transitions. and I'm personally of the belief that the DFZ routing table isn't really the place to solve that problem, for the same reason we don't solve the cellular mobility problem there either. > We'll see I suppose. > > Regards, -drc > From Greg.Whynott at oicr.on.ca Fri Mar 5 16:31:38 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 5 Mar 2010 17:31:38 -0500 Subject: Bell canada CIDR Message-ID: Hello, We received a /21 from ARIN a year or so ago which we have been using. At the time I noticed Bell was advertising a longer CIDR which included ours. I contacted Bell, they said it would be corrected, multiple times. Who I might contact to have this resolved? Thanks for your time, greg AS11628 ipcalc 206.108.120.0/21 => Network: 206.108.120.0/21 HostMin: 206.108.120.1 HostMax: 206.108.127.254 AS577 ipcalc 206.108.96.0/19 => Network: 206.108.96.0/19 HostMin: 206.108.96.1 HostMax: 206.108.127.254 From morrowc.lists at gmail.com Fri Mar 5 16:44:55 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 5 Mar 2010 17:44:55 -0500 Subject: Bell canada CIDR In-Reply-To: References: Message-ID: <75cb24521003051444p54e4cae1xb16b3ad07468bc12@mail.gmail.com> On Fri, Mar 5, 2010 at 5:31 PM, Greg Whynott wrote: > Hello, > > We received a /21 from ARIN a year or so ago which we have been using. ?At the time I noticed Bell was advertising a longer > CIDR which included ours. ?I contacted Bell, they said it would be corrected, ?multiple times. shorter cidr.... less specific route. it shouldn't matter, unless someone filters the more specific...it's not nice of them, for sure. > > Who I might contact to have this resolved? > Thanks for your time, > greg > > > AS11628 > ipcalc 206.108.120.0/21 > => > Network: ? 206.108.120.0/21 > HostMin: ? 206.108.120.1 > HostMax: ? 206.108.127.254 > > > AS577 > ipcalc 206.108.96.0/19 > => NetRange: 206.108.96.0 - 206.108.111.255 CIDR: 206.108.96.0/20 NetName: BELLADVCOM-2BLK NetHandle: NET-206-108-96-0-1 looks like they flubbed their static route :( There are more than a few bell.ca folks who read nanog... -chris > Network: ? 206.108.96.0/19 > HostMin: ? 206.108.96.1 > HostMax: ? 206.108.127.254 > > From cra at WPI.EDU Fri Mar 5 16:50:22 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 5 Mar 2010 17:50:22 -0500 Subject: Bell canada CIDR In-Reply-To: References: Message-ID: <20100305225022.GB12615@angus.ind.WPI.EDU> On Fri, Mar 05, 2010 at 05:31:38PM -0500, Greg Whynott wrote: > Hello, > > We received a /21 from ARIN a year or so ago which we have been > using. At the time I noticed Bell was advertising a longer CIDR > which included ours. I contacted Bell, they said it would be > corrected, multiple times. > > Who I might contact to have this resolved? Contact everyone who peers with them and ask them to filter their illegal route :-) Or ask them to ask Bell Canada to fix their misconfiguration. From cboyd at gizmopartners.com Fri Mar 5 17:40:45 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Fri, 5 Mar 2010 17:40:45 -0600 Subject: Problem from Comcast Network to The Planet In-Reply-To: <9805C6F4-6E91-4F47-9458-2005774D7C87@gmail.com> References: <9805C6F4-6E91-4F47-9458-2005774D7C87@gmail.com> Message-ID: <5DF52A7E-7288-433B-8B08-EA9530B29400@gizmopartners.com> On Mar 5, 2010, at 3:33 PM, Zachary Frederick wrote: > We have been having a problem emailing to a customer whose server is hosted by The Planet (http://www.theplanet.com/). Our mail server is hosted in-house on a comcast business connection. I don't know what's going on in the Comcast network, but I've been having similar fits with a single IP address in my network. Comcast can get to nearby IP addresses in the same /24 no issue. The Comcast customer in my case is in Florida, and I get to them via TWTelecom. I know it's not my net, and TWT was very helpful and knows it's not their net. Attempts to get Comcast to look into it seem to end with them pinging their customer's IP address from the Comcast support center and terminating the call "since they can reach them." --Chris From jimb at jsbc.cc Fri Mar 5 17:51:20 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Fri, 05 Mar 2010 15:51:20 -0800 Subject: IP4 Space - the lie In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> Message-ID: <4B9198F8.4020705@jsbc.cc> On 3/5/2010 06:38, Cameron Byrne wrote: > There is one of other catch with NAT64 and IPv6-only. It breaks > communications with IPv4 literals. Now, you might says that IPv4 > literals in URLs are very seldom.... well ... have a look at how > Akamai does a lot of their streaming. I just hope it does not come to > a show-down where networks move to IPv6-only since IPv4 is a goner and > now Akamai content is not available while IPv6 early adopters like > Google and Limelight laugh all the way to bank. > One of the reasons I like the idea of DS-Lite. It may not be as native-IPv6 pure-and-holy as NAT64/DNS64, but it allows end users, IPv4 only applications, and legacy/non-IPv6 equipment to actually use IPv4 addresses. When the end user's favorite application stops working, or he can't play games online with his Xbox 360, he won't care about any explanations of NAT64/DNS64, or whose fault it is. He'll just want things to work. DS-Lite still allows this, and doesn't have any real impact on IPv4 exhaustion, since the end user will be issued RFC1918s, (likely) overlapped with other end users' RFC1918s. I also speculate that if one takes a large user community, say, customers of an ISP, and put them on NAT64/DNS64, we'll likely discover a lot more "IPv4 only" applications/services/appliances out there than we were expecting via the explosive ringing of flooded help desk lines. :p Granted, DS approaches will slow native IPv6 adoption a bit, but I think the real-world alternative is chaos. I personally prefer a scenario where users can go on using the internet as they've always done, likely oblivious to whether any particular site or application is using IPv6 or IPv4, while "behind the curtain" these same sites/applications are switching over to native IPv6, than a scenario where things simply stop working for them. Also, I hope that any pain associated with going through a CGN used in any of these sorts of approaches, and/or the benefits of native IPv6, will speed native IPv6 adoption more than any transition method might slow it. One can hope. :p From sparctacus at gmail.com Fri Mar 5 18:09:22 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Fri, 5 Mar 2010 16:09:22 -0800 Subject: Problem from Comcast Network to The Planet In-Reply-To: <9805C6F4-6E91-4F47-9458-2005774D7C87@gmail.com> References: <9805C6F4-6E91-4F47-9458-2005774D7C87@gmail.com> Message-ID: <53d706301003051609l1fc23f93scffd0d876d8ef932@mail.gmail.com> On Fri, Mar 5, 2010 at 1:33 PM, Zachary Frederick wrote: > We have been having a problem emailing to a customer whose server is hosted by The Planet (http://www.theplanet.com/). Our mail server is hosted in-house on a comcast business connection. > > IP address of our server is: 173.13.45.23 > > Customers mail server is: 69.93.203.243 > > I cannot telnet to port 25 on their server, and they cannot telnet to port 25 on ours. > > If I try to connect to their mail server from a different network such as my home internet connection, I can connect. > We do not do any firewalling that would block this in anyway. We were able to send and receive email to them when we used Qwest for our connection, before we switched to Comcast. > > Comcast has said the problem is not on their end because it times out at The Planet. > The Planet doesn't have much interest in speaking with me, because I'm not their customer. > > Not sure what to do at this point. Can you hit the submission port? (587) -Bryan From chort at smtps.net Fri Mar 5 18:23:49 2010 From: chort at smtps.net (Brian Keefer) Date: Fri, 5 Mar 2010 16:23:49 -0800 Subject: Problem from Comcast Network to The Planet In-Reply-To: <9805C6F4-6E91-4F47-9458-2005774D7C87@gmail.com> References: <9805C6F4-6E91-4F47-9458-2005774D7C87@gmail.com> Message-ID: <35BC9394-B559-4BAD-A456-B5B2B85F7ABD@smtps.net> On Mar 5, 2010, at 1:33 PM, Zachary Frederick wrote: > We have been having a problem emailing to a customer whose server is hosted by The Planet (http://www.theplanet.com/). Our mail server is hosted in-house on a comcast business connection. > > IP address of our server is: 173.13.45.23 > > Customers mail server is: 69.93.203.243 > I can get there from Comcast Business [chort at abydos ~]$ nc 69.93.203.243 25 220 ******************************************************************************************** ehlo smtps.net 250-securemail.insurancewebsitebuilder.com Hello smtps.net [173.11.102.7], pleased to meet you. 250-ENHANCEDSTATUSCODES 250-SIZE 250-XXXA 250-ETRN 250-XXXB 250-DSN 250-CHECKPOINT 250-8BITMIME 250-AUTH CRAM-MD5 PLAIN LOGIN DIGEST-MD5 250-XXXXXXXC 250 XXXD quit 221 2.0.0 securemail.insurancewebsitebuilder.com closing connection That's almost certainly a PIX/ASA with fixup enabled (like Jay said). It's been known to cause many interoperability problems. The solution is pretty simple: no fixup protocol smtp 25 -- bk From owen at delong.com Fri Mar 5 19:19:05 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Mar 2010 09:19:05 +0800 Subject: IP4 Space In-Reply-To: <03DBD526-6509-486B-ADB1-72C605D05637@virtualized.org> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> <59AEDC03-BCC7-4027-8818-CF6353455BE8@delong.com> <03DBD526-6509-486B-ADB1-72C605D05637@virtualized.org> Message-ID: On Mar 6, 2010, at 6:08 AM, David Conrad wrote: > On Mar 5, 2010, at 1:21 PM, Owen DeLong wrote: >>> The interesting question is at what point _can_ you do what you want without IPv4. It seems obvious that that point will be after the IPv4 free pool is exhausted, and as such, allocated-but-not-efficiently-used addresses will likely become worth the effort to reclaim. >>> >> Ah, but, that assumes that the need is located in a similar part of the network >> to the reclamation, or, that the point of reclamation can be sufficiently motivated >> to do so by the money offered by the point of need. > > Actually, no, not really. When you're dying of thirst, even muddy water can be mighty appealing. The fact that some prefixes you obtain may be filtered because they're too short merely means you have additional costs to reach the sites you care about. Don't know many ISPs that guarantee universal connectivity outside their own network today. Not sure why that would change in the future. > I think you mean long, not short. While there aren't many ISPs that guarantee that today (any?) it's still generally expected by customers and they are very unhappy when $SITE_THEY_CARE_ABOUT is unreachable. While the underlying guarantee likely won't change, I think it is even less likely that customer expectations will degrade even further. I could be wrong. However, my point was that if the organization with need is not the organization able to do the reclamation, or, at least a customer of the organization doing the reclamation, I expect the $$ they can offer to be a less than effective motivator for an external unrelated organization to give up their space. >> I suspect the organizations that have excess space and know where it is are >> likely to hold onto it as a hedge against their future needs, or, try to extract >> a very high market premium for it. > > Such folks will also have to take into consideration opportunity cost. Or they could make the strategic decision that all they really need is one or two ISP-provided public IPv4 addresses (in addition to IPv6) for their NATv4 box and public servers is all they really need and lease to their ISP the blocks they currently have in exchange for free connectivity or whatever. Etc. Myriad of possibilities. > Which comes back to my proximity argument -- If they leas to their provider, then, their provider can only offer those addresses to their immediate customers. What happens in such a lease when the lease expires and the original organization decides they want the addresses back? I'd hat to be the organization that received such addresses and suddenly faces a massive and urgent renumbering project. > The point is that when the IPv4 free pool is exhausted, there will be disruptive change. It isn't clear to me that pretty much any of the existing policies or practices regarding IPv4 addressing will continue to apply. I've been disappointed that some folks in the RIR communities have been unable to understand this. Gave up arguing as I figure time will tell one way or the other. > I understand it, but, I think that the most likely disruptive change will be that new users mostly end up behind IPv6 and some form of LSN solution. I'm hoping that it's mostly something like DS-Lite which gets the hell out of the way as soon as the content the customer wants is available on IPv6, but, I'm sure there will be providers that make uglier decisions for their customers. As such, I'm trying to do every thing I can to reach out to as many content and services providers as possible to encourage them to add IPv6 capabilities to their content and services. The more of these we can get dual-stack ready (even if they do something akin to Google, where it's ready and essentially available except for the DNS entries). The more content and services that are prepared in this manner, the less disruptive runout will be. Additionally, content and services are MUCH easier to roll out than enterprise networks. Almost as easy as end-user networks will be in about a year. (I think that you'll see relatively complete IPv6 solutions from most of the last-mile CPE and Head-End (DSLAM, DOCSIS, [BG]PON, etc.) vendors within the next 12 months. Some sooner than others. Owen > Regards, > -drc From Valdis.Kletnieks at vt.edu Fri Mar 5 19:35:27 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 05 Mar 2010 20:35:27 -0500 Subject: IP4 Space In-Reply-To: Your message of "Fri, 05 Mar 2010 17:08:50 EST." <03DBD526-6509-486B-ADB1-72C605D05637@virtualized.org> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> <59AEDC03-BCC7-4027-8818-CF6353455BE8@delong.com> <03DBD526-6509-486B-ADB1-72C605D05637@virtualized.org> Message-ID: <9526.1267839327@localhost> On Fri, 05 Mar 2010 17:08:50 EST, David Conrad said: > On Mar 5, 2010, at 1:21 PM, Owen DeLong wrote: > > Ah, but, that assumes that the need is located in a similar part of the network > > to the reclamation, or, that the point of reclamation can be sufficiently motivated > > to do so by the money offered by the point of need. > > Actually, no, not really. When you're dying of thirst, even muddy water > can be mighty appealing. Muddy water is a good way to catch anything from dysentery to Giardia to typhoid fever. You *really* want to avoid it if at all possible, or at least do your best to treat it. Anyhow, the problem is that the person dying of thirst will in most cases not be anywhere near where the muddy water is. Sure, my AS could do the renumbering and get back a /25 or /26 - but then what will we *do* with it? We're not about to go get just a /25 from an RIR, so it doesn't realistically slow down *OUR* requests, and we can't give it to anybody else easily. Our last big IP space grab was to deploy campus-wide wireless, which ended up needing a chunk of space. We ended up splitting the difference - wireless users get a globally routable dynamic-config IPv6 address, but a NAT-ed IPv4 address out of a /18 in 172.16. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tdurack at gmail.com Fri Mar 5 21:10:01 2010 From: tdurack at gmail.com (Tim Durack) Date: Fri, 5 Mar 2010 22:10:01 -0500 Subject: FreeAxez raised flooring? In-Reply-To: <20100305164559.6ea3455e.darcy@Vex.Net> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> <0DB35DA7-9BF8-40CC-A9E5-AB74D06CD5A9@delong.com> <20100305191539.GA48474@typo.org> <9e246b4d1003051311j180cf409ya0fea8ef9531660f@mail.gmail.com> <20100305164559.6ea3455e.darcy@Vex.Net> Message-ID: <9e246b4d1003051910i3b77e9efi74d9e014437a5dda@mail.gmail.com> >> We have/are building new datacenters with a raised floor plenum. Air >> is directed into the racks from below, and ducted out of the top. No >> hot/cold aisle, just lots of cold air to cool the equipment. It's an >> AFCO rack design. Seems to be efficient so far. > > How do you measure efficiency? ?How do you blow air on all the > computers in the rack and not just the bottom one? > > Hot/cold aisles are going to be way more efficient, or at least more > uniform. ?Your systems are probably like most rack mount gear and > designed to take air in the front, route it over the internals in an > ideal way (possibly using baffles) and spitting it out through the > back. ?Hot/cold aisles work with this system. ?Your way hits the bottom > box and then spits the air out of the rack missing the top systems. Same way you cool the top of a rack in a cold/hot aisle system. Blow cold air up the front of the rack. We measure temperature at select points in the rack. Keep the hottest spot below set point, and everything is fine. The physics aren't that much different. We are cooling 20kw per rack with this setup. 4 hp c-class chassis per rack. Works great. -- Tim:> From bill at herrin.us Fri Mar 5 21:21:30 2010 From: bill at herrin.us (William Herrin) Date: Fri, 5 Mar 2010 22:21:30 -0500 Subject: FreeAxez raised flooring? In-Reply-To: <9e246b4d1003051910i3b77e9efi74d9e014437a5dda@mail.gmail.com> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> <0DB35DA7-9BF8-40CC-A9E5-AB74D06CD5A9@delong.com> <20100305191539.GA48474@typo.org> <9e246b4d1003051311j180cf409ya0fea8ef9531660f@mail.gmail.com> <20100305164559.6ea3455e.darcy@Vex.Net> <9e246b4d1003051910i3b77e9efi74d9e014437a5dda@mail.gmail.com> Message-ID: <3c3e3fca1003051921p489d7de5hd3a2df3292fe8d10@mail.gmail.com> On Fri, Mar 5, 2010 at 10:10 PM, Tim Durack wrote: > Same way you cool the top of a rack in a cold/hot aisle system. Blow > cold air up the front of the rack. We measure temperature at select > points in the rack. Keep the hottest spot below set point, and > everything is fine. The physics aren't that much different. > > We are cooling 20kw per rack with this setup. 4 hp c-class chassis per > rack. Works great. Hi Tim, I poked through AFCO's drawings at http://www.afcosystems.com/pdf/AFCO_Drawings.pdf, How much of a size hit is typical? Do you take the depth out to 52" to create enough space in front of the equipment for air to flow and take the 6-inch hit to the side for the cabling sidecar? What's the impact with respect to sharing the facility with non-AFCO cabinets? I would imagine that with a bunch of these things dynamically changing their air flow it would be hard to maintain a static pressure under the floor. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From patrick at zill.net Fri Mar 5 23:30:22 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Sat, 06 Mar 2010 00:30:22 -0500 Subject: Locations with no good Internet (was ISP in Johannesburg) In-Reply-To: <1003040455.AA22820@ivan.Harhan.ORG> References: <1003040455.AA22820@ivan.Harhan.ORG> Message-ID: <4B91E86E.6020300@zill.net> Michael Sokolov wrote: > Another possible way to solve the middle mile issue would again be to > use the copper plant that's already in the ground. Unlike fiber, the > copper plant is *ubiquitous*: I don't know of any place in the 1st or > 2nd worlds that doesn't have copper pairs going to it. Also AFAIK T1s > are available everywhere too: if you order a T1, they'll deliver it to > you regardless of how deep you are in the middle of nowhere, although I > suppose there likely are extra surcharges involved. > Pardon me if attribution is screwed up ... > Granted, a T1 at 1.5 Mbps may not be much for backhaul, but what about > bonded T1s? Bond 4 of them to get 6 Mbps symmetric - not too bad in my > book for a rural community. > > And again using SDSL instead of T1 offers a cost reduction opportunity. > One could get that 6 Mbps symmetric for much cheaper by bonding 4 SDSL > circuits running at 1.5 Mbps each instead of T1s. There is a Covad > DSLAM with SDSL capability in virtually every CO in the country, but Isn't this really an issue (political) with tariffed T1 prices rather than a technical problem? I was told that most T1s are provisioned over a DSLAM these days anyways, and that the key difference between T1 and DSL was the SLA (99.99% guarantee vs. "when we get it fixed"). And T3/DS3 can run over what, 4 copper pairs? Yet how much is the typical tariffed rate for that? --Patrick From bmanning at vacation.karoshi.com Sat Mar 6 05:02:43 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 6 Mar 2010 11:02:43 +0000 Subject: IP4 Space - the lie In-Reply-To: <4BB3D876-628A-4052-BC91-7635045BC5B5@delong.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <4BB3D876-628A-4052-BC91-7635045BC5B5@delong.com> Message-ID: <20100306110243.GA28197@vacation.karoshi.com.> On Sat, Mar 06, 2010 at 02:23:59AM +0800, Owen DeLong wrote: > > > > IVI is stateless, which means it requires 1 to 1 IPv4 to IPv6 mapping. > > NAT64 allows multiplexing. > > > I didn't fully understand it, but, Ma Yan presented IVI with multiplexing > in a stateless environment at APNIC 29. > > Owen (who is very glad these are technologies OTHER people will use) > > > eat your own dog-food.. :) the house has been running IVI for several years now. everyone on hte house net is native v6 only. when there is a need, we pull a v4 address outo fhte DHCP pool and map it to the v6 address in question. when we're done, unlink the binding. from the "outside" - looks just like a nomral DHCP lease. --bill From Joel.Snyder at Opus1.COM Sat Mar 6 06:28:21 2010 From: Joel.Snyder at Opus1.COM (Joel Snyder) Date: Sat, 06 Mar 2010 05:28:21 -0700 Subject: Locations with no good Internet In-Reply-To: References: Message-ID: <4B924A65.2030100@opus1.com> Patrick Giagnocavo wrote: >Isn't this really an issue (political) with tariffed T1 prices rather >than a technical problem? >I was told that most T1s are provisioned over a DSLAM these days >anyways, and that the key difference between T1 and DSL was the SLA >(99.99% guarantee vs. "when we get it fixed"). I don't know about anything other than Qwest-land in Arizona, but we are seeing the few T1s that are still in service provisioned as you described: a 2-wire DSL connection, although not out of a local DSLAM. I think it depends on your definition of the box that's being used for connections as a DSLAM. It's certainly not the same traffic engineering as DSL, because DSL circuits are muxed at the DSLAM (at least in Qwest-land) and may or may not be subject to congestion when leaving the neighborhood remote terminal DSLAM. We for sure NEVER see any congestion on the T1s that are being provisioned using DSL technology. Now, whether that's the same chassis with engineering over an uplink, or two separate chassis in the same road-side wart for the two different services, that's a deployment issue. In other words, I think you're right about the technology involved (DSL-ish 2 wire circuits) being used to deliver, but there's more to it than repair time SLA when it comes to selling the same 2 wires as DSL for $39.95 and T1 for $399.95. (again, at least out here in the Wild West) That being said, I think your fundamental point is likely correct, something well known to everyone in this business: the cost to a Telco to provide T1 service is not 10x the cost to provide DSL service at similar speeds, and when there is that much additional marginal revenue being generated, they are going to fight with politics, tariffs, and any other tool at their disposal to keep the additional revenue coming in as long as possible. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From newton at internode.com.au Sat Mar 6 07:00:22 2010 From: newton at internode.com.au (Mark Newton) Date: Sat, 6 Mar 2010 23:30:22 +1030 Subject: IP4 Space In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> Message-ID: <6DB66FD4-3582-4656-AEA6-B15B19BA5220@internode.com.au> On 06/03/2010, at 1:06 AM, David Conrad wrote: > Mark, > > On Mar 4, 2010, at 11:46 PM, Mark Newton wrote: >> On 05/03/2010, at 2:50 PM, David Conrad wrote: >>> When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort. >> >> Only to the extent that the cost of IPv6 migration exceeds the cost >> of recovering space. > > You're remembering to include the cost of migrating both sides, for all combinations of sides interested in communicating, right? In some cases, that cost for one of those sides will be quite high. Yes, but I only need to pay the cost of my side. >> There's sure to be an upper-bound on the cost of v4 space, limited by the >> magnitude of effort required to do whatever you want to do without v4. > > The interesting question is at what point _can_ you do what you want without IPv4. It seems obvious that that point will be after the IPv4 free pool is exhausted, and as such, allocated-but-not-efficiently-used addresses will likely become worth the effort to reclaim. That isn't a likely outcome, though. We'll never need to do "without IPv4", it'll always be available, just in a SP-NATted form which doesn't work very well. Continuing to put up with that state of affairs comes with its own set of costs and obstacles which need to be weighed up against the cost of migrating to dual-stack (unicast global IPv6 + SPNAT IPv4) to extract yourself from the IPv4 tar-baby. Not migrating will be increasingly expensive over time, the costs of migrating will diminish, each individual operator will reach their own point when staying where they are is more expensive than getting with the program. And most of the participants on this mailing list will probably reach that point sooner than they think. My mom will probably never see a need to move beyond IPv4. But her next door neighbor with the bittorrent client and WoW habit probably will, and any content provider who's interested in having a relationship with their eyeballs which isn't intermediated by bollocky SPNAT boxes probably will too. Horses for courses. What I do know is that this "migrating to IPv6 is expensive so nobody wants to do it," is a canard that's been trotted out for most of the last decade as a justification for doing nothing. As an ISP that's running dual-stack right now, I can tell you from personal experience that the cost impact is grossly overstated, and under the circumstances is probably better off ignored. Just sayin'. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From newton at internode.com.au Sat Mar 6 07:06:24 2010 From: newton at internode.com.au (Mark Newton) Date: Sat, 6 Mar 2010 23:36:24 +1030 Subject: IP4 Space - the lie In-Reply-To: <20100305144019.GA4695@dan.olp.net> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> Message-ID: <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> On 06/03/2010, at 1:10 AM, Dan White wrote: > On 05/03/10 12:39 +0000, bmanning at vacation.karoshi.com wrote: >>> I *wholeheartedly* agree with Owen's assessment. Even spending time >>> trying to calculate a rebuttal to his numbers is better spent moving >>> toward dual-stack ;) >>> >>> Nice. >>> >>> Steve >> >> >> er... what part of dual-stack didn't you understand? >> dual-stack consumes exactly the same number of v4 and v6 addresses. > > I would expect the number of v6 addresses assigned to a host to be a > multiple of the number of v4 addresses, depending on the type of host. That's because you haven't done it yet. When you start doing it, you'll see that the number of v6 addresses assigned to a host will bear almost no relationship whatsoever to any metrics you've previously used to allocated IPv4 addresses. > Or, dual stack today. When you've run out of IPv4 addresses for new end > users, set them up an IPv6 HTTP proxy, SMTP relay and DNS resolver and/or > charge a premium for IPv4 addresses when you start to sweat. I expect that once we all work out that we can use SP-NAT to turn "dynamic IPv4 addresses" into "shared dynamic IPv4 addresses," we'll have enough spare IPv4 addresses for much of the foreseeable future. If I have half a million residential subscribers and I can get ten subscribers onto each NATted IPv4 addresses, then I only need 50,000 addresses to service them. Yet I have half a million addresses *right now*, which I won't be giving back to my RIR. So that turns into 450,000 saleable addresses for premium customers after the SP-NAT box is turned on, right? Problem solved :-) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From bill at herrin.us Sat Mar 6 08:37:35 2010 From: bill at herrin.us (William Herrin) Date: Sat, 6 Mar 2010 09:37:35 -0500 Subject: Locations with no good Internet In-Reply-To: <4B924A65.2030100@opus1.com> References: <4B924A65.2030100@opus1.com> Message-ID: <3c3e3fca1003060637s182e2ecdvc48f88d63b89f31b@mail.gmail.com> On Sat, Mar 6, 2010 at 7:28 AM, Joel Snyder wrote: > Patrick Giagnocavo wrote: > >>Isn't this really an issue (political) with tariffed T1 prices rather >>than a technical problem? > >>I was told that most T1s are provisioned over a DSLAM these days >>anyways, and that the key difference between T1 and DSL was the SLA >>(99.99% guarantee vs. "when we get it fixed"). > > I don't know about anything other than Qwest-land in Arizona, but we are > seeing the few T1s that are still in service provisioned as you described: a > 2-wire DSL connection, although not out of a local DSLAM. > > Now, whether that's the same chassis with engineering > over an uplink, or two separate chassis in the same > road-side wart for the two different services, > that's a deployment issue. For a T1 it's a "smart jack" on each end (and often repeaters in the middle) that have been engineered to run an HDSL signal between them and a classic T1 signal "outward" from each end. One independent set per T1; they aren't aggregated until after they're converted back to a classic T1 signal. http://en.wikipedia.org/wiki/Network_interface_device#Smartjack http://help.trixbox.com/Troubleshooting/What_is_a_Smart_Jack%3F The major difference between using HDSL smart jacks and classic smart jacks is that the HDSL ones don't need wire that's in quite as good shape and they don't need repeaters between you and the CO as often. They're still very much a T1 service. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dwhite at olp.net Sat Mar 6 10:14:37 2010 From: dwhite at olp.net (Dan White) Date: Sat, 6 Mar 2010 10:14:37 -0600 Subject: IP4 Space - the lie In-Reply-To: <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> Message-ID: <20100306161437.GA4736@dan.olp.net> On 06/03/10?23:36?+1030, Mark Newton wrote: > >On 06/03/2010, at 1:10 AM, Dan White wrote: > >> On 05/03/10 12:39 +0000, bmanning at vacation.karoshi.com wrote: >>>> I *wholeheartedly* agree with Owen's assessment. Even spending time >>>> trying to calculate a rebuttal to his numbers is better spent moving >>>> toward dual-stack ;) >>>> >>>> Nice. >>>> >>>> Steve >>> >>> >>> er... what part of dual-stack didn't you understand? >>> dual-stack consumes exactly the same number of v4 and v6 addresses. >> >> I would expect the number of v6 addresses assigned to a host to be a >> multiple of the number of v4 addresses, depending on the type of host. > >That's because you haven't done it yet. When you start doing it, >you'll see that the number of v6 addresses assigned to a host will >bear almost no relationship whatsoever to any metrics you've previously >used to allocated IPv4 addresses. I have. Windows XP, for instance, will auto assign multiple addresses during auto configuration, including random identifiers. If you through in multiple routers for redundancy, then you start to have a multiplying effect, compared to your typical one v4 address per end user host. Also, the number of publicly routeable v6 addresses assigned to hosts is surely much higher, on average, than the public v4 addresses assigned to those hosts. >> Or, dual stack today. When you've run out of IPv4 addresses for new end >> users, set them up an IPv6 HTTP proxy, SMTP relay and DNS resolver and/or >> charge a premium for IPv4 addresses when you start to sweat. > >I expect that once we all work out that we can use SP-NAT to turn "dynamic >IPv4 addresses" into "shared dynamic IPv4 addresses," we'll have enough >spare IPv4 addresses for much of the foreseeable future. > >If I have half a million residential subscribers and I can get ten >subscribers onto each NATted IPv4 addresses, then I only need 50,000 >addresses to service them. Yet I have half a million addresses >*right now*, which I won't be giving back to my RIR. So that turns >into 450,000 saleable addresses for premium customers after the >SP-NAT box is turned on, right? Possibly. I understand how to do HTTP proxies today, and understand its limitations. But it's a far more appealing technology than all these future technologies being proposed that fit in the 'once we all work out that we can use' category. -- Dan White From cb.list6 at gmail.com Sat Mar 6 12:07:35 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sat, 6 Mar 2010 10:07:35 -0800 Subject: IP4 Space - the lie In-Reply-To: <20100306161437.GA4736@dan.olp.net> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> <20100306161437.GA4736@dan.olp.net> Message-ID: On Sat, Mar 6, 2010 at 8:14 AM, Dan White wrote: > On 06/03/10?23:36?+1030, Mark Newton wrote: >> >> On 06/03/2010, at 1:10 AM, Dan White wrote: >> >>> On 05/03/10 12:39 +0000, bmanning at vacation.karoshi.com wrote: >>>>> >>>>> I *wholeheartedly* agree with Owen's assessment. Even spending time >>>>> trying to calculate a rebuttal to his numbers is better spent moving >>>>> toward dual-stack ;) >>>>> >>>>> Nice. >>>>> >>>>> Steve >>>> >>>> >>>> ? ? ? ?er... what part of dual-stack didn't you understand? >>>> ? ? ? ?dual-stack consumes exactly the same number of v4 and v6 >>>> addresses. >>> >>> I would expect the number of v6 addresses assigned to a host to be a >>> multiple of the number of v4 addresses, depending on the type of host. >> >> That's because you haven't done it yet. ?When you start doing it, >> you'll see that the number of v6 addresses assigned to a host will >> bear almost no relationship whatsoever to any metrics you've previously >> used to allocated IPv4 addresses. > > I have. Windows XP, for instance, will auto assign multiple addresses > during auto configuration, including random identifiers. > > If you through in multiple routers for redundancy, then you start to have a > multiplying effect, compared to your typical one v4 address per end user > host. > > Also, the number of publicly routeable v6 addresses assigned to hosts is > surely much higher, on average, than the public v4 addresses assigned > to those hosts. > >>> Or, dual stack today. When you've run out of IPv4 addresses for new end >>> users, set them up an IPv6 HTTP proxy, SMTP relay and DNS resolver and/or >>> charge a premium for IPv4 addresses when you start to sweat. >> >> I expect that once we all work out that we can use SP-NAT to turn "dynamic >> IPv4 addresses" into "shared dynamic IPv4 addresses," we'll have enough >> spare IPv4 addresses for much of the foreseeable future. >> >> If I have half a million residential subscribers and I can get ten >> subscribers onto each NATted IPv4 addresses, then I only need 50,000 >> addresses to service them. ?Yet I have half a million addresses >> *right now*, which I won't be giving back to my RIR. ?So that turns >> into 450,000 saleable addresses for premium customers after the >> SP-NAT box is turned on, right? > > Possibly. I understand how to do HTTP proxies today, and understand its > limitations. But it's a far more appealing technology than all these future > technologies being proposed that fit in the 'once we all work out that we > can use' category. > These IPv6-only systems are not far out, i am running a beta service using NAT64/DNS64 today. I believe a reasonable level off basic service can be provided today using IPv6-only + NAT64/DNS64. And, of course, native IPv6 content is a better QoE than the common NAT44 folks have today. I have demonstrations of windows 7 netbooks and Symbian Nokia smartphones doing common function with only IPv6 addresses on the end systems, no IPv4 except for the translation pool on the NAT64: www.youtube.com/theipv6guy Folks are risking their business and their customers if they don't have an IPv6 plan, and when i say IPv6 plan i mean IPv6-only. This list has already examined how polluted the remaining free IPv4 blocks are ... and as others have pointed out, CGN will be an expensive and poor QoE reality for those clinging to IPv4 > -- > Dan White > > From saku at ytti.fi Sat Mar 6 12:49:58 2010 From: saku at ytti.fi (Saku Ytti) Date: Sat, 6 Mar 2010 20:49:58 +0200 Subject: IP4 Space - the lie In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> <20100306161437.GA4736@dan.olp.net> Message-ID: <20100306184958.GA17785@mx.ytti.net> On (2010-03-06 10:07 -0800), Cameron Byrne wrote: > Folks are risking their business and their customers if they don't > have an IPv6 plan, and when i say IPv6 plan i mean IPv6-only. This > list has already examined how polluted the remaining free IPv4 blocks > are ... and as others have pointed out, CGN will be an expensive and > poor QoE reality for those clinging to IPv4 I'm personally afraid that EU+US companies may not see the risk. Majority of people in EU+US who want broadband and have purchase power for the services, should already have connectivity, as broadband penetration is somewhat complete. Companies offering products/services may view that implementing IPv6 will not bring them new business, but implementing it carries non-zero cost. And providing access to consumers who are not potential customers increases costs without increasing revenue. The major losers in EU+US market seem to be start-ups, who can't get addresses and thus have fraction of the market size giving existing companies unfair competitive advantage, nearly impossible to overcome. I would personally hope that EU+US would mandate that residential ISP add IPv6 to their subscribers by default, without possibility to opt-out in n years time. Hopefully n would be no more than 3. APAC and Africa surely are completely different matter. -- ++ytti From msokolov at ivan.Harhan.ORG Sat Mar 6 14:23:16 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Sat, 6 Mar 2010 20:23:16 GMT Subject: SDSL vs T1 (was Locations with no good Internet) Message-ID: <1003062023.AA29449@ivan.Harhan.ORG> Patrick Giagnocavo wrote: > Isn't this really an issue (political) with tariffed T1 prices rather > than a technical problem? Yes, of course. It's even worse if you are tied to one particular ISP (VZB) by non-portable IP addresses. I wanted service from AS701 with a V.35 hand-off; both requirements (the ISP choice and the hand-off type) were/are for sentimental reasons. Speed was/is a lower-priority concern, i.e., I was/am willing to live with sub-T1 speeds if it allows me to keep my 701-assigned IP addresses for a lower monthly extortion payment. My choices were: 1. Get a T1, enjoy the bandwidth (I live in an alternate Universe in which T1 bandwidth is almost infinity) and the SLA, and getting a V.35 hand-off would have been as easy as pulling an Adtran DSU out of my junk pile. But it was something like $650/month, probably before adding taxes and other extortions. 2. Opt for SDSL instead. I'm within a short walk of my CO, but I opt for only 384 kbps to reduce the monthly extortion payment. And since I still want V.35 hand-off, add the expense of designing and building my own CPE for it - but it's a one-time expense, and I have learned a *lot* in the process - as they say, happiness is a journey, not a destination. > I was told that most T1s are provisioned over a DSLAM these days > anyways, and that the key difference between T1 and DSL was the SLA > (99.99% guarantee vs. "when we get it fixed"). My situation is different because I am deliberately opting for a lower- speed service than what's available. At sub-T1 speeds SDSL has one advantage: the actual electrical signaling rate on the circuit is lowered to match the subscription data rate, unlike the fractional T1 kludge. But if you are specifically looking for a 1.5 Mbps service and are prepared to pay for 1.5 Mbps, the T1 vs. SDSL trade-off starts to look murkier: * With a T1 regardless of who serves it to you and how, you still get the classic HDLC encapsulation supported by every decent WAN router; with SDSL served out of a Covad DSLAM you get ATM cells on the line, wrapped in a wacky frame format: http://ifctfvax.Harhan.ORG/OpenWAN/2B1Q/flavors/nokia.html * Prior to my invention of the OSDCU gadget, it was not possible to connect a Covad SDSL line to a real router like Cisco (or Juniper or a BSD/Linux box or whatever), only to some very inferior router brands supplied as the "standard CPE". And as far as my gadget goes, I've built the hardware, but I haven't finished the firmware part yet, so it's still technically vaporware. * ATM is much less bit-efficient than HDLC, so a Covad SDSL circuit sold as "1.5 Mbps" actually has a little less real data carrying capacity than a T1. * I don't know off the top of my head what the monthly price is for Covad SDSL at 1.5 Mbps, and there probably is some variability between different ISPs who go through Covad, but I assume that even with a good deal it would still be a bit more than what I pay to VZB for 384 kbps. T1 prices have been coming down OTOH, at least for those who aren't tied to VZB. But I still expect T1 to be at least a little more expensive than SDSL @ 1.5 Mbps. I don't know how big this price delta is right now though - would anyone here have a better idea? The magnitude of this price delta ought to have a critical impact on whether or not it is worth putting up with all the quirks of SDSL listed above. For my peculiar situation (willing to live with 384 kbps and tied to VZB) the price delta (>3x increase in the monthly payment) is most definitely worth the one-time expense of finishing my OSDCU gadget, but I don't know how the cards would fall for someone who is looking for full 1.5 Mbps (or more with bonding) and who has a choice of ISPs. > And T3/DS3 can run over what, 4 copper pairs? Yet how much is the > typical tariffed rate for that? DS3 over 4 copper pairs? ~11 Mbps symmetric on each pair? That seems like squeezing a lot out of a copper pair to me. Over what distance? William Herrin wrote: > The major difference between using HDSL smart jacks and classic smart > jacks is that the HDSL ones don't need wire that's in quite as good > shape and they don't need repeaters between you and the CO as often. > They're still very much a T1 service. Yup. Even though at the transceiver chipset level HDSL and SDSL are very much alike, the powers that be configure them very very differently at the higher layers. HDSL units are configured to pass the entire T1 frame structure (SF/ESF) unaltered, and within that T1 frame structure you get the good old familiar HDLC. Covad SDSL uses the same 2B1Q line code as HDSL and even the same transceiver chip (Bt8970 or RS8973), but stuffs the bit stream with ATM cells in a wacky non-standard frame structure instead of HDLC or T1 frames. One can either pay a monthly premium for a more standards-based bit stream format, or pay less per month for the hoary non-standard Nokia flavor and make a one-time expense of building a converter gadget to transform it into HDLC (per FRF.8 or FUNI) as soon as it enters your premises. MS From shon at unwiredbb.com Sat Mar 6 15:32:39 2010 From: shon at unwiredbb.com (Shon Elliott) Date: Sat, 06 Mar 2010 13:32:39 -0800 Subject: IP4 Space In-Reply-To: <6DB66FD4-3582-4656-AEA6-B15B19BA5220@internode.com.au> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> <6DB66FD4-3582-4656-AEA6-B15B19BA5220@internode.com.au> Message-ID: <4B92C9F7.4080301@unwiredbb.com> My first reply to this thread. I've been kind of tracking it. I would love to move to IPv6. However, the IPv6 addressing, I have to say, is really tough to remember and understand for most people. Where is a four number dotted quad was easy to remember, an IPv6 address.. not so much. I wished they had made that a little easier when they were drafting up the protocol specs. basically, you need technical knowledge to even understand how the IP address is split up. I wished ARIN would waive the fee for service provider's first block of IPv6 as well. It would help make the dual stack deployment easier. I know IPv4 is running out. I understand the situation. I just wished they had put a little more thought into the user experience side of the addressing. You can all flog me now if you want. I expect it. I'm green on IPv6. I would love the education if I am wrong. -S Mark Newton wrote: > On 06/03/2010, at 1:06 AM, David Conrad wrote: > >> Mark, >> >> On Mar 4, 2010, at 11:46 PM, Mark Newton wrote: >>> On 05/03/2010, at 2:50 PM, David Conrad wrote: >>>> When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort. >>> Only to the extent that the cost of IPv6 migration exceeds the cost >>> of recovering space. >> You're remembering to include the cost of migrating both sides, for all combinations of sides interested in communicating, right? In some cases, that cost for one of those sides will be quite high. > > Yes, but I only need to pay the cost of my side. > >>> There's sure to be an upper-bound on the cost of v4 space, limited by the >>> magnitude of effort required to do whatever you want to do without v4. >> The interesting question is at what point _can_ you do what you want without IPv4. It seems obvious that that point will be after the IPv4 free pool is exhausted, and as such, allocated-but-not-efficiently-used addresses will likely become worth the effort to reclaim. > > That isn't a likely outcome, though. We'll never need to do "without IPv4", > it'll always be available, just in a SP-NATted form which doesn't work very > well. > > Continuing to put up with that state of affairs comes with its own set of > costs and obstacles which need to be weighed up against the cost of > migrating to dual-stack (unicast global IPv6 + SPNAT IPv4) to extract yourself > from the IPv4 tar-baby. Not migrating will be increasingly expensive > over time, the costs of migrating will diminish, each individual operator > will reach their own point when staying where they are is more expensive > than getting with the program. > > And most of the participants on this mailing list will probably reach > that point sooner than they think. > > My mom will probably never see a need to move beyond IPv4. But her next > door neighbor with the bittorrent client and WoW habit probably will, and > any content provider who's interested in having a relationship with their > eyeballs which isn't intermediated by bollocky SPNAT boxes probably will too. > > Horses for courses. > > What I do know is that this "migrating to IPv6 is expensive so nobody wants > to do it," is a canard that's been trotted out for most of the last decade > as a justification for doing nothing. > > As an ISP that's running dual-stack right now, I can tell you from personal > experience that the cost impact is grossly overstated, and under the > circumstances is probably better off ignored. > > Just sayin'. > > - mark > > -- > Mark Newton Email: newton at internode.com.au (W) > Network Engineer Email: newton at atdot.dotat.org (H) > Internode Pty Ltd Desk: +61-8-82282999 > "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 > > > > > > > From marka at isc.org Sat Mar 6 15:41:54 2010 From: marka at isc.org (Mark Andrews) Date: Sun, 07 Mar 2010 08:41:54 +1100 Subject: IP4 Space - the lie In-Reply-To: Your message of "Sat, 06 Mar 2010 20:49:58 +0200." <20100306184958.GA17785@mx.ytti.net> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> <20100306161437.GA4736@dan.olp.net> <20100306184958.GA17785@mx.ytti.net> Message-ID: <201003062141.o26LfsYK025182@drugs.dv.isc.org> In message <20100306184958.GA17785 at mx.ytti.net>, Saku Ytti writes: > On (2010-03-06 10:07 -0800), Cameron Byrne wrote: > > > Folks are risking their business and their customers if they don't > > have an IPv6 plan, and when i say IPv6 plan i mean IPv6-only. This > > list has already examined how polluted the remaining free IPv4 blocks > > are ... and as others have pointed out, CGN will be an expensive and > > poor QoE reality for those clinging to IPv4 > > I'm personally afraid that EU+US companies may not see the risk. Majority > of people in EU+US who want broadband and have purchase power for the > services, should already have connectivity, as broadband penetration is > somewhat complete. > > Companies offering products/services may view that implementing IPv6 will > not bring them new business, but implementing it carries non-zero cost. And > providing access to consumers who are not potential customers increases > costs without increasing revenue. Not implementing IPv6 will start to lose them business soon as they won't be able to reach IPv6 only sites. Not quite yet but soon. While all the services that there customers want to reach are available over IPv4 they will be fine. Once they are not they people will start to leave for a competitor that does offer IPv6 access. ISP's need to be asking themselves how much business are they willing to lose before they deploy IPv6. If they answer is "none" they should be moving now. > The major losers in EU+US market seem to be start-ups, who can't get > addresses and thus have fraction of the market size giving existing > companies unfair competitive advantage, nearly impossible to overcome. > > I would personally hope that EU+US would mandate that residential ISP add > IPv6 to their subscribers by default, without possibility to opt-out in > n years time. Hopefully n would be no more than 3. > > APAC and Africa surely are completely different matter. > -- > ++ytti -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sethm at rollernet.us Sat Mar 6 15:48:19 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 06 Mar 2010 13:48:19 -0800 Subject: IP4 Space In-Reply-To: <4B92C9F7.4080301@unwiredbb.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> <6DB66FD4-3582-4656-AEA6-B15B19BA5220@internode.com.au> <4B92C9F7.4080301@unwiredbb.com> Message-ID: <4B92CDA3.1050702@rollernet.us> On 3/6/10 1:32 PM, Shon Elliott wrote: > My first reply to this thread. I've been kind of tracking it. > > I would love to move to IPv6. However, the IPv6 addressing, I have to say, is > really tough to remember and understand for most people. Where is a four number > dotted quad was easy to remember, an IPv6 address.. not so much. I wished they > had made that a little easier when they were drafting up the protocol specs. > basically, you need technical knowledge to even understand how the IP address is > split up. I wished ARIN would waive the fee for service provider's first block > of IPv6 as well. It would help make the dual stack deployment easier. > There *is* a fee waiver in effect as introduced in 2008. However, if you've waited until now you only get 50% waived in 2010 and 25% waived in 2011. The waiver expires in 2012. Also, if your IPv4 fees are higher than the IPv6 fees would be, you only pay the higher one so the IPv6 block would be effectively free. ~Seth From routingbits at gmail.com Sat Mar 6 15:58:16 2010 From: routingbits at gmail.com (Routing Bits) Date: Sat, 6 Mar 2010 16:58:16 -0500 Subject: Comcast cust cannot reach Chris Boyd's IP x.x.x.x (was Problem from Comcast Network to The Planet) Message-ID: > > Message: 7 > Date: Fri, 5 Mar 2010 17:40:45 -0600 > From: Chris Boyd > Subject: Re: Problem from Comcast Network to The Planet > To: nanog at nanog.org > Message-ID: <5DF52A7E-7288-433B-8B08-EA9530B29400 at gizmopartners.com> > Content-Type: text/plain; charset=us-ascii > > > > I don't know what's going on in the Comcast network, but I've been having > similar fits with a single IP address in my network. Comcast can get to > nearby IP addresses in the same /24 no issue. The Comcast customer in my > case is in Florida, and I get to them via TWTelecom. > > I know it's not my net, and TWT was very helpful and knows it's not their > net. > > Attempts to get Comcast to look into it seem to end with them pinging their > customer's IP address from the Comcast support center and terminating the > call "since they can reach them." > --Chris Chris, Maybe Comcast abuse is blackholing the host? What is the host IP? Is it more than one Comcast customer unable to reach that host? What is the IP of the Comcast customer(s) unable to reach it? What do traces from the host to the customer and from customer to host look like? From r.engehausen at gmail.com Sat Mar 6 16:12:06 2010 From: r.engehausen at gmail.com (Roy) Date: Sat, 06 Mar 2010 14:12:06 -0800 Subject: SDSL vs T1 (was Locations with no good Internet) In-Reply-To: <1003062023.AA29449@ivan.Harhan.ORG> References: <1003062023.AA29449@ivan.Harhan.ORG> Message-ID: <4B92D336.4040008@gmail.com> On 3/6/2010 12:23 PM, Michael Sokolov wrote: > ... > I wanted service from AS701 with a V.35 hand-off; both requirements > (the ISP choice and the hand-off type) were/are for sentimental reasons. > Speed was/is a lower-priority concern, i.e., I was/am willing to live > with sub-T1 speeds if it allows me to keep my 701-assigned IP addresses > for a lower monthly extortion payment. > > ... > You missed an option. Just change to another ISP. I know of at least one AS701 address block still attached to a company that hasn't been their customer for ten years or so. ... From msokolov at ivan.Harhan.ORG Sat Mar 6 16:35:19 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Sat, 6 Mar 2010 22:35:19 GMT Subject: SDSL vs T1 (was Locations with no good Internet) Message-ID: <1003062235.AA29644@ivan.Harhan.ORG> Roy wrote: > You missed an option. Just change to another ISP. I know of at least > one AS701 address block still attached to a company that hasn't been > their customer for ten years or so. How is that possible? AFAIK no local politician has passed an IP address portability law yet. If my circuit from VZB were disconnected, wouldn't they release the address block for reuse by other customers just like any other ISP? I'm kinda guessing that you're suggesting that VZB's business practices are lax and that I may slip through the cracks? But there is no guarantee of any kind, is there? If they were to release/reuse my address block like they would have every right to, what recourse could I possibly have as a voluntarily disconnected customer? And even if the block remained unused / not reassigned after I left VZB, how could I possibly get it routed to me while connected through another ISP? I just don't get it - I don't see how this could be done without some local politician passing an IP address portability law like has been discussed recently. MS From marka at isc.org Sat Mar 6 16:46:28 2010 From: marka at isc.org (Mark Andrews) Date: Sun, 07 Mar 2010 09:46:28 +1100 Subject: IP4 Space In-Reply-To: Your message of "Sat, 06 Mar 2010 13:32:39 -0800." <4B92C9F7.4080301@unwiredbb.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> <6DB66FD4-3582-4656-AEA6-B15B19BA5220@internode.com.au> <4B92C9F7.4080301@unwiredbb.com> Message-ID: <201003062246.o26MkSoC025568@drugs.dv.isc.org> In message <4B92C9F7.4080301 at unwiredbb.com>, Shon Elliott writes: > My first reply to this thread. I've been kind of tracking it. > > I would love to move to IPv6. However, the IPv6 addressing, I have to say, is > really tough to remember and understand for most people. Where is a four numb > er > dotted quad was easy to remember, an IPv6 address.. not so much. I wished the > y > had made that a little easier when they were drafting up the protocol specs. Actually a lot of thought went into how to present 128 bit addresses and the current format is actually easier and more compact than the alternatives. > basically, you need technical knowledge to even understand how the IP address > is > split up. Actually IPv6 address are usually easier to split up than IPv4 addresses. You can take the presentation format of a IPv6 address and work out the host and network components without having to bit logic in your head. Take this real address 2001:470:1f00:820:214:22ff:fed9:fbdc. Its expanded form is 2001:0470:1f00:0820:0214:22ff:fed9:fbdc. The network component is 2001:470:1f00:820::/64. The host component it ::214:22ff:fed9:fbdc. If it was from a /56 the site would be 2001:470:1f00:800::/56 and it would be the 0x20 (32) subnet. If it was from a /48 the site would be 2001:470:1f00::/48 and it would be in the 0x820 (2080) subnet. IPv6 addresses are big enough that one can put the break points on nibble boundaries so that it is easy for the end user to work this all out. ISP's may get non-nibble break points but end users, unless the ISP is being stupid, will not see them. Compared with you have 192.223.8.96/27 IPv6 is easy. Bigger but easier which you will find once you actually work with IPv6 addresses. > I wished ARIN would waive the fee for service provider's first bloc > k > of IPv6 as well. It would help make the dual stack deployment easier. > > I know IPv4 is running out. I understand the situation. I just wished they ha > d > put a little more thought into the user experience side of the addressing. Yo > u > can all flog me now if you want. I expect it. I'm green on IPv6. I would love > the education if I am wrong. > > -S -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jrhett at netconsonance.com Sat Mar 6 23:01:19 2010 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat, 6 Mar 2010 21:01:19 -0800 Subject: Alcatel-Lucent In-Reply-To: References: Message-ID: On Mar 4, 2010, at 2:07 PM, Chris Wallace wrote: > I am hoping to get some peoples opinions on Alcatel-Lucent routers. We are looking at the 7750 SR line and the 7450 ESS line. We are currently a Cisco shop but these would be deployed in a completely new network delivering mostly MPLS based services and DIA. Any comments are welcome, good and bad. Unit functionality seems to be very good. My experience with their support groups has been less than good. Our sales rep and sales engineer are very helpful, as are the developers of the 7450 software I've been dealing with. But their support team loves, outright LOVES to say "no" and they do it an awful lot. "No" we don't support that, "no we never intend to support modern Solaris OS or patch levels", "no we won't support you in this config", etc. As it turns out the developers of the software already have fixes for all the reported problems, have every intention and working patches to support modern Solaris releases, etc. So my experience so far has been good product, good company, needs a real attitude adjustment in the support department. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owen at delong.com Sun Mar 7 00:07:47 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Mar 2010 14:07:47 +0800 Subject: IP4 Space - the lie In-Reply-To: <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> Message-ID: On Mar 6, 2010, at 9:06 PM, Mark Newton wrote: > > On 06/03/2010, at 1:10 AM, Dan White wrote: > >> On 05/03/10 12:39 +0000, bmanning at vacation.karoshi.com wrote: >>>> I *wholeheartedly* agree with Owen's assessment. Even spending time >>>> trying to calculate a rebuttal to his numbers is better spent moving >>>> toward dual-stack ;) >>>> >>>> Nice. >>>> >>>> Steve >>> >>> >>> er... what part of dual-stack didn't you understand? >>> dual-stack consumes exactly the same number of v4 and v6 addresses. >> >> I would expect the number of v6 addresses assigned to a host to be a >> multiple of the number of v4 addresses, depending on the type of host. > > That's because you haven't done it yet. When you start doing it, > you'll see that the number of v6 addresses assigned to a host will > bear almost no relationship whatsoever to any metrics you've previously > used to allocated IPv4 addresses. > With all due respect, your latter statement is true, but, your former is not. While there is no direct relationship, at least on my network, I can guarantee you that most of the hosts, especially all of the ones that received static addresses, did end up with more IPv6 addresses than they have IPv4 addresses. I don't know whether the person who stated the expectation has or has not added IPv6 capability to his network yet. I know I have, and, i know his statement essentially holds true in my case. >> Or, dual stack today. When you've run out of IPv4 addresses for new end >> users, set them up an IPv6 HTTP proxy, SMTP relay and DNS resolver and/or >> charge a premium for IPv4 addresses when you start to sweat. > > I expect that once we all work out that we can use SP-NAT to turn "dynamic > IPv4 addresses" into "shared dynamic IPv4 addresses," we'll have enough > spare IPv4 addresses for much of the foreseeable future. > Ewwwww... The more I hear people say this, the more I am _REALLY_ glad I am unlikely to have to live behind such an environment. I cannot imagine that this will provide anything remotely resembling a good user experience, or, even close to the current degraded user experience most people tolerate behind their current NAT devices. > If I have half a million residential subscribers and I can get ten > subscribers onto each NATted IPv4 addresses, then I only need 50,000 > addresses to service them. Yet I have half a million addresses > *right now*, which I won't be giving back to my RIR. So that turns > into 450,000 saleable addresses for premium customers after the > SP-NAT box is turned on, right? > Interesting way of thinking about it. I suspect that rather than pay your premium prices, the customers you just degraded in order to charge them more for the service they had will look to your competitors for better service. > Problem solved :-) > Indeed, once your customers move to a provider that will respect them, their problem is solved. Owen From owen at delong.com Sun Mar 7 00:21:26 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Mar 2010 14:21:26 +0800 Subject: IP4 Space - the lie In-Reply-To: <20100306184958.GA17785@mx.ytti.net> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> <20100306161437.GA4736@dan.olp.net> <20100306184958.GA17785@mx.ytti.net> Message-ID: <0F88136A-7B9D-479C-AA28-EFF6ACAB3247@delong.com> On Mar 7, 2010, at 2:49 AM, Saku Ytti wrote: > On (2010-03-06 10:07 -0800), Cameron Byrne wrote: > >> Folks are risking their business and their customers if they don't >> have an IPv6 plan, and when i say IPv6 plan i mean IPv6-only. This >> list has already examined how polluted the remaining free IPv4 blocks >> are ... and as others have pointed out, CGN will be an expensive and >> poor QoE reality for those clinging to IPv4 > > I'm personally afraid that EU+US companies may not see the risk. Majority > of people in EU+US who want broadband and have purchase power for the > services, should already have connectivity, as broadband penetration is > somewhat complete. > While it is more complete than many other countries, there are still rural areas where it is not, and, the relatively high churn rate in competitive markets will actually still lead to a need for increasing address allocations and assignments as customers move from ISPs that already have space for them to ISPs that need more space. If you look at the ARIN consumption statistics, or, the RIPE consumption statistics, there is certainly no indication that the demand for addresses has been significantly reduced in EU+US. > Companies offering products/services may view that implementing IPv6 will > not bring them new business, but implementing it carries non-zero cost. And > providing access to consumers who are not potential customers increases > costs without increasing revenue. > It may not bring you new business, but, it may be necessary to avoid losing the business you have. Most businesses that are built on an MRR model have to pay attention to that. Generally speaking, customer retention is regarded as important in most such organizations. > The major losers in EU+US market seem to be start-ups, who can't get > addresses and thus have fraction of the market size giving existing > companies unfair competitive advantage, nearly impossible to overcome. > I think at least the first several such startups will be able to get space out of the /10 reserved for transitional technologies to provide front-end proxies and such for their services. Startup eye-ball ISPs may be at a greater disadvantage for a relatively short period of time as they will essentially have to deploy an IPv6 customer network along side a technology such as NAT64 or DS-LITE. However, the more of these are created, the more pressure there is for content and service providers to provide native IPv6 availability of their content and services, so, I think it will rapidly solve itself on that level. > I would personally hope that EU+US would mandate that residential ISP add > IPv6 to their subscribers by default, without possibility to opt-out in > n years time. Hopefully n would be no more than 3. > I wouldn't hold my breath on that. It simply doesn't map to the regulatory framework and culture prevalent in the US at this time. Owen From owen at delong.com Sun Mar 7 00:39:01 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Mar 2010 14:39:01 +0800 Subject: IP4 Space In-Reply-To: <4B92C9F7.4080301@unwiredbb.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> <6DB66FD4-3582-4656-AEA6-B15B19BA5220@internode.com.au> <4B92C9F7.4080301@unwiredbb.com> Message-ID: <17F26B99-59A6-4B95-B0D6-2BFCD918E7AB@delong.com> On Mar 7, 2010, at 5:32 AM, Shon Elliott wrote: > My first reply to this thread. I've been kind of tracking it. > > I would love to move to IPv6. However, the IPv6 addressing, I have to say, is > really tough to remember and understand for most people. Where is a four number > dotted quad was easy to remember, an IPv6 address.. not so much. I wished they > had made that a little easier when they were drafting up the protocol specs. > basically, you need technical knowledge to even understand how the IP address is > split up. I wished ARIN would waive the fee for service provider's first block > of IPv6 as well. It would help make the dual stack deployment easier. > I'm not sure how you think they could have. 128 bits is a really big number no matter how you represent it. For the most part, attempting to remember IP addresses of either form is error-prone and ill-advised. It's actually much easier to understand how an IPv6 address should be split up than an IPv4 address. The rules are virtually identical to IPv4, and the recommendations are even easier to understand than the IPv4 rules. Rule: A netmask is expressed as a / followed by the number of contiguous bits at the MSB end of the number which comprise the network number. The remaining bits at the LSB end of the number comprise the host address. (Hint: This is the same rule as modern IPv4 and has largely the same mapping: For example, a /8 is 0xff000000 in IPv4 and 0xff00000000000000000000000000 in IPv6. (notice just more 0s to the right of the 0xff) ) Recommendations: End networks containing hosts should be /64. End-User organizations of very small size should receive a /56, or, on request, a /48. End-User organizations which are not very small should receive a /48, or, larger with appropriate justification. ISPs and LIRs should receive a /32, or, larger with appropriate justification. Because IPv6 addresses are always represented in hex, it is even easier to match up subnets to digits. Each hex digit is exactly 4 bits. (In IPv4, every 1, 2, or 3 digits, separated by a . was 8 bits and required a not insignificant amount of mental arithmetic to match an IP address and netmask to a prefix) IPv6 netmasks which do not line up with nibble boundaries still require some mental arithmetic, but, it is much much easier: Mask Value (MV) = /xx XX = Mask match portion of address. yy... = Remainder of 64 MSb of address. zz... = Host portion of /64 MV % 4 Mapping: 0 Full digit. /0 = default 1 First bit /1 = [0-7]yyy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz or [8-f]yyy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz 2 Two bits /2 = [0-3], [4-7], [8-b], or [c-f]... 3 Three bits /3 = [0-1], [2-3], [4-5], [6-7], [8-9], [a-b], [c-d], or [e-f]... 0 Full digit /4 = Xyyy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz 1 First bit /5 = X[0-7]yy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz or X[8-f]yy:yyyy:yyyy:yyyy:zzzz:zzzz:zzzz:zzzz 2 Two bits /6 = X[0-3]yy, X[4-7]yy, X[8-b]yy, or X[c-f]yy... etc. Personally, I recommend the KISS approach and keeping the boundaries aligned to the nibble wherever possible (/4, /8, /12, /16...) > I know IPv4 is running out. I understand the situation. I just wished they had > put a little more thought into the user experience side of the addressing. You > can all flog me now if you want. I expect it. I'm green on IPv6. I would love > the education if I am wrong. > I'm not trying to flog you. I'm trying to help you. If you have more questions, feel free to email me off-list. Owen > -S > > > Mark Newton wrote: >> On 06/03/2010, at 1:06 AM, David Conrad wrote: >> >>> Mark, >>> >>> On Mar 4, 2010, at 11:46 PM, Mark Newton wrote: >>>> On 05/03/2010, at 2:50 PM, David Conrad wrote: >>>>> When the IPv4 free pool is exhausted, I have a sneaking suspicion you'll quickly find that reclaiming pretty much any IPv4 space will quickly become worth the effort. >>>> Only to the extent that the cost of IPv6 migration exceeds the cost >>>> of recovering space. >>> You're remembering to include the cost of migrating both sides, for all combinations of sides interested in communicating, right? In some cases, that cost for one of those sides will be quite high. >> >> Yes, but I only need to pay the cost of my side. >> >>>> There's sure to be an upper-bound on the cost of v4 space, limited by the >>>> magnitude of effort required to do whatever you want to do without v4. >>> The interesting question is at what point _can_ you do what you want without IPv4. It seems obvious that that point will be after the IPv4 free pool is exhausted, and as such, allocated-but-not-efficiently-used addresses will likely become worth the effort to reclaim. >> >> That isn't a likely outcome, though. We'll never need to do "without IPv4", >> it'll always be available, just in a SP-NATted form which doesn't work very >> well. >> >> Continuing to put up with that state of affairs comes with its own set of >> costs and obstacles which need to be weighed up against the cost of >> migrating to dual-stack (unicast global IPv6 + SPNAT IPv4) to extract yourself >> from the IPv4 tar-baby. Not migrating will be increasingly expensive >> over time, the costs of migrating will diminish, each individual operator >> will reach their own point when staying where they are is more expensive >> than getting with the program. >> >> And most of the participants on this mailing list will probably reach >> that point sooner than they think. >> >> My mom will probably never see a need to move beyond IPv4. But her next >> door neighbor with the bittorrent client and WoW habit probably will, and >> any content provider who's interested in having a relationship with their >> eyeballs which isn't intermediated by bollocky SPNAT boxes probably will too. >> >> Horses for courses. >> >> What I do know is that this "migrating to IPv6 is expensive so nobody wants >> to do it," is a canard that's been trotted out for most of the last decade >> as a justification for doing nothing. >> >> As an ISP that's running dual-stack right now, I can tell you from personal >> experience that the cost impact is grossly overstated, and under the >> circumstances is probably better off ignored. >> >> Just sayin'. >> >> - mark >> >> -- >> Mark Newton Email: newton at internode.com.au (W) >> Network Engineer Email: newton at atdot.dotat.org (H) >> Internode Pty Ltd Desk: +61-8-82282999 >> "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 >> >> >> >> >> >> >> From surfer at mauigateway.com Sun Mar 7 01:52:34 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 6 Mar 2010 23:52:34 -0800 Subject: Alcatel-Lucent Message-ID: <20100306235234.2C032D6D@resin16.mta.everyone.net> --- jrhett at netconsonance.com wrote: So my experience so far has been good product, good company, needs a real attitude adjustment in the support department. ----------------------------------------- ditto that! scott From Valdis.Kletnieks at vt.edu Sun Mar 7 02:39:26 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 07 Mar 2010 03:39:26 -0500 Subject: IP4 Space - the lie In-Reply-To: Your message of "Sun, 07 Mar 2010 14:07:47 +0800." References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com> <20100305144019.GA4695@dan.olp.net> <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> Message-ID: <10621.1267951166@localhost> On Sun, 07 Mar 2010 14:07:47 +0800, Owen DeLong said: > Interesting way of thinking about it. I suspect that rather than pay your > premium prices, the customers you just degraded in order to charge > them more for the service they had will look to your competitors for > better service. I suspect that in many areas, the incumbent monopoly/duopoly has done a sufficiently good job of lowering customer expectations to do this. They've already been marketing what should be baseline service as "premium" for years already, and I'm not seeing much motivation for them to change. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From saku at ytti.fi Sun Mar 7 03:33:17 2010 From: saku at ytti.fi (Saku Ytti) Date: Sun, 7 Mar 2010 11:33:17 +0200 Subject: IP4 Space - the lie In-Reply-To: <201003062141.o26LfsYK025182@drugs.dv.isc.org> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> <20100306161437.GA4736@dan.olp.net> <20100306184958.GA17785@mx.ytti.net> <201003062141.o26LfsYK025182@drugs.dv.isc.org> Message-ID: <20100307093317.GA21026@mx.ytti.net> On (2010-03-07 08:41 +1100), Mark Andrews wrote: > Not implementing IPv6 will start to lose them business soon as they > won't be able to reach IPv6 only sites. Not quite yet but soon. While > all the services that there customers want to reach are available over > IPv4 they will be fine. Once they are not they people will start to > leave for a competitor that does offer IPv6 access. I'm not so optimistic users would migrate to new ISP because some sites do not work, sites which they have not accustomed to use and thus haven't learned to care about. Before this could happen, there would need to be many IPv6 only sites offering services and products successfully, these sites would need to survive competing against IPv4 sites, who will have vastly larger potential customer base. I fear companies offering products and services refuse to try to compete against IPv4 sites, so they'll do everything they can to acquire IPv4 address or give up the attempt to survive with IPv6 only. > ISP's need to be asking themselves how much business are they willing to > lose before they deploy IPv6. If they answer is "none" they should be > moving now. You are certainly right in APAC and Africa, I truly hope there would be business impact in EU+US too, I fear businesses might not experience it. -- ++ytti From saku at ytti.fi Sun Mar 7 03:47:56 2010 From: saku at ytti.fi (Saku Ytti) Date: Sun, 7 Mar 2010 11:47:56 +0200 Subject: IP4 Space - the lie In-Reply-To: <0F88136A-7B9D-479C-AA28-EFF6ACAB3247@delong.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> <20100306161437.GA4736@dan.olp.net> <20100306184958.GA17785@mx.ytti.net> <0F88136A-7B9D-479C-AA28-EFF6ACAB3247@delong.com> Message-ID: <20100307094756.GB21026@mx.ytti.net> On (2010-03-07 14:21 +0800), Owen DeLong wrote: > While it is more complete than many other countries, there are still rural > areas where it is not, and, the relatively high churn rate in competitive > markets will actually still lead to a need for increasing address allocations > and assignments as customers move from ISPs that already have space > for them to ISPs that need more space. My wording could have been better, by 'mostly complete' I was trying to be in mindset of company offering products and service over Internet. I think US is somewhere between 65-70& BB penetration? Companies might feel the part of the country not having BB accesss are not potential customers, perhaps due to lack of purchase power. Interestingly enough, here local incumbent ex-monopoly started removing DSLAM network from remote rural areas, quoting it being unprofitable. > If you look at the ARIN consumption statistics, or, the RIPE consumption > statistics, there is certainly no indication that the demand for addresses > has been significantly reduced in EU+US. But have these addresses been mostly delivered to new home users? Or have they been to new companies offering products and services? > It may not bring you new business, but, it may be necessary to avoid losing > the business you have. Most businesses that are built on an MRR model > have to pay attention to that. Generally speaking, customer retention is > regarded as important in most such organizations. I can't see end users currently having IPv4 connectivity changing to provider who can't provide access to IPv4 sites. Which I believe would translate that all existing users will continue to have access to the service. > I think at least the first several such startups will be able to get space out > of the /10 reserved for transitional technologies to provide front-end > proxies and such for their services. Startup eye-ball ISPs may be at > a greater disadvantage for a relatively short period of time as they will > essentially have to deploy an IPv6 customer network along side a > technology such as NAT64 or DS-LITE. However, the more of these > are created, the more pressure there is for content and service providers > to provide native IPv6 availability of their content and services, so, I think > it will rapidly solve itself on that level. I really hope you are correct. But I fear only way to fix the situation is to force IPv6 connectivity down the throat of every existing IPv4 end-user. Some companies sellings products and services might even find the new situation favourable, by not deploying IPv6, they make sure that users won't change to IPv6 only service as they need to reach the site, and thus they would be protecting themselves of new competition, who can only offer the service over IPv6. > > I would personally hope that EU+US would mandate that residential ISP add > > IPv6 to their subscribers by default, without possibility to opt-out in > > n years time. Hopefully n would be no more than 3. > > > I wouldn't hold my breath on that. It simply doesn't map to the regulatory > framework and culture prevalent in the US at this time. Quite right, but EU has history requiring rather more silly things, especially if it means getting free money with ridiculous monopoly claims. -- ++ytti From gbonser at seven.com Sun Mar 7 04:58:52 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 7 Mar 2010 02:58:52 -0800 Subject: SDSL vs T1 (was Locations with no good Internet) In-Reply-To: <1003062235.AA29644@ivan.Harhan.ORG> References: <1003062235.AA29644@ivan.Harhan.ORG> Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7C32@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG] > Sent: Saturday, March 06, 2010 2:35 PM > To: nanog at nanog.org > Subject: Re: SDSL vs T1 (was Locations with no good Internet) > > Roy wrote: > > > You missed an option. Just change to another ISP. I know of at > least > > one AS701 address block still attached to a company that hasn't been > > their customer for ten years or so. > > How is that possible? AFAIK no local politician has passed an IP > address portability law yet. If my circuit from VZB were disconnected, > wouldn't they release the address block for reuse by other customers > just like any other ISP? The government doesn't own IP addresses so there is no need to pass any such laws. I suppose it is completely legal to sever a transit agreement for traffic with a provider but maintain a business relationship where you pay them a fee for the use of the IP address space. There have been several instances in my career where I have used prefixes issued by a carrier that I never announced to them. I was using their IP space but the traffic to those addresses never went through their network. In some cases I have maintained a relationship with them such as having a thin pipe where I might pay some small monthly fee in order to retain the IP address space but simply paying someone to allow you to keep IP addresses isn't beyond the realm of possibility. From fw at deneb.enyo.de Sun Mar 7 08:45:37 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 07 Mar 2010 15:45:37 +0100 Subject: IP4 Space In-Reply-To: (Thomas Magill's message of "Thu, 4 Mar 2010 10:52:24 -0800") References: Message-ID: <87eijwxka6.fsf@mid.deneb.enyo.de> * Thomas Magill: > 1. Why don't providers use /31 addresses for P2P links? This > works fine per rfc 3021 but nobody seems to believe it or use it. Are > there any major manufacturers out there that do not support it? Not all vendors support it, especially not over Ethernet. > 2. Longer than /24 prefixes in global BGP table. The most obvious > answer is that some hardware may not handle it... I think the main problem today is update rate, not actual prefix count. In any case, it seems rather unlikely that less aggregation brings more IP addresses into play. Smaller RIR allocations, perhaps, but beyond the /24 barrier, you'll soon have better global connectivity over IPv6. From andy at nosignal.org Sun Mar 7 10:24:33 2010 From: andy at nosignal.org (Andy Davidson) Date: Sun, 07 Mar 2010 16:24:33 +0000 Subject: IP4 Space In-Reply-To: <4B92C9F7.4080301@unwiredbb.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> <6DB66FD4-3582-4656-AEA6-B15B19BA5220@internode.com.au> <4B92C9F7.4080301@unwiredbb.com> Message-ID: <4B93D341.3030707@nosignal.org> On 06/03/2010 21:32, Shon Elliott wrote: > I would love to move to IPv6. However, the IPv6 addressing, I have to say, is > really tough to remember and understand for most people. Roll out DNS before you roll out v6 then. > basically, you need technical knowledge to even understand how the IP address is > split up. By split up, do you mean subnetting ? You have to have technical knowledge to understand CIDR in v4, and once you do you will understand subnetting in v6 too. These excuses are really false and old. Forget the reasons why you can't roll v6. Do a little bit of work for your v6 roll out every day, and it will be done in a few months. Assuming you have made v6 support part of your purchasing policy by now. Andy From sven at cb3rob.net Sun Mar 7 10:50:47 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Sun, 7 Mar 2010 16:50:47 +0000 (UTC) Subject: Sponsoring request Piratenpartij Nederland Message-ID: Pardon the interruption regarding this somewhat unusual request, but please forward this to your sponsoring/donations/legal/lobbying department: ---------------------------------------------------------------------- Dear Internet Industry representatives: The Pirate Party Netherlands ( Piratenpartij Nederland), which is concerned with online and offline civil rights and a revision (reduction) of copyright law, is planning to take part in the upcoming parliamentary elections in the Netherlands. Although participation in the elections is open to all parties, it is not without costs. Therefore, the Pirate Party needs external funding from both individuals and organisations which share our vision. The costs which we incur are the following: - EUR 11250.- deposit to the election council (www.kiesraad.nl), to be recieved back if the party attains 75% of one parliamentary seat. - EUR 450.- registration fee for political parties at election council (www.kiesraad.nl) - EUR 500.- notary costs - EUR 150.- chamber of commerce registration (formal association with legal personality) - Online and offline advertising and campaign costs That is why we ask organisations and individuals for contributions to Pirate Party Netherlands. More information can be found at: http://staging.piratenpartij.nl/ Kind regards, representing Pirate Party Netherlands Rogier Huurman, Secretary Pirate Party Netherlands Sven Olaf Kamphuis, Member Piratenpartei Deutschland Member Piratenpartij Nederland Contact: Samir Allioui, Co-President at Pirate Parties International Chairman Piratenpartij Nederland +31627588738 samir.alioui at piratenpartij.nl ---------------------------------------------------------------------- Geachte vertegenwoordigers van de Internet Industrie, De Piratenpartij Nederland, die zich inzet voor online en offline burgerrechten alsmede een herziening (beperking) van de auteursrechten, is voornemens deel te nemen aan de komende verkiezingen voor de Tweede Kamer der Staten Generaal. Deelname aan de verkiezingen is dan wel vrij voor iedereen, maar het is zeker niet gratis. De Piratenpartij heeft daarom behoefte aan externe financiC+le injecties van zowel particulieren als organisaties die zich door onze standpunten aangesproken voelen. De kosten die wij moeten maken zijn als volgt: - 11250 euro borgstelling voor de kiesraad (www.kiesraad.nl), terug te ontvangen van de kiesraad door de partij bij het halen van 0.75e deel van 1 zetel - 450 euro eenmalige inschrijvingskosten kieslijst (www.kiesraad.nl) - 500 euro notariskosten - 150 euro kamer van koophandel (formele vereniging met rechtspersoon) - Online en offline advertentie- en campagnekosten Wij vragen daarom organisaties en particulieren om bijdragen ten bate van de Piratenpartij Nederland. Verdere informatie is beschikbaar op http://staging.piratenpartij.nl/ Met vriendelijke groet, namens Piratenpartij Nederland, Rogier Huurman, Secretary Pirate Party Netherlands Sven Olaf Kamphuis, Lid Piratenpartei Deutschland Lid Piratenpartei Nederland Contact: Samir Allioui, Co-President at Pirate Parties International Voorzitter Piratenpartij Nederland +31627588738 samir.alioui at piratenpartij.nl ---------------------------------------------------------------------- PiratenPartij Nederland Postbus 58006 NL-1040 HA Amsterdam The Netherlands From sven at cb3rob.net Sun Mar 7 10:50:47 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Sun, 7 Mar 2010 16:50:47 +0000 (UTC) Subject: [members-discuss] Sponsoring request Piratenpartij Nederland Message-ID: Pardon the interruption regarding this somewhat unusual request, but please forward this to your sponsoring/donations/legal/lobbying department: ---------------------------------------------------------------------- Dear Internet Industry representatives: The Pirate Party Netherlands ( Piratenpartij Nederland), which is concerned with online and offline civil rights and a revision (reduction) of copyright law, is planning to take part in the upcoming parliamentary elections in the Netherlands. Although participation in the elections is open to all parties, it is not without costs. Therefore, the Pirate Party needs external funding from both individuals and organisations which share our vision. The costs which we incur are the following: - EUR 11250.- deposit to the election council (www.kiesraad.nl), to be recieved back if the party attains 75% of one parliamentary seat. - EUR 450.- registration fee for political parties at election council (www.kiesraad.nl) - EUR 500.- notary costs - EUR 150.- chamber of commerce registration (formal association with legal personality) - Online and offline advertising and campaign costs That is why we ask organisations and individuals for contributions to Pirate Party Netherlands. More information can be found at: http://staging.piratenpartij.nl/ Kind regards, representing Pirate Party Netherlands Rogier Huurman, Secretary Pirate Party Netherlands Sven Olaf Kamphuis, Member Piratenpartei Deutschland Member Piratenpartij Nederland Contact: Samir Allioui, Co-President at Pirate Parties International Chairman Piratenpartij Nederland +31627588738 samir.alioui at piratenpartij.nl ---------------------------------------------------------------------- Geachte vertegenwoordigers van de Internet Industrie, De Piratenpartij Nederland, die zich inzet voor online en offline burgerrechten alsmede een herziening (beperking) van de auteursrechten, is voornemens deel te nemen aan de komende verkiezingen voor de Tweede Kamer der Staten Generaal. Deelname aan de verkiezingen is dan wel vrij voor iedereen, maar het is zeker niet gratis. De Piratenpartij heeft daarom behoefte aan externe financiC+le injecties van zowel particulieren als organisaties die zich door onze standpunten aangesproken voelen. De kosten die wij moeten maken zijn als volgt: - 11250 euro borgstelling voor de kiesraad (www.kiesraad.nl), terug te ontvangen van de kiesraad door de partij bij het halen van 0.75e deel van 1 zetel - 450 euro eenmalige inschrijvingskosten kieslijst (www.kiesraad.nl) - 500 euro notariskosten - 150 euro kamer van koophandel (formele vereniging met rechtspersoon) - Online en offline advertentie- en campagnekosten Wij vragen daarom organisaties en particulieren om bijdragen ten bate van de Piratenpartij Nederland. Verdere informatie is beschikbaar op http://staging.piratenpartij.nl/ Met vriendelijke groet, namens Piratenpartij Nederland, Rogier Huurman, Secretary Pirate Party Netherlands Sven Olaf Kamphuis, Lid Piratenpartei Deutschland Lid Piratenpartei Nederland Contact: Samir Allioui, Co-President at Pirate Parties International Voorzitter Piratenpartij Nederland +31627588738 samir.alioui at piratenpartij.nl ---------------------------------------------------------------------- PiratenPartij Nederland Postbus 58006 NL-1040 HA Amsterdam The Netherlands ---- If you don't want to receive mails from the RIPE NCC Members Discuss list, please log in to your LIR Portal account at: http://lirportal.ripe.net/ First click on General and then click on Edit. At the bottom of the Page you can add or remove addresses. From owen at delong.com Sun Mar 7 14:02:58 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Mar 2010 12:02:58 -0800 Subject: IP4 Space - the lie In-Reply-To: <20100307094756.GB21026@mx.ytti.net> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> <20100306161437.GA4736@dan.olp.net> <20100306184958.GA17785@mx.ytti.net> <0F88136A-7B9D-479C-AA28-EFF6ACAB3247@delong.com> <20100307094756.GB21026@mx.ytti.net> Message-ID: On Mar 7, 2010, at 1:47 AM, Saku Ytti wrote: > On (2010-03-07 14:21 +0800), Owen DeLong wrote: > >> While it is more complete than many other countries, there are still rural >> areas where it is not, and, the relatively high churn rate in competitive >> markets will actually still lead to a need for increasing address allocations >> and assignments as customers move from ISPs that already have space >> for them to ISPs that need more space. > > My wording could have been better, by 'mostly complete' I was trying to be > in mindset of company offering products and service over Internet. I think > US is somewhere between 65-70& BB penetration? Companies might feel the > part of the country not having BB accesss are not potential customers, > perhaps due to lack of purchase power. Us is somewhere close to 90% BB penetration in urban areas and closer to 30% in rural areas. Overall, that makes 65-70%. My point was that the raw 65-70% number is misleading because of the strong dichotomy between urban and rural instances in the US. While you may be right that some larger national companies may not feel the impact, do not underestimate the number of companies that depend on providing and delivering local content to these rural markets as well. Given the number of initiatives to expand rural broadband within the US, such as BTOP, I think there is potential here. > Interestingly enough, here local incumbent ex-monopoly started removing > DSLAM network from remote rural areas, quoting it being unprofitable. > That would probably not happen here unless it was replaced by an alternative technology for the same market, lest it attract the attention of regulators. Additionally, one of the largest broadband providers in the US is Comcast. I suspect that of the US markets which are monopoly or duopoly Comcast is probably present in a majority of those markets. They have expressed a definite strategy for moving to IPv6 and enabling their residential customers to have IPv6 services. I think this fact will make it difficult for their competition to offer less and get away with it. >> If you look at the ARIN consumption statistics, or, the RIPE consumption >> statistics, there is certainly no indication that the demand for addresses >> has been significantly reduced in EU+US. > > But have these addresses been mostly delivered to new home users? Or have > they been to new companies offering products and services? > The largest address consumers even today as I understand it are the residential "eye-ball" ISPs. However, even if it is new companies offering products and services, then, it will not take long after IPv4 runout for there to be a critical mass of IPv6-only companies in this area of the net. Either way, I think that IPv4 runout, in addition to creating a temporary train-wreck of end-user experiences for IPv4 content, will accelerate deployment of IPv6 on both sides of the equation and that any acceleration on one side will drive further acceleration on the other. >> It may not bring you new business, but, it may be necessary to avoid losing >> the business you have. Most businesses that are built on an MRR model >> have to pay attention to that. Generally speaking, customer retention is >> regarded as important in most such organizations. > > I can't see end users currently having IPv4 connectivity changing to > provider who can't provide access to IPv4 sites. Which I believe would > translate that all existing users will continue to have access to the > service. > No, but, if their choice is between a current provider which offers extremely degraded IPv4 services without IPv6 and a provider which offers IPv6 services and a similarly degraded service which only affects IPv4-only content, I can see them switching rapidly towards the latter. >> I think at least the first several such startups will be able to get space out >> of the /10 reserved for transitional technologies to provide front-end >> proxies and such for their services. Startup eye-ball ISPs may be at >> a greater disadvantage for a relatively short period of time as they will >> essentially have to deploy an IPv6 customer network along side a >> technology such as NAT64 or DS-LITE. However, the more of these >> are created, the more pressure there is for content and service providers >> to provide native IPv6 availability of their content and services, so, I think >> it will rapidly solve itself on that level. > > I really hope you are correct. But I fear only way to fix the situation is > to force IPv6 connectivity down the throat of every existing IPv4 end-user. I hope not, because that simply won't happen. > Some companies sellings products and services might even find the new > situation favourable, by not deploying IPv6, they make sure that users > won't change to IPv6 only service as they need to reach the site, and thus > they would be protecting themselves of new competition, who can only offer > the service over IPv6. > I don't think i will work out that way. I think that new companies that need to offer new sites will use proxy servers and obtain VIP addresses out of the /10 reserved for transitional technologies. Thus, new services will be able to easily come up dual-stack with almost no disadvantage vs. their IPv4-only competition. Since their IPv4-only competition will then be providing an increasingly degraded user-experience to their end users, where as dual-stack end-users will get a full native user experience with the newer competitor on dual-stack, I think that the newer competitor will actually have the advantage here. >>> I would personally hope that EU+US would mandate that residential ISP add >>> IPv6 to their subscribers by default, without possibility to opt-out in >>> n years time. Hopefully n would be no more than 3. >>> >> I wouldn't hold my breath on that. It simply doesn't map to the regulatory >> framework and culture prevalent in the US at this time. > > Quite right, but EU has history requiring rather more silly things, > especially if it means getting free money with ridiculous monopoly claims. > I'm not sufficiently familiar with the EU regulatory climate to comment knowledgeably. I can say that I would not expect that to work in the US which is where I live. I'll even go out on a limb and say it is unlikely in Canada. Owen From newton at internode.com.au Mon Mar 8 00:40:07 2010 From: newton at internode.com.au (Mark Newton) Date: Mon, 8 Mar 2010 17:10:07 +1030 Subject: IP4 Space - the lie In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B907507.800@ibctech.ca> <20100305123919.GA20227@vacation.karoshi.com.> <20100305144019.GA4695@dan.olp.net> <1D926C85-D1D1-46EB-98FA-FEBEC782CE5D@internode.com.au> Message-ID: <4F967295-ACE9-4365-AAEA-FFDCD1868776@internode.com.au> On 07/03/2010, at 4:37 PM, Owen DeLong wrote: >> I expect that once we all work out that we can use SP-NAT to turn "dynamic >> IPv4 addresses" into "shared dynamic IPv4 addresses," we'll have enough >> spare IPv4 addresses for much of the foreseeable future. >> > Ewwwww... The more I hear people say this, the more I am _REALLY_ glad > I am unlikely to have to live behind such an environment. I cannot imagine > that this will provide anything remotely resembling a good user experience, To whom? My mom doesn't care, and isn't likely to ever notice. Gamers might care, but their gaming platforms are likely to be among the first to transition when the rubber meets the road, so they won't be significantly affected. P2P users already don't care because their apps use v6 already. You and I won't care, because we'll have v6 access to everything we need too. Content owners will care a fair bit at the beginning but less as time goes on, and more of their eyeballs become v6-enabled. There'll be bits of the internet that transition very, very quickly to dual-stack or straight-out IPv6, and there'll be other bits which won't. The impact of what I've suggested will be quarantined to that latter category. And frankly I can't see why anyone should be expected to invest engineering time and cost into solving a problem that only exists because the people who are causing it (by not transitioning to v6) expect everyone else to clean up their mess (by providing painless transition tools). To put it another way: The very last IPv4-only Internet user won't have any serious expectation that the rest of the world owes him/her an easy ride. So why should the last five of them, or the last 1000 of them, or even the last billion of them? There'll be a sliding scale of care-factor, and my guess is that it won't take very long to get to the bottom of it, and that the significant bulk of the transition will happen faster than anyone expects. > or, even close to the current degraded user experience most people tolerate > behind their current NAT devices. Sucks to be them. They'd better upgrade then, hadn't they? >> If I have half a million residential subscribers and I can get ten >> subscribers onto each NATted IPv4 addresses, then I only need 50,000 >> addresses to service them. Yet I have half a million addresses >> *right now*, which I won't be giving back to my RIR. So that turns >> into 450,000 saleable addresses for premium customers after the >> SP-NAT box is turned on, right? >> > Interesting way of thinking about it. I suspect that rather than pay your > premium prices, the customers you just degraded in order to charge > them more for the service they had will look to your competitors for > better service. My competitors will have the same problem with the same array of available solutions with the same mixtures of cost, benefit and care-factor. Odds are that they'll probably make many of the same decisions. Sorry, perhaps I'm missing something here, but is there a general expectation that the v4-v6 transition is going to be an easy ride for everyone? - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From piotr.sawicki.pl at gmail.com Mon Mar 8 07:31:00 2010 From: piotr.sawicki.pl at gmail.com (piotr sawicki) Date: Mon, 08 Mar 2010 14:31:00 +0100 Subject: Alcatel-Lucent In-Reply-To: References: Message-ID: <4B94FC14.4040106@gmail.com> Chris Wallace wrote: > I am hoping to get some peoples opinions on Alcatel-Lucent routers. We are looking at the 7750 SR line and the 7450 ESS line. We are currently a Cisco shop but these would be deployed in a completely new network delivering mostly MPLS based services and DIA. Any comments are welcome, good and bad. > > ---Chris > Hello !! First time on the list :) I'd like to say something in opposite . These are very weak routers .. We ( SP on country level , PL ) had two of them , implemented in core , as pure ip routers . The worst thing in it was bgp proto .. Router was unable to withstand 20+ peering sessions , most of that outgoing bgp session to customers , a few peerings , and only 1v2 incoming upstream providers When there was instability/surge in bgp updates , router was able to break itself tcp sess. Dwnld bgp table (150,000prefix) took 2h or more ... Things done in hardware should be working although ( bridge .. , maybe label switching , vpls ) Tech support is very weak. Expect problems with interoperability . Sorry to say that . It was 3+ years time ago , maybe they improved themself .. :) If you want 2 spare chassis , we have them free // best regards Piotr Sawicki . From hadas at tehila.gov.il Mon Mar 8 08:21:38 2010 From: hadas at tehila.gov.il (Hadas Shany) Date: Mon, 8 Mar 2010 16:21:38 +0200 Subject: Trojan traffic from 115.100.250.112 Message-ID: Hello NANOG, Yesterday we've found some strange requests in our logs, typical to the Daonol Trojan. According to the logs, the infected computers are sending personal information such as search engine lookups and browsing history. The information sent to 115.100.250.112. Log entry for example: GET http://115.100.250.112/x/?0ECiqocksamkpjqtnwhgrtieydpwgvnmktk2 HTTP/1.0..SS: More information on Daonol Trojan: http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Win32%2fDaonol We've blocked all communication with this address. Thank you, Hadas Shany CERT.GOV ISRAEL From cmaurand at xyonet.com Mon Mar 8 09:16:53 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Mon, 08 Mar 2010 10:16:53 -0500 Subject: Locations with no good Internet In-Reply-To: <4B924A65.2030100@opus1.com> References: <4B924A65.2030100@opus1.com> Message-ID: <4B9514E5.2040203@xyonet.com> On 3/6/2010 7:28 AM, Joel Snyder wrote: > Patrick Giagnocavo wrote: > > >Isn't this really an issue (political) with tariffed T1 prices rather > >than a technical problem? > > >I was told that most T1s are provisioned over a DSLAM these days > >anyways, and that the key difference between T1 and DSL was the SLA > >(99.99% guarantee vs. "when we get it fixed"). > > I don't know about anything other than Qwest-land in Arizona, but we > are seeing the few T1s that are still in service provisioned as you > described: a 2-wire DSL connection, although not out of a local DSLAM. > Here in Maine, they use HDSL (two pair) to supply T1. They put repeaters down the line or work it out of a SLICK. The bridge taps and side taps are removed from the loops (conditioned) and then there's the SLA. I learned to always have a spare CSU/DSU on site. --Curtis From robert at timetraveller.org Mon Mar 8 10:52:27 2010 From: robert at timetraveller.org (Robert Brockway) Date: Mon, 8 Mar 2010 11:52:27 -0500 (EST) Subject: IP4 Space In-Reply-To: <4B92C9F7.4080301@unwiredbb.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> <6DB66FD4-3582-4656-AEA6-B15B19BA5220@internode.com.au> <4B92C9F7.4080301@unwiredbb.com> Message-ID: On Sat, 6 Mar 2010, Shon Elliott wrote: > I would love to move to IPv6. However, the IPv6 addressing, I have to > say, is really tough to remember and understand for most people. Where Hi Shon. But we have a system in place which allows non-technical people to ignore IP addresses entirely. Up to this point the ease of remembering IPv4 addresses has allowed their use to leak out in to the user community. It is quite common today for users to ssh to servers by IP address in many organisations. I consider this an historical accident. When setting up or upgrading corporate networks (even for small companies) I use split-view DNS. I like to point out that once IPv6 is mainstream no one is going to remember IP addresses ever again :) > is a four number dotted quad was easy to remember, an IPv6 address.. not > so much. I wished they had made that a little easier when they were > drafting up the protocol specs. I don't believe making it easier for humans to remember or understand IP addresses would have been a good design criteria. IP addresses are principally designed for computers to understand. We humans have a parrallel structure of names that we can use. In any case humans got a break with the :: notation in IPv6 :) > basically, you need technical knowledge to even understand how the IP > address is split up. I wished ARIN would waive the fee for service That's actually still true in IPv4. A knowledgeable user may be able to ping an IP address but few of them will understand the concept of a subnet. Cheers, Rob -- Email: robert at timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com I tried to change the world but they had a no-return policy From tony at hoyle.me.uk Mon Mar 8 11:06:20 2010 From: tony at hoyle.me.uk (Tony Hoyle) Date: Mon, 08 Mar 2010 17:06:20 +0000 Subject: IP4 Space In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <9ED58CAF-3851-449E-A352-EE082678CDA4@virtualized.org> <6DB66FD4-3582-4656-AEA6-B15B19BA5220@internode.com.au> <4B92C9F7.4080301@unwiredbb.com> Message-ID: <4B952E8C.9060309@hoyle.me.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2010 16:52, Robert Brockway wrote: > On Sat, 6 Mar 2010, Shon Elliott wrote: > >> I would love to move to IPv6. However, the IPv6 addressing, I have to >> say, is really tough to remember and understand for most people. Where > > Hi Shon. But we have a system in place which allows non-technical > people to ignore IP addresses entirely. > > Up to this point the ease of remembering IPv4 addresses has allowed > their use to leak out in to the user community. It is quite common > today for users to ssh to servers by IP address in many organisations. > I consider this an historical accident. > It's also not that difficult to remember.. your prefix never changes so that's the first 48-64 bits taken care of. The rest you can make human readable if you want - I know people that use ::53 for their nameserver, ::80 for their webserver, etc. It's all about how you use it. Personally I use DNS.. that's what it's for. Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLlS6MAAoJEJ1qCQ6ePCDUj+AH/3Kr/FBliJQeCIGSlIEOHm3K TmeGWsfD+cZR/clTN3MNAFtwH63Iowo014zU9kL2AJAkZEVs6LCx0uJ3ewDT+tfb +KGcB4KUjJkaEXxdcjIRIcJrVcW2QnMyFT/J5B+CWM7MhgPzsGL9VLmvKY2LaqBQ coGlfqsg89HTmzlK1McQy+UfhvkJx8bVKgYqHxmHQvIN3GPaWWDjjt50l6oskBy7 F8htD0+O5eM8B7/ozsxeaH7N3gTrZIlEG5MzCvXCxWXyR4wbVssUt9SEF3Gdd9sg aEC6sjUSxL9t7G9a8FyRvwufpQALxJ7mNgozxJPJF8HuHbPnGFL7ZpoH1fph0PI= =AnwO -----END PGP SIGNATURE----- From toivo at usf.edu Mon Mar 8 12:56:59 2010 From: toivo at usf.edu (Voll, Toivo) Date: Mon, 8 Mar 2010 13:56:59 -0500 Subject: Best VPN Appliance In-Reply-To: References: Message-ID: We're generally happy with our Juniper SA6500s, but they, and a lot of the other SSL VPN vendor appliances will not support IPSec. Cisco's ASA does, but it's less feature-rich in the SSL VPN arena. The Juniper was the most mature and flexible of all the offerings we looked at, but also the most expensive, and it's not perfect either. Having migrated from Cisco's 3000 series appliances, the current SSL VPNs are a totally different mindset and about two orders of magnitude more complicated. Have a very good understanding of exactly what problem you're trying to solve with the product and what kind of policies and requirements you have to meet, or it's going to be a mess. I can answer more specific questions on our experiences and testing off-list. -- Toivo Voll University of South Florida Information Technology Communications -----Original Message----- From: Chris Campbell [mailto:Chris.Campbell at nebulassolutions.com] Sent: Friday, March 05, 2010 11:36 AM To: Dawood Iqbal Cc: nanog at nanog.org Subject: Re: Best VPN Appliance The Juniper SA is by far and away the market leader and in my opinion the best end user experience. On 5 Mar 2010, at 15:57, Dawood Iqbal wrote: > Hello All, > > > > Is it possible to get your ideas on what VPN appliances are good to have in > enterprise network? > > > > Requirements are; > > SSL > > IPSec > > Client and Web VPN support (Win/MAC/iPhone/Android) > > If webvpn is used, then when any user connects via webvpn, we should be able > to re-direct him to any and ONLY specific application i.e SAP. > > If 2 boxes are installed then they should replicate data seamlessly. > > > > > > Regards, > > dI > From sfouant at shortestpathfirst.net Mon Mar 8 13:28:48 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 8 Mar 2010 19:28:48 +0000 Subject: Best VPN Appliance Message-ID: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> Toivo, The SA Series absolutely supports IPsec if you are using Network Connect. It defaults to using IPsec and if that is not supported then it will fall back to SSL. Of course, NC is not as secure as W-SAM, J-SAM, or Core Access in terms of role and resource granularity control but the support for IPsec is absolutely there. HTHs. Stefan Fouant ------Original Message------ From: Voll, Toivo To: Chris Campbell To: Dawood Iqbal Cc: nanog at nanog.org Subject: RE: Best VPN Appliance Sent: Mar 8, 2010 11:56 AM We're generally happy with our Juniper SA6500s, but they, and a lot of the other SSL VPN vendor appliances will not support IPSec. Cisco's ASA does, but it's less feature-rich in the SSL VPN arena. The Juniper was the most mature and flexible of all the offerings we looked at, but also the most expensive, and it's not perfect either. Having migrated from Cisco's 3000 series appliances, the current SSL VPNs are a totally different mindset and about two orders of magnitude more complicated. Have a very good understanding of exactly what problem you're trying to solve with the product and what kind of policies and requirements you have to meet, or it's going to be a mess. I can answer more specific questions on our experiences and testing off-list. -- Toivo Voll University of South Florida Information Technology Communications -----Original Message----- From: Chris Campbell [mailto:Chris.Campbell at nebulassolutions.com] Sent: Friday, March 05, 2010 11:36 AM To: Dawood Iqbal Cc: nanog at nanog.org Subject: Re: Best VPN Appliance The Juniper SA is by far and away the market leader and in my opinion the best end user experience. On 5 Mar 2010, at 15:57, Dawood Iqbal wrote: > Hello All, > > > > Is it possible to get your ideas on what VPN appliances are good to have in > enterprise network? > > > > Requirements are; > > SSL > > IPSec > > Client and Web VPN support (Win/MAC/iPhone/Android) > > If webvpn is used, then when any user connects via webvpn, we should be able > to re-direct him to any and ONLY specific application i.e SAP. > > If 2 boxes are installed then they should replicate data seamlessly. > > > > > > Regards, > > dI > Sent from my Verizon Wireless BlackBerry From Orin.Blomberg at DOH.WA.GOV Mon Mar 8 13:37:02 2010 From: Orin.Blomberg at DOH.WA.GOV (Blomberg, Orin P (DOH)) Date: Mon, 8 Mar 2010 11:37:02 -0800 Subject: Best VPN Appliance In-Reply-To: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> Message-ID: There is also the fact to consider that Cisco has said there will be no support for Windows 64-bit on their IPSEC client, they are pushing people to the AnyConnect (An SSL-based clientless IPSEC) who want to use Windows 64-bit or other OSs, so in the future the argument for having a separate box for client-based IPSEC will be moot. Orin -----Original Message----- From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] Sent: Monday, March 08, 2010 11:29 AM To: Voll, Toivo; Chris Campbell; Dawood Iqbal Cc: nanog at nanog.org Subject: Re: Best VPN Appliance Toivo, The SA Series absolutely supports IPsec if you are using Network Connect. It defaults to using IPsec and if that is not supported then it will fall back to SSL. Of course, NC is not as secure as W-SAM, J-SAM, or Core Access in terms of role and resource granularity control but the support for IPsec is absolutely there. HTHs. Stefan Fouant ------Original Message------ From: Voll, Toivo To: Chris Campbell To: Dawood Iqbal Cc: nanog at nanog.org Subject: RE: Best VPN Appliance Sent: Mar 8, 2010 11:56 AM We're generally happy with our Juniper SA6500s, but they, and a lot of the other SSL VPN vendor appliances will not support IPSec. Cisco's ASA does, but it's less feature-rich in the SSL VPN arena. The Juniper was the most mature and flexible of all the offerings we looked at, but also the most expensive, and it's not perfect either. Having migrated from Cisco's 3000 series appliances, the current SSL VPNs are a totally different mindset and about two orders of magnitude more complicated. Have a very good understanding of exactly what problem you're trying to solve with the product and what kind of policies and requirements you have to meet, or it's going to be a mess. I can answer more specific questions on our experiences and testing off-list. -- Toivo Voll University of South Florida Information Technology Communications -----Original Message----- From: Chris Campbell [mailto:Chris.Campbell at nebulassolutions.com] Sent: Friday, March 05, 2010 11:36 AM To: Dawood Iqbal Cc: nanog at nanog.org Subject: Re: Best VPN Appliance The Juniper SA is by far and away the market leader and in my opinion the best end user experience. On 5 Mar 2010, at 15:57, Dawood Iqbal wrote: > Hello All, > > > > Is it possible to get your ideas on what VPN appliances are good to have in > enterprise network? > > > > Requirements are; > > SSL > > IPSec > > Client and Web VPN support (Win/MAC/iPhone/Android) > > If webvpn is used, then when any user connects via webvpn, we should be able > to re-direct him to any and ONLY specific application i.e SAP. > > If 2 boxes are installed then they should replicate data seamlessly. > > > > > > Regards, > > dI > Sent from my Verizon Wireless BlackBerry From bjohnson at drtel.com Mon Mar 8 13:39:00 2010 From: bjohnson at drtel.com (Brian Johnson) Date: Mon, 8 Mar 2010 13:39:00 -0600 Subject: Best VPN Appliance In-Reply-To: References: Message-ID: <29A54911243620478FF59F00EBB12F4701CEE5D0@ex01.drtel.lan> I've used the Cisco ASAs without issue. Cisco flamers need not respond. :P This is a bit of a loaded question though. - Brian > -----Original Message----- > From: Dawood Iqbal [mailto:Dawood_Iqbal at hotmail.com] > Sent: Friday, March 05, 2010 9:58 AM > To: nanog at nanog.org > Subject: Best VPN Appliance > > Hello All, > > > > Is it possible to get your ideas on what VPN appliances are good to > have in > enterprise network? > > > > Requirements are; > > SSL > > IPSec > > Client and Web VPN support (Win/MAC/iPhone/Android) > > If webvpn is used, then when any user connects via webvpn, we should be > able > to re-direct him to any and ONLY specific application i.e SAP. > > If 2 boxes are installed then they should replicate data seamlessly. > > > > > > Regards, > > dI CONFIDENTIALITY NOTICE: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, copying, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you. From mksmith at adhost.com Mon Mar 8 13:42:32 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 8 Mar 2010 11:42:32 -0800 Subject: Best VPN Appliance In-Reply-To: References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> Message-ID: <17838240D9A5544AAA5FF95F8D52031607B15A4F@ad-exh01.adhost.lan> > -----Original Message----- > From: Blomberg, Orin P (DOH) [mailto:Orin.Blomberg at DOH.WA.GOV] > Sent: Monday, March 08, 2010 11:37 AM > To: sfouant at shortestpathfirst.net; Voll, Toivo; Chris Campbell; Dawood > Iqbal > Cc: nanog at nanog.org > Subject: RE: Best VPN Appliance > > There is also the fact to consider that Cisco has said there will be no > support for Windows 64-bit on their IPSEC client, they are pushing > people to the AnyConnect (An SSL-based clientless IPSEC) who want to > use > Windows 64-bit or other OSs, so in the future the argument for having a > separate box for client-based IPSEC will be moot. > The beta 64-bit VPN client has been released, FYI. Mike From nicotine at warningg.com Mon Mar 8 13:42:34 2010 From: nicotine at warningg.com (Brandon Ewing) Date: Mon, 8 Mar 2010 13:42:34 -0600 Subject: Best VPN Appliance In-Reply-To: References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> Message-ID: <20100308194234.GA18411@radiological.warningg.com> On Mon, Mar 08, 2010 at 11:37:02AM -0800, Blomberg, Orin P (DOH) wrote: > There is also the fact to consider that Cisco has said there will be no > support for Windows 64-bit on their IPSEC client, they are pushing > people to the AnyConnect (An SSL-based clientless IPSEC) who want to use > Windows 64-bit or other OSs, so in the future the argument for having a > separate box for client-based IPSEC will be moot. > Cisco has released a beta version of their 64-bit IPSec client for Windows 7. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jasongurtz at npumail.com Mon Mar 8 13:43:29 2010 From: jasongurtz at npumail.com (Jason Gurtz) Date: Mon, 8 Mar 2010 14:43:29 -0500 Subject: Best VPN Appliance In-Reply-To: References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> Message-ID: > There is also the fact to consider that Cisco has said there will be no > support for Windows 64-bit on their IPSEC client [...] Amazingly, and to many people's great surprise, Cisco recently made available a beta version of the IPSEC VPN client that supports 64-bit. ~JasonG -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5103 bytes Desc: not available URL: From Orin.Blomberg at DOH.WA.GOV Mon Mar 8 13:50:29 2010 From: Orin.Blomberg at DOH.WA.GOV (Blomberg, Orin P (DOH)) Date: Mon, 8 Mar 2010 11:50:29 -0800 Subject: Best VPN Appliance In-Reply-To: <17838240D9A5544AAA5FF95F8D52031607B15A4F@ad-exh01.adhost.lan> References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> <17838240D9A5544AAA5FF95F8D52031607B15A4F@ad-exh01.adhost.lan> Message-ID: Thanks for the information. I am just going on what we have been formally told by our onsite Cisco engineers on several occasions. It may be that they were misinformed, or that they are trying to make the sell for AnyConnect Licensing, but I had been going with the facts I had. I am glad there is a 64-bit in beta, at least, now I don't have to migrate all those people off the ASAs right away. Orin -----Original Message----- From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] Sent: Monday, March 08, 2010 11:43 AM To: Blomberg, Orin P (DOH); sfouant at shortestpathfirst.net; Voll, Toivo; Chris Campbell; Dawood Iqbal Cc: nanog at nanog.org Subject: RE: Best VPN Appliance > -----Original Message----- > From: Blomberg, Orin P (DOH) [mailto:Orin.Blomberg at DOH.WA.GOV] > Sent: Monday, March 08, 2010 11:37 AM > To: sfouant at shortestpathfirst.net; Voll, Toivo; Chris Campbell; Dawood > Iqbal > Cc: nanog at nanog.org > Subject: RE: Best VPN Appliance > > There is also the fact to consider that Cisco has said there will be no > support for Windows 64-bit on their IPSEC client, they are pushing > people to the AnyConnect (An SSL-based clientless IPSEC) who want to > use > Windows 64-bit or other OSs, so in the future the argument for having a > separate box for client-based IPSEC will be moot. > The beta 64-bit VPN client has been released, FYI. Mike From jda at tapodi.net Mon Mar 8 13:53:55 2010 From: jda at tapodi.net (Jon Auer) Date: Mon, 8 Mar 2010 13:53:55 -0600 Subject: Best VPN Appliance In-Reply-To: References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> Message-ID: If you can use 3rd party VPN clients the ShrewSoft IPSec client on Windows 7 works great with Cisco concentrators. http://www.shrew.net/software On Mon, Mar 8, 2010 at 1:37 PM, Blomberg, Orin P (DOH) wrote: > There is also the fact to consider that Cisco has said there will be no > support for Windows 64-bit on their IPSEC client, they are pushing > people to the AnyConnect (An SSL-based clientless IPSEC) who want to use > Windows 64-bit or other OSs, so in the future the argument for having a > separate box for client-based IPSEC will be moot. > > Orin > > -----Original Message----- > From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] > Sent: Monday, March 08, 2010 11:29 AM > To: Voll, Toivo; Chris Campbell; Dawood Iqbal > Cc: nanog at nanog.org > Subject: Re: Best VPN Appliance > > Toivo, > > The SA Series absolutely supports IPsec if you are using Network > Connect. ?It defaults to using IPsec and if that is not supported then > it will fall back to SSL. ?Of course, NC is not as secure as W-SAM, > J-SAM, or Core Access in terms of role and resource granularity control > but the support for IPsec is absolutely there. > > HTHs. > > Stefan Fouant > ------Original Message------ > From: Voll, Toivo > To: Chris Campbell > To: Dawood Iqbal > Cc: nanog at nanog.org > Subject: RE: Best VPN Appliance > Sent: Mar 8, 2010 11:56 AM > > We're generally happy with our Juniper SA6500s, but they, and a lot of > the other SSL VPN vendor appliances will not support IPSec. Cisco's ASA > does, but it's less feature-rich in the SSL VPN arena. The Juniper was > the most mature and flexible of all the offerings we looked at, but also > the most expensive, and it's not perfect either. > > Having migrated from Cisco's 3000 series appliances, the current SSL > VPNs are a totally different mindset and about two orders of magnitude > more complicated. Have a very good understanding of exactly what problem > you're trying to solve with the product and what kind of policies and > requirements you have to meet, or it's going to be a mess. I can answer > more specific questions on our experiences and testing off-list. > > -- > Toivo Voll > University of South Florida > Information Technology Communications > > > > > -----Original Message----- > From: Chris Campbell [mailto:Chris.Campbell at nebulassolutions.com] > Sent: Friday, March 05, 2010 11:36 AM > To: Dawood Iqbal > Cc: nanog at nanog.org > Subject: Re: Best VPN Appliance > > The Juniper SA is by far and away the market leader and in my opinion > the best end user experience. > > On 5 Mar 2010, at 15:57, Dawood Iqbal wrote: > >> Hello All, >> >> >> >> Is it possible to get your ideas on what VPN appliances are good to > have in >> enterprise network? >> >> >> >> Requirements are; >> >> SSL >> >> IPSec >> >> Client and Web VPN support (Win/MAC/iPhone/Android) >> >> If webvpn is used, then when any user connects via webvpn, we should > be able >> to re-direct him to any and ONLY specific application i.e SAP. >> >> If 2 boxes are installed then they should replicate data seamlessly. >> >> >> >> >> >> Regards, >> >> dI >> > > > > > Sent from my Verizon Wireless BlackBerry > > From williamsjj at digitar.com Mon Mar 8 13:57:15 2010 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Mon, 8 Mar 2010 12:57:15 -0700 Subject: Best VPN Appliance In-Reply-To: References: Message-ID: We've been running various Fortinet Fortigate appliances since 2003 and have had very good luck with them. Clustering is plug-and-play...boxes act as a single managed unit and do stateful failover of VPN connections. We use the IPsec for site-to-site between our offices and our data centers, the SSL VPN we use for all of our road tunnels. SSL clients work great on WinXP, Win7 and OS X. There's a new iPhone app as well for the web-based VPN. -J -------- Jason J. W. Williams, COO/CTO DigiTar williamsjj at digitar.com V: 208.343.8520 F: 208.322.8522 M: 208.863.0727 www.digitar.com On Mar 5, 2010, at 8:57 AM, Dawood Iqbal wrote: > > Hello All, > > > > Is it possible to get your ideas on what VPN appliances are good to have in > enterprise network? > > > > Requirements are; > > SSL > > IPSec > > Client and Web VPN support (Win/MAC/iPhone/Android) > > If webvpn is used, then when any user connects via webvpn, we should be able > to re-direct him to any and ONLY specific application i.e SAP. > > If 2 boxes are installed then they should replicate data seamlessly. > > > > > > Regards, > > dI > > !SIG:4b912af4162726244877506! > From tvarriale at comcast.net Mon Mar 8 14:23:03 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Mon, 8 Mar 2010 14:23:03 -0600 Subject: Best VPN Appliance References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry><17838240D9A5544AAA5FF95F8D52031607B15A4F@ad-exh01.adhost.lan> Message-ID: <283EC5F9D71646C08A2ED35875E54F6A@flamdt01> Why would you migrate them away instead of buying a $150/$250 one-time license? tv ----- Original Message ----- From: "Blomberg, Orin P (DOH)" To: Sent: Monday, March 08, 2010 1:50 PM Subject: RE: Best VPN Appliance Thanks for the information. I am just going on what we have been formally told by our onsite Cisco engineers on several occasions. It may be that they were misinformed, or that they are trying to make the sell for AnyConnect Licensing, but I had been going with the facts I had. I am glad there is a 64-bit in beta, at least, now I don't have to migrate all those people off the ASAs right away. Orin -----Original Message----- From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] Sent: Monday, March 08, 2010 11:43 AM To: Blomberg, Orin P (DOH); sfouant at shortestpathfirst.net; Voll, Toivo; Chris Campbell; Dawood Iqbal Cc: nanog at nanog.org Subject: RE: Best VPN Appliance > -----Original Message----- > From: Blomberg, Orin P (DOH) [mailto:Orin.Blomberg at DOH.WA.GOV] > Sent: Monday, March 08, 2010 11:37 AM > To: sfouant at shortestpathfirst.net; Voll, Toivo; Chris Campbell; Dawood > Iqbal > Cc: nanog at nanog.org > Subject: RE: Best VPN Appliance > > There is also the fact to consider that Cisco has said there will be no > support for Windows 64-bit on their IPSEC client, they are pushing > people to the AnyConnect (An SSL-based clientless IPSEC) who want to > use > Windows 64-bit or other OSs, so in the future the argument for having a > separate box for client-based IPSEC will be moot. > The beta 64-bit VPN client has been released, FYI. Mike From erik_list at caneris.com Mon Mar 8 17:10:28 2010 From: erik_list at caneris.com (Erik L) Date: Mon, 8 Mar 2010 18:10:28 -0500 Subject: PPP+RADIUS - routing subnets to end users - Framed-Route vs. Framed-IP-Netmask Message-ID: Scenario: with the help of RADIUS, routing subnets to end users connecting via PPP. Discussion: pros/cons of using Framed-IP-Address+Framed-Route versus Framed-IP-Address+Framed-IP-Netmask. We're talking here in generic terms, so as far as the behaviour of the LNS or access concentrator or whatever else is receiving the Access-Accept and terminating the ppp session, we're assuming more or less sane behaviour, roughly as follows. In the first alternative, the IP address on the ppp link is outside the subnet indicated by Framed-Route and one or more subnets are routed via the link; one such subnet per Framed-Route attrib. In the second alternative, the one subnet routed is that which contains the Framed-IP-Address and is as large as the Framed-IP-Netmask indicates. I'm arguing to a colleague that the first alternative is "better", non-/32 netmasks on a ppp link make no sense (since netmasks on point-to-point links don't matter anyway), that the second alternative doesn't allow users to make use of their allocated space as easily and effectively as the first alternative, and that the second alternative is limited to routing one subnet (though you might be able to mix Framed-IP-Netmask and Framed-Route together?). Comments? How are others doing it and why? Erik From george at montco.net Mon Mar 8 17:33:32 2010 From: george at montco.net (George Carey) Date: Mon, 8 Mar 2010 18:33:32 -0500 Subject: PPP+RADIUS - routing subnets to end users - Framed-Route vs. Framed-IP-Netmask In-Reply-To: References: Message-ID: We've always considered the WAN and LAN to be different objects so our history is to prefer the method you think is 'better.' Seems this model has been around since the dialin days. We also have customers with multiple routes so it seems a logical separation. Failover might be a bit more flexible too since you can control some parameters of the Framed Route. I know some people use RFC1918 addresses for WAN which might be a factor (we do not). Perhaps in some network strategies the lines between WAN and LAN may be a bit more blurred than ours. George On Mar 8, 2010, at 6:10 PM, Erik L wrote: > Scenario: with the help of RADIUS, routing subnets to end users connecting via PPP. > > Discussion: pros/cons of using Framed-IP-Address+Framed-Route versus Framed-IP-Address+Framed-IP-Netmask. > > We're talking here in generic terms, so as far as the behaviour of the LNS or access concentrator or whatever else is receiving the Access-Accept and terminating the ppp session, we're assuming more or less sane behaviour, roughly as follows. In the first alternative, the IP address on the ppp link is outside the subnet indicated by Framed-Route and one or more subnets are routed via the link; one such subnet per Framed-Route attrib. In the second alternative, the one subnet routed is that which contains the Framed-IP-Address and is as large as the Framed-IP-Netmask indicates. > > I'm arguing to a colleague that the first alternative is "better", non-/32 netmasks on a ppp link make no sense (since netmasks on point-to-point links don't matter anyway), that the second alternative doesn't allow users to make use of their allocated space as easily and effectively as the first alternative, and that the second alternative is limited to routing one subnet (though you might be able to mix Framed-IP-Netmask and Framed-Route together?). > > Comments? How are others doing it and why? > > Erik > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available URL: From tdurack at gmail.com Mon Mar 8 21:59:18 2010 From: tdurack at gmail.com (Tim Durack) Date: Mon, 8 Mar 2010 22:59:18 -0500 Subject: FreeAxez raised flooring? In-Reply-To: <3c3e3fca1003051921p489d7de5hd3a2df3292fe8d10@mail.gmail.com> References: <7db2dcf91003050814k38252315nb543fbb4d7b980@mail.gmail.com> <3c3e3fca1003051041ma822fa6r60ee4065c68456e5@mail.gmail.com> <0DB35DA7-9BF8-40CC-A9E5-AB74D06CD5A9@delong.com> <20100305191539.GA48474@typo.org> <9e246b4d1003051311j180cf409ya0fea8ef9531660f@mail.gmail.com> <20100305164559.6ea3455e.darcy@Vex.Net> <9e246b4d1003051910i3b77e9efi74d9e014437a5dda@mail.gmail.com> <3c3e3fca1003051921p489d7de5hd3a2df3292fe8d10@mail.gmail.com> Message-ID: <9e246b4d1003081959u2718200dn76fcf45846026a38@mail.gmail.com> On Fri, Mar 5, 2010 at 10:21 PM, William Herrin wrote: > I poked through AFCO's drawings at > http://www.afcosystems.com/pdf/AFCO_Drawings.pdf, How much of a size > hit is typical? Do you take the depth out to 52" to create enough > space in front of the equipment for air to flow and take the 6-inch > hit to the side for the cabling sidecar? EHD racks with 6" sidecars, one on each side, as we have significant cabling density to handle. Rack frame is 48" deep. > What's the impact with respect to sharing the facility with non-AFCO > cabinets? I would imagine that with a bunch of these things > dynamically changing their air flow it would be hard to maintain a > static pressure under the floor. No impact - it's all the same racks :-) Airflow under the floor has not been an issue. It's not much different than moving perf tiles around periodically. -- Tim:> From laurens at daemon.be Tue Mar 9 07:05:38 2010 From: laurens at daemon.be (Laurens Vets) Date: Tue, 09 Mar 2010 14:05:38 +0100 Subject: Best VPN Appliance In-Reply-To: References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> Message-ID: <4B9647A2.9000705@daemon.be> On 3/8/2010 8:37 PM, Blomberg, Orin P (DOH) wrote: > There is also the fact to consider that Cisco has said there will be no > support for Windows 64-bit on their IPSEC client, they are pushing > people to the AnyConnect (An SSL-based clientless IPSEC) who want to use > Windows 64-bit or other OSs, so in the future the argument for having a > separate box for client-based IPSEC will be moot. You can also use the Shrew Soft VPN Client. Comes in various flavors including 64-bit. Greetings, L. > -----Original Message----- > From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] > Sent: Monday, March 08, 2010 11:29 AM > To: Voll, Toivo; Chris Campbell; Dawood Iqbal > Cc: nanog at nanog.org > Subject: Re: Best VPN Appliance > > Toivo, > > The SA Series absolutely supports IPsec if you are using Network > Connect. It defaults to using IPsec and if that is not supported then > it will fall back to SSL. Of course, NC is not as secure as W-SAM, > J-SAM, or Core Access in terms of role and resource granularity control > but the support for IPsec is absolutely there. > > HTHs. > > Stefan Fouant > ------Original Message------ > From: Voll, Toivo > To: Chris Campbell > To: Dawood Iqbal > Cc: nanog at nanog.org > Subject: RE: Best VPN Appliance > Sent: Mar 8, 2010 11:56 AM > > We're generally happy with our Juniper SA6500s, but they, and a lot of > the other SSL VPN vendor appliances will not support IPSec. Cisco's ASA > does, but it's less feature-rich in the SSL VPN arena. The Juniper was > the most mature and flexible of all the offerings we looked at, but also > the most expensive, and it's not perfect either. > > Having migrated from Cisco's 3000 series appliances, the current SSL > VPNs are a totally different mindset and about two orders of magnitude > more complicated. Have a very good understanding of exactly what problem > you're trying to solve with the product and what kind of policies and > requirements you have to meet, or it's going to be a mess. I can answer > more specific questions on our experiences and testing off-list. > > -- > Toivo Voll > University of South Florida > Information Technology Communications > > > > > -----Original Message----- > From: Chris Campbell [mailto:Chris.Campbell at nebulassolutions.com] > Sent: Friday, March 05, 2010 11:36 AM > To: Dawood Iqbal > Cc: nanog at nanog.org > Subject: Re: Best VPN Appliance > > The Juniper SA is by far and away the market leader and in my opinion > the best end user experience. > > On 5 Mar 2010, at 15:57, Dawood Iqbal wrote: > >> Hello All, >> >> >> >> Is it possible to get your ideas on what VPN appliances are good to > have in >> enterprise network? >> >> >> >> Requirements are; >> >> SSL >> >> IPSec >> >> Client and Web VPN support (Win/MAC/iPhone/Android) >> >> If webvpn is used, then when any user connects via webvpn, we should > be able >> to re-direct him to any and ONLY specific application i.e SAP. >> >> If 2 boxes are installed then they should replicate data seamlessly. >> >> >> >> >> >> Regards, >> >> dI >> > > > > > Sent from my Verizon Wireless BlackBerry > > > From james at freedomnet.co.nz Tue Mar 9 09:50:24 2010 From: james at freedomnet.co.nz (James Jones) Date: Tue, 09 Mar 2010 10:50:24 -0500 Subject: networking job list Message-ID: <4B966E40.6040204@freedomnet.co.nz> Hey everyone, I posted an email a last week asking about a NANOG job board/list. I received no responses so Jared Mauch and I thought it would be a good idea to start a separate mailing list for this purpose. I will be moderating this for the time being and asking for more moderators as it grows. This is here to help network operators to stay network operators. So please if you have a need for network operators or engineers please post it on this list. Thanks for your support. You can subscribe here: https://puck.nether.net/mailman/listinfo/network-jobs -- James Jones +1-413-667-9199 james at freedomnet.co.nz From frnkblk at iname.com Tue Mar 9 09:58:42 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 9 Mar 2010 09:58:42 -0600 Subject: Calix listserv starting up -- delete if you're not interested Message-ID: Considering that there are likely more than a handful of Calix customers in this list, I'd like to advertise a new listserv to talk about all things Calix, namely calix-nsp. If you're interested, you can sign up here: https://puck.nether.net/mailman/listinfo/calix-nsp Regards, Frank Bulk From scott at doc.net.au Tue Mar 9 11:47:15 2010 From: scott at doc.net.au (Scott Howard) Date: Tue, 9 Mar 2010 09:47:15 -0800 Subject: Best VPN Appliance In-Reply-To: References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> <17838240D9A5544AAA5FF95F8D52031607B15A4F@ad-exh01.adhost.lan> Message-ID: On Mon, Mar 8, 2010 at 11:50 AM, Blomberg, Orin P (DOH) wrote: > Thanks for the information. ?I am just going on what we have been > formally told by our onsite Cisco engineers on several occasions. ?It > may be that they were misinformed, or that they are trying to make the > sell for AnyConnect Licensing, but I had been going with the facts I > had. It was neither, at least not specifically on the side of your engineers. Cisco had absolutely no plans to release a 64-bit IPSec client - not because they couldn't (they have had a working version for some time), but because they have been trying to kill off the product for years to try and migrate customers to their newer products (ie, AnyConnect). So your Cisco engineers were absolutely correct - at the time - in saying that there would never be a 64 bit version. Obviously it seems they have finally buckled to customer pressure (!) and release a 64 bit version, which is good news for everyone except whoever's job in Cisco it was to EOL the IPSec code. It's unfortunate that they didn't take the obvious approach and put IPSec into AnyConnect when it first came out, which would have avoided all of these issues. (I used to work for Cisco in the Security Technology Business Unit, but I don't any more so I'm obviously not speaking on behalf of anyone other than possibly myself!) Scott. From toivo at usf.edu Tue Mar 9 12:03:36 2010 From: toivo at usf.edu (Voll, Toivo) Date: Tue, 9 Mar 2010 13:03:36 -0500 Subject: Best VPN Appliance In-Reply-To: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> Message-ID: You are correct; I should have been more pedantic -- the SA series cannot terminate site-to-site IPsec tunnels, according to the sales engineer, unlike the Cisco 3000 series and ASA. -- Toivo Voll University of South Florida Information Technology Communications -----Original Message----- From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] Sent: Monday, March 08, 2010 2:29 PM To: Voll, Toivo; Chris Campbell; Dawood Iqbal Cc: nanog at nanog.org Subject: Re: Best VPN Appliance Toivo, The SA Series absolutely supports IPsec if you are using Network Connect. It defaults to using IPsec and if that is not supported then it will fall back to SSL. Of course, NC is not as secure as W-SAM, J-SAM, or Core Access in terms of role and resource granularity control but the support for IPsec is absolutely there. From piotr.sawicki.pl at gmail.com Tue Mar 9 12:03:36 2010 From: piotr.sawicki.pl at gmail.com (piotr sawicki) Date: Tue, 09 Mar 2010 19:03:36 +0100 Subject: Alcatel-Lucent In-Reply-To: <4B94FC14.4040106@gmail.com> References: <4B94FC14.4040106@gmail.com> Message-ID: <4B968D78.8010105@gmail.com> > > The worst thing in it was bgp proto .. Router was unable to withstand > 20+ peering sessions , most of that outgoing bgp session to customers > , a few peerings , and only 1v2 incoming upstream providers > When there was instability/surge in bgp updates , router was able to > break itself tcp sess. Dwnld bgp table (150,000prefix) took 2h or more > ... > Things done in hardware should be working although ( bridge .. , maybe > label switching , vpls ) Tech support is very weak. Expect problems > with interoperability . > Sorry to say that . It was 3+ years time ago , maybe they improved > themself .. :) > Hi, I must say we had very old timos 2.0R17 , as you now use 8.0 I guess .. As most of my complains is against software , this may be improved - i hope it is :) Hardware is solid, 'hard to kill' Sorry for a bit preliminary assumptions about 7750SR platform . // regards PiotrSawicki. From jlightfoot at gmail.com Tue Mar 9 12:54:51 2010 From: jlightfoot at gmail.com (John Lightfoot) Date: Tue, 9 Mar 2010 13:54:51 -0500 Subject: Best VPN Appliance In-Reply-To: References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> <17838240D9A5544AAA5FF95F8D52031607B15A4F@ad-exh01.adhost.lan> Message-ID: <009f01cabfba$00bbcb50$023361f0$@gmail.com> Can anyone tell me how to get the beta 64 bit client? Thanks. -----Original Message----- From: Scott Howard [mailto:scott at doc.net.au] Sent: Tuesday, March 09, 2010 12:47 PM To: Blomberg, Orin P (DOH) Cc: nanog at nanog.org Subject: Re: Best VPN Appliance On Mon, Mar 8, 2010 at 11:50 AM, Blomberg, Orin P (DOH) wrote: > Thanks for the information. ?I am just going on what we have been > formally told by our onsite Cisco engineers on several occasions. ?It > may be that they were misinformed, or that they are trying to make the > sell for AnyConnect Licensing, but I had been going with the facts I > had. It was neither, at least not specifically on the side of your engineers. Cisco had absolutely no plans to release a 64-bit IPSec client - not because they couldn't (they have had a working version for some time), but because they have been trying to kill off the product for years to try and migrate customers to their newer products (ie, AnyConnect). So your Cisco engineers were absolutely correct - at the time - in saying that there would never be a 64 bit version. Obviously it seems they have finally buckled to customer pressure (!) and release a 64 bit version, which is good news for everyone except whoever's job in Cisco it was to EOL the IPSec code. It's unfortunate that they didn't take the obvious approach and put IPSec into AnyConnect when it first came out, which would have avoided all of these issues. (I used to work for Cisco in the Security Technology Business Unit, but I don't any more so I'm obviously not speaking on behalf of anyone other than possibly myself!) Scott. From ask at develooper.com Tue Mar 9 02:38:58 2010 From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Tue, 9 Mar 2010 00:38:58 -0800 Subject: IPv6 client adoption slowly going 3% (?) Message-ID: Hi everyone, I read the IPv4 address space thread and thought this might be of interest to the group: Some months ago I setup a small test to test if users browsing http://www.pool.ntp.org/ supported IPv6: http://www.v6test.develooper.com/statistics http://www.v6test.develooper.com/ It's slowly been creeping up to 2.8% this month (from ~2.2% in November). At this rate we'll have critical mass (say 25%?) already in 2022! Kidding aside, although most of the test data is from NTP Pool website currently I've been testing a few different sites and the numbers are all pretty close. Anyway - if you want to test your user base, then you can make an account at http://www.v6test.develooper.com/account and get a bit of javascript to put on your website/weblog/... The code for the system is at http://git.develooper.com/?p=v6test.git;a=summary and http://github.com/abh/v6test Specifically the javascript doing the test at: http://github.com/abh/v6test/blob/master/public/devel/v6test.js I've also been testing how many fails to handle A+AAAA records and it seems to be about 2-3%[1] -- which sounds like more than plenty for Google, Amazon etc not to enable IPv6 on their regular hostnames where it matters. - ask [1] The number on the "global" statistics page is artificially low because many of the tests have been via a host with both A and AAAA records and I forgot to take that into account when calculating the numbers. Oops. I'll get it fixed. -- http://develooper.com/ - http://askask.com/ From bfeeny at mac.com Tue Mar 9 13:51:28 2010 From: bfeeny at mac.com (Brian Feeny) Date: Tue, 09 Mar 2010 14:51:28 -0500 Subject: CRS-3 Message-ID: So who is going to be the first to deploy these? http://newsroom.cisco.com/dlls/2010/prod_030910.html - Download the entire Library of Congress in just over 1 second - Stream every motion picture ever created in less than four minutes If nothing else you gotta love the Cisco Marketing machine! Brian From dhubbard at dino.hostasaurus.com Tue Mar 9 13:54:16 2010 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 9 Mar 2010 14:54:16 -0500 Subject: CRS-3 Message-ID: From: Brian Feeny [mailto:bfeeny at mac.com] > > So who is going to be the first to deploy these? > > http://newsroom.cisco.com/dlls/2010/prod_030910.html > > > - Download the entire Library of Congress in just over 1 second > - Stream every motion picture ever created in less than four minutes > > If nothing else you gotta love the Cisco Marketing machine! > > Brian The article about this in the tech section on CNN already has comments in it like "Oh, well Cisco owns Linksys and I have a Linksys router so will my ISP be updating me to the CRS-3 so I can download at those speeds?" LOL From brandon.galbraith at gmail.com Tue Mar 9 14:09:27 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 9 Mar 2010 14:09:27 -0600 Subject: CRS-3 In-Reply-To: <366100671003091208q195e3d8fl5082eb3850415d4d@mail.gmail.com> References: <366100671003091208q195e3d8fl5082eb3850415d4d@mail.gmail.com> Message-ID: <366100671003091209x11f2fd65q2fa50140c1899a72@mail.gmail.com> It was mentioned that Att is already testing this with a 100gbps fiber run. On Mar 9, 2010 1:53 PM, "Brian Feeny" wrote: So who is going to be the first to deploy these? http://newsroom.cisco.com/dlls/2010/prod_030910.html - Download the entire Library of Congress in just over 1 second - Stream every motion picture ever created in less than four minutes If nothing else you gotta love the Cisco Marketing machine! Brian From brett at the-watsons.org Tue Mar 9 14:14:09 2010 From: brett at the-watsons.org (Brett Watson) Date: Tue, 9 Mar 2010 13:14:09 -0700 Subject: CRS-3 In-Reply-To: <366100671003091209x11f2fd65q2fa50140c1899a72@mail.gmail.com> References: <366100671003091208q195e3d8fl5082eb3850415d4d@mail.gmail.com> <366100671003091209x11f2fd65q2fa50140c1899a72@mail.gmail.com> Message-ID: On Mar 9, 2010, at 1:09 PM, Brandon Galbraith wrote: > It was mentioned that Att is already testing this with a 100gbps fiber run. Maybe Peter Lothberg is testing one in his basement? :) -b From joel.esler at me.com Tue Mar 9 14:15:51 2010 From: joel.esler at me.com (Joel Esler) Date: Tue, 09 Mar 2010 15:15:51 -0500 Subject: CRS-3 In-Reply-To: <366100671003091209x11f2fd65q2fa50140c1899a72@mail.gmail.com> References: <366100671003091208q195e3d8fl5082eb3850415d4d@mail.gmail.com> <366100671003091209x11f2fd65q2fa50140c1899a72@mail.gmail.com> Message-ID: <67696696054649532984549755929952375919-Webmail@me.com> Yes, it says that right in the press release. J -- Joel Esler joel.esler at me.com http://www.joelesler.net On Tuesday, March 09, 2010, at 03:09PM, "Brandon Galbraith" wrote: >It was mentioned that Att is already testing this with a 100gbps fiber run. > >On Mar 9, 2010 1:53 PM, "Brian Feeny" wrote: > > >So who is going to be the first to deploy these? > >http://newsroom.cisco.com/dlls/2010/prod_030910.html > > >- Download the entire Library of Congress in just over 1 second >- Stream every motion picture ever created in less than four minutes > >If nothing else you gotta love the Cisco Marketing machine! > > > >Brian > > From nanog at enger.us Tue Mar 9 14:20:14 2010 From: nanog at enger.us (Robert Enger - NANOG) Date: Tue, 09 Mar 2010 12:20:14 -0800 Subject: CRS-3 In-Reply-To: References: Message-ID: <4B96AD7E.50302@enger.us> Forget Linksys: Didn't Peter Lothberg's mom have a CRS1 in her basement already? :-) She said it was great for drying her clothes. If she gets the CRS-3, will she be able to dry her clothes even faster? On 3/9/2010 11:54 AM, David Hubbard wrote: > > The article about this in the tech section on CNN > already has comments in it like "Oh, well Cisco > owns Linksys and I have a Linksys router so will > my ISP be updating me to the CRS-3 so I can > download at those speeds?" LOL > > > On 3/9/2010 11:54 AM, David Hubbard wrote: > From: Brian Feeny [mailto:bfeeny at mac.com] >> So who is going to be the first to deploy these? >> >> http://newsroom.cisco.com/dlls/2010/prod_030910.html >> >> >> - Download the entire Library of Congress in just over 1 second >> - Stream every motion picture ever created in less than four minutes >> >> If nothing else you gotta love the Cisco Marketing machine! >> >> Brian > The article about this in the tech section on CNN > already has comments in it like "Oh, well Cisco > owns Linksys and I have a Linksys router so will > my ISP be updating me to the CRS-3 so I can > download at those speeds?" LOL > > > From deleskie at gmail.com Tue Mar 9 14:22:16 2010 From: deleskie at gmail.com (deleskie at gmail.com) Date: Tue, 9 Mar 2010 20:22:16 +0000 Subject: CRS-3 Message-ID: <617164067-1268166137-cardhu_decombobulator_blackberry.rim.net-1066376024-@bda006.bisx.prod.on.blackberry> What happened to CRS-2? :) ------Original Message------ From: Robert Enger - NANOG To: David Hubbard Cc: nanog at nanog.org Subject: Re: CRS-3 Sent: Mar 9, 2010 4:20 PM Forget Linksys: Didn't Peter Lothberg's mom have a CRS1 in her basement already? :-) She said it was great for drying her clothes. If she gets the CRS-3, will she be able to dry her clothes even faster? On 3/9/2010 11:54 AM, David Hubbard wrote: > > The article about this in the tech section on CNN > already has comments in it like "Oh, well Cisco > owns Linksys and I have a Linksys router so will > my ISP be updating me to the CRS-3 so I can > download at those speeds?" LOL > > > On 3/9/2010 11:54 AM, David Hubbard wrote: > From: Brian Feeny [mailto:bfeeny at mac.com] >> So who is going to be the first to deploy these? >> >> http://newsroom.cisco.com/dlls/2010/prod_030910.html >> >> >> - Download the entire Library of Congress in just over 1 second >> - Stream every motion picture ever created in less than four minutes >> >> If nothing else you gotta love the Cisco Marketing machine! >> >> Brian > The article about this in the tech section on CNN > already has comments in it like "Oh, well Cisco > owns Linksys and I have a Linksys router so will > my ISP be updating me to the CRS-3 so I can > download at those speeds?" LOL > > > Sent from my BlackBerry device on the Rogers Wireless Network From brandon.kim at brandontek.com Tue Mar 9 14:23:56 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 9 Mar 2010 15:23:56 -0500 Subject: CRS-3 In-Reply-To: References: Message-ID: LOL! Wow that is a pretty sad comment...... But back to the CRS-3, just wow!!! > Subject: RE: CRS-3 > Date: Tue, 9 Mar 2010 14:54:16 -0500 > From: dhubbard at dino.hostasaurus.com > To: nanog at nanog.org > > From: Brian Feeny [mailto:bfeeny at mac.com] > > > > So who is going to be the first to deploy these? > > > > http://newsroom.cisco.com/dlls/2010/prod_030910.html > > > > > > - Download the entire Library of Congress in just over 1 second > > - Stream every motion picture ever created in less than four minutes > > > > If nothing else you gotta love the Cisco Marketing machine! > > > > Brian > > The article about this in the tech section on CNN > already has comments in it like "Oh, well Cisco > owns Linksys and I have a Linksys router so will > my ISP be updating me to the CRS-3 so I can > download at those speeds?" LOL > > > From patrick at ianai.net Tue Mar 9 14:29:56 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 9 Mar 2010 15:29:56 -0500 Subject: CRS-3 In-Reply-To: References: Message-ID: On Mar 9, 2010, at 3:23 PM, Brandon Kim wrote: > LOL! Wow that is a pretty sad comment...... > > But back to the CRS-3, just wow!!! Wow what? Is there anything in the CRS-3 that competitors are not shipping _today_? If you look at some startups, they are doing 4-5 times as many Gbps per slot, and pre-release equipment is in use in some networks already. The only "wow" here is "wow, why did cisco hype how far behind they are?" -- TTFN, patrick >> Subject: RE: CRS-3 >> Date: Tue, 9 Mar 2010 14:54:16 -0500 >> From: dhubbard at dino.hostasaurus.com >> To: nanog at nanog.org >> >> From: Brian Feeny [mailto:bfeeny at mac.com] >>> >>> So who is going to be the first to deploy these? >>> >>> http://newsroom.cisco.com/dlls/2010/prod_030910.html >>> >>> >>> - Download the entire Library of Congress in just over 1 second >>> - Stream every motion picture ever created in less than four minutes >>> >>> If nothing else you gotta love the Cisco Marketing machine! >>> >>> Brian >> >> The article about this in the tech section on CNN >> already has comments in it like "Oh, well Cisco >> owns Linksys and I have a Linksys router so will >> my ISP be updating me to the CRS-3 so I can >> download at those speeds?" LOL >> >> >> > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Mar 9 14:31:41 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 10 Mar 2010 07:01:41 +1030 Subject: CRS-3 In-Reply-To: References: Message-ID: <20100310070141.5beb9674@opy.nosense.org> On Tue, 09 Mar 2010 14:51:28 -0500 Brian Feeny wrote: > > So who is going to be the first to deploy these? > > http://newsroom.cisco.com/dlls/2010/prod_030910.html > > > - Download the entire Library of Congress in just over 1 second Is that about 11 giggitybits per second? > - Stream every motion picture ever created in less than four minutes > MPAA are preparing their lawsuits now. > If nothing else you gotta love the Cisco Marketing machine! > > > > Brian > From kilobit at gmail.com Tue Mar 9 14:33:31 2010 From: kilobit at gmail.com (bas) Date: Tue, 9 Mar 2010 21:33:31 +0100 Subject: CRS-3 In-Reply-To: References: Message-ID: On Tue, Mar 9, 2010 at 8:51 PM, Brian Feeny wrote > If nothing else you gotta love the Cisco Marketing machine! Indeed Cisco marketing machine. Nothing new to CRS-1, just new linecards and route-processor. It would be like giving the CAT6500 a new name back when the SUP720/DCEF cards came out. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Mar 9 14:34:50 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 10 Mar 2010 07:04:50 +1030 Subject: CRS-3 In-Reply-To: <617164067-1268166137-cardhu_decombobulator_blackberry.rim.net-1066376024-@bda006.bisx.prod.on.blackberry> References: <617164067-1268166137-cardhu_decombobulator_blackberry.rim.net-1066376024-@bda006.bisx.prod.on.blackberry> Message-ID: <20100310070450.6191392d@opy.nosense.org> On Tue, 9 Mar 2010 20:22:16 +0000 deleskie at gmail.com wrote: > What happened to CRS-2? :) I agree. We were joking at work what the announcement might be and I suggested a CRS2. Missed it by >< much :-( > ------Original Message------ > From: Robert Enger - NANOG > To: David Hubbard > Cc: nanog at nanog.org > Subject: Re: CRS-3 > Sent: Mar 9, 2010 4:20 PM > > > Forget Linksys: Didn't Peter Lothberg's mom have a CRS1 in her basement already? :-) > > She said it was great for drying her clothes. > If she gets the CRS-3, will she be able to dry her clothes even faster? > > > > On 3/9/2010 11:54 AM, David Hubbard wrote: > > > > The article about this in the tech section on CNN > > already has comments in it like "Oh, well Cisco > > owns Linksys and I have a Linksys router so will > > my ISP be updating me to the CRS-3 so I can > > download at those speeds?" LOL > > > > > > > > > On 3/9/2010 11:54 AM, David Hubbard wrote: > > From: Brian Feeny [mailto:bfeeny at mac.com] > >> So who is going to be the first to deploy these? > >> > >> http://newsroom.cisco.com/dlls/2010/prod_030910.html > >> > >> > >> - Download the entire Library of Congress in just over 1 second > >> - Stream every motion picture ever created in less than four minutes > >> > >> If nothing else you gotta love the Cisco Marketing machine! > >> > >> Brian > > The article about this in the tech section on CNN > > already has comments in it like "Oh, well Cisco > > owns Linksys and I have a Linksys router so will > > my ISP be updating me to the CRS-3 so I can > > download at those speeds?" LOL > > > > > > > > > > > Sent from my BlackBerry device on the Rogers Wireless Network From rgreenier at gmail.com Tue Mar 9 14:37:58 2010 From: rgreenier at gmail.com (Ryan Greenier) Date: Tue, 9 Mar 2010 15:37:58 -0500 Subject: Roadrunner Mail-gateway Contact Message-ID: If possible, can someone technical (dns/email) from Roadrunner contact me off-list? I tried going through the online & phone channels provided on the various websites, but I'm getting the run-around. Thanks, - Ryan From mailinglists at expresswebsystems.com Tue Mar 9 14:41:07 2010 From: mailinglists at expresswebsystems.com (Express Web Systems) Date: Tue, 9 Mar 2010 14:41:07 -0600 Subject: CRS-3 In-Reply-To: References: Message-ID: <001701cabfc8$d913fa50$8b3beef0$@com> > Wow what? > > Is there anything in the CRS-3 that competitors are not shipping _today_? > > If you look at some startups, they are doing 4-5 times as many Gbps per slot, > and pre-release equipment is in use in some networks already. > > The only "wow" here is "wow, why did cisco hype how far behind they are?" > It's called doing the "wall street dance". Their stock price jumped 3% yesterday in anticipation of the "big" announcement. Hype is hype, and people still remember the magic of the dotcom bubble. "ZOMG! They increased the size of the tubez! BUY! BUY!" [full disclosure: I own stock in Cisco] Tom Walsh Express Web Systems, Inc. From khuon at neebu.net Tue Mar 9 14:36:20 2010 From: khuon at neebu.net (Jake Khuon) Date: Tue, 09 Mar 2010 12:36:20 -0800 Subject: CRS-3 In-Reply-To: References: Message-ID: <1268166980.9876.85.camel@localhost> On Tue, 2010-03-09 at 15:29 -0500, Patrick W. Gilmore wrote: > The only "wow" here is "wow, why did cisco hype how far behind they > are?" Because in some organisations, the only vendor that matters is Cisco. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From khuon at neebu.net Tue Mar 9 14:43:12 2010 From: khuon at neebu.net (Jake Khuon) Date: Tue, 09 Mar 2010 12:43:12 -0800 Subject: CRS-3 In-Reply-To: <617164067-1268166137-cardhu_decombobulator_blackberry.rim.net-1066376024-@bda006.bisx.prod.on.blackberry> References: <617164067-1268166137-cardhu_decombobulator_blackberry.rim.net-1066376024-@bda006.bisx.prod.on.blackberry> Message-ID: <1268167392.9876.88.camel@localhost> On Tue, 2010-03-09 at 20:22 +0000, deleskie at gmail.com wrote: > What happened to CRS-2? :) It exploded and was destroyed during construction. Parts of it were also recycled to build the next CRS. |8^) -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From bedard.phil at gmail.com Tue Mar 9 14:57:28 2010 From: bedard.phil at gmail.com (Phil Bedard) Date: Tue, 9 Mar 2010 15:57:28 -0500 Subject: Alcatel-Lucent In-Reply-To: <4B968D78.8010105@gmail.com> References: <4B94FC14.4040106@gmail.com> <4B968D78.8010105@gmail.com> Message-ID: I've done some recent testing and while the BGP download time isn't blazing fast, it can load 400k routes and propagate them to 20 other peers in a few minutes. Certainly not 2 hours. :) I've also done quite a bit of interop testing with the other main vendors as well and have yet to run into anything major. Phil On Mar 9, 2010, at 1:03 PM, piotr sawicki wrote: >> >> The worst thing in it was bgp proto .. Router was unable to withstand 20+ peering sessions , most of that outgoing bgp session to customers , a few peerings , and only 1v2 incoming upstream providers >> When there was instability/surge in bgp updates , router was able to break itself tcp sess. Dwnld bgp table (150,000prefix) took 2h or more ... >> Things done in hardware should be working although ( bridge .. , maybe label switching , vpls ) Tech support is very weak. Expect problems with interoperability . >> Sorry to say that . It was 3+ years time ago , maybe they improved themself .. :) >> > > Hi, > > I must say we had very old timos 2.0R17 , as you now use 8.0 I guess .. > As most of my complains is against software , this may be improved - i hope it is :) > Hardware is solid, 'hard to kill' > Sorry for a bit preliminary assumptions about 7750SR platform . > > // regards PiotrSawicki. > From nick at foobar.org Tue Mar 9 15:07:41 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 09 Mar 2010 21:07:41 +0000 Subject: Best VPN Appliance In-Reply-To: <009f01cabfba$00bbcb50$023361f0$@gmail.com> References: <1265797326-1268076585-cardhu_decombobulator_blackberry.rim.net-2008957556-@bda294.bisx.prod.on.blackberry> <17838240D9A5544AAA5FF95F8D52031607B15A4F@ad-exh01.adhost.lan> <009f01cabfba$00bbcb50$023361f0$@gmail.com> Message-ID: <4B96B89D.60109@foobar.org> On 09/03/2010 18:54, John Lightfoot wrote: > Can anyone tell me how to get the beta 64 bit client? Thanks. > http://tools.cisco.com/support/downloads/go/ImageList.x?relVer=5.0.7+Beta&mdfid=281940730&sftType=VPN+Client+Software&optPlat=Windows Nick From arjan.van.der.oest at worldmax.nl Tue Mar 9 15:18:44 2010 From: arjan.van.der.oest at worldmax.nl (Arjan van der Oest) Date: Tue, 9 Mar 2010 22:18:44 +0100 Subject: CRS-3 References: Message-ID: Renaming the 6500? Nice one, let's call it 7600 then :-) Arjan -----Original Message----- From: bas [mailto:kilobit at gmail.com] Sent: Tue 3/9/2010 9:33 PM To: Brian Feeny Cc: nanog at nanog.org list Subject: Re: CRS-3 On Tue, Mar 9, 2010 at 8:51 PM, Brian Feeny wrote > If nothing else you gotta love the Cisco Marketing machine! Indeed Cisco marketing machine. Nothing new to CRS-1, just new linecards and route-processor. It would be like giving the CAT6500 a new name back when the SUP720/DCEF cards came out. Internet communications are not secure; therefore, the integrity of this e-mail cannot be guaranteed following transmission on the Internet. This e-mail may contain confidential information. If you have received this e-mail in error, please notify the sender and erase this e-mail. Use of this e-mail by any person other than the addressee is strictly forbidden. This e-mail is believed to be free of any virus that might adversely affect the addressee's computer system; however, no responsibility is accepted for any loss or damage arising in any way from its use. All the preceding disclaimers also apply to any possible attachments to this e-mail. From bfeeny at mac.com Tue Mar 9 15:24:47 2010 From: bfeeny at mac.com (Brian Feeny) Date: Tue, 09 Mar 2010 16:24:47 -0500 Subject: CRS-3 In-Reply-To: <001701cabfc8$d913fa50$8b3beef0$@com> References: <001701cabfc8$d913fa50$8b3beef0$@com> Message-ID: Yes, and their stock price dipped today after the news release actually hit. So remember people, buy on rumor, sell on news. Brian On Mar 9, 2010, at 3:41 PM, Express Web Systems wrote: >> Wow what? >> >> Is there anything in the CRS-3 that competitors are not shipping _today_? >> >> If you look at some startups, they are doing 4-5 times as many Gbps per > slot, >> and pre-release equipment is in use in some networks already. >> >> The only "wow" here is "wow, why did cisco hype how far behind they are?" >> > > It's called doing the "wall street dance". Their stock price jumped 3% > yesterday in anticipation of the "big" announcement. Hype is hype, and > people still remember the magic of the dotcom bubble. "ZOMG! They increased > the size of the tubez! BUY! BUY!" > > [full disclosure: I own stock in Cisco] > > Tom Walsh > Express Web Systems, Inc. > > From tdurack at gmail.com Tue Mar 9 15:39:25 2010 From: tdurack at gmail.com (Tim Durack) Date: Tue, 9 Mar 2010 16:39:25 -0500 Subject: CRS-3 In-Reply-To: References: Message-ID: <9e246b4d1003091339s44b0f034g904cd894b44867e9@mail.gmail.com> On Tue, Mar 9, 2010 at 2:51 PM, Brian Feeny wrote: > > So who is going to be the first to deploy these? > > http://newsroom.cisco.com/dlls/2010/prod_030910.html > > > - Download the entire Library of Congress in just over 1 second > - Stream every motion picture ever created in less than four minutes > > If nothing else you gotta love the Cisco Marketing machine! "This intelligence also includes carrier-grade IPv6 (CGv6)" Can't wait to find out what this is. -- Tim:> From pdavis at i2k.com Tue Mar 9 15:52:39 2010 From: pdavis at i2k.com (Philip Davis) Date: Tue, 09 Mar 2010 16:52:39 -0500 Subject: CRS-3 In-Reply-To: <9e246b4d1003091339s44b0f034g904cd894b44867e9@mail.gmail.com> References: <9e246b4d1003091339s44b0f034g904cd894b44867e9@mail.gmail.com> Message-ID: <4B96C327.2050104@i2k.com> On 3/9/2010 4:39 PM, Tim Durack wrote: > On Tue, Mar 9, 2010 at 2:51 PM, Brian Feeny wrote: >> >> So who is going to be the first to deploy these? >> >> http://newsroom.cisco.com/dlls/2010/prod_030910.html >> >> >> - Download the entire Library of Congress in just over 1 second >> - Stream every motion picture ever created in less than four minutes >> >> If nothing else you gotta love the Cisco Marketing machine! > > "This intelligence also includes carrier-grade IPv6 (CGv6)" > > Can't wait to find out what this is. > http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_paper_c11-558744-00_ns1017_Networking_Solutions_White_Paper.html First google link for CGv6. Skimmed it any saw something called 'Double NAT 444'. -- Philip Davis Systems Administrator I-2000 Inc. (616) 532-8425 888-234-4254 From joachim at tingvold.com Tue Mar 9 15:53:25 2010 From: joachim at tingvold.com (Joachim Tingvold) Date: Tue, 9 Mar 2010 22:53:25 +0100 Subject: CRS-3 In-Reply-To: <9e246b4d1003091339s44b0f034g904cd894b44867e9@mail.gmail.com> References: <9e246b4d1003091339s44b0f034g904cd894b44867e9@mail.gmail.com> Message-ID: On 9. mars 2010, at 22.39, Tim Durack wrote: > "This intelligence also includes carrier-grade IPv6 (CGv6)" > > Can't wait to find out what this is. http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_paper_c11-558744-00_ns1017_Networking_Solutions_White_Paper.html -- Joachim From nanog at djvh.nl Tue Mar 9 15:54:36 2010 From: nanog at djvh.nl (Dirk-Jan van Helmond) Date: Tue, 9 Mar 2010 22:54:36 +0100 Subject: CRS-3 In-Reply-To: <9e246b4d1003091339s44b0f034g904cd894b44867e9@mail.gmail.com> References: <9e246b4d1003091339s44b0f034g904cd894b44867e9@mail.gmail.com> Message-ID: It's teh future of the tubes! Didn't you get the memo? Nah, actually it is just hardware assisted SP-wide NAT... See: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_paper_c11-558744-00_ns1017_Networking_Solutions_White_Paper.html Cisco believes that this is the (intermediate-)solution to the IPv4 address depletion... Regards, Dirk On Mar 9, 2010, at 10:39 PM, Tim Durack wrote: > On Tue, Mar 9, 2010 at 2:51 PM, Brian Feeny wrote: >> >> So who is going to be the first to deploy these? >> >> http://newsroom.cisco.com/dlls/2010/prod_030910.html >> >> >> - Download the entire Library of Congress in just over 1 second >> - Stream every motion picture ever created in less than four minutes >> >> If nothing else you gotta love the Cisco Marketing machine! > > "This intelligence also includes carrier-grade IPv6 (CGv6)" > > Can't wait to find out what this is. > > -- > Tim:> > From patrick at ianai.net Tue Mar 9 16:02:01 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 9 Mar 2010 17:02:01 -0500 Subject: CRS-3 In-Reply-To: <1268166980.9876.85.camel@localhost> References: <1268166980.9876.85.camel@localhost> Message-ID: On Mar 9, 2010, at 3:36 PM, Jake Khuon wrote: > On Tue, 2010-03-09 at 15:29 -0500, Patrick W. Gilmore wrote: > >> The only "wow" here is "wow, why did cisco hype how far behind they >> are?" > > Because in some organisations, the only vendor that matters is Cisco. Then why bother hyping at all? Anyone who needs even a significant fraction of 322 Tbps is not going to ignore competitors. -- TTFN, patrick From swm at emanon.com Tue Mar 9 16:08:30 2010 From: swm at emanon.com (Scott Morris) Date: Tue, 09 Mar 2010 17:08:30 -0500 Subject: CRS-3 In-Reply-To: <617164067-1268166137-cardhu_decombobulator_blackberry.rim.net-1066376024-@bda006.bisx.prod.on.blackberry> References: <617164067-1268166137-cardhu_decombobulator_blackberry.rim.net-1066376024-@bda006.bisx.prod.on.blackberry> Message-ID: <4B96C6DE.7050506@emanon.com> It only supported IPv5. :) Scott [1]deleskie at gmail.com wrote: What happened to CRS-2? :) ------Original Message------ From: Robert Enger - NANOG To: David Hubbard Cc: [2]nanog at nanog.org Subject: Re: CRS-3 Sent: Mar 9, 2010 4:20 PM Forget Linksys: Didn't Peter Lothberg's mom have a CRS1 in her basement already ? :-) She said it was great for drying her clothes. If she gets the CRS-3, will she be able to dry her clothes even faster? On 3/9/2010 11:54 AM, David Hubbard wrote: The article about this in the tech section on CNN already has comments in it like "Oh, well Cisco owns Linksys and I have a Linksys router so will my ISP be updating me to the CRS-3 so I can download at those speeds?" LOL On 3/9/2010 11:54 AM, David Hubbard wrote: From: Brian Feeny [[3]mailto:bfeeny at mac.com] So who is going to be the first to deploy these? [4]http://newsroom.cisco.com/dlls/2010/prod_030910.html - Download the entire Library of Congress in just over 1 second - Stream every motion picture ever created in less than four minutes If nothing else you gotta love the Cisco Marketing machine! Brian The article about this in the tech section on CNN already has comments in it like "Oh, well Cisco owns Linksys and I have a Linksys router so will my ISP be updating me to the CRS-3 so I can download at those speeds?" LOL Sent from my BlackBerry device on the Rogers Wireless Network References 1. mailto:deleskie at gmail.com 2. mailto:nanog at nanog.org 3. mailto:bfeeny at mac.com 4. http://newsroom.cisco.com/dlls/2010/prod_030910.html From cian.brennan at redbrick.dcu.ie Tue Mar 9 16:12:47 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Tue, 9 Mar 2010 22:12:47 +0000 Subject: CRS-3 In-Reply-To: References: <1268166980.9876.85.camel@localhost> Message-ID: <20100309221247.GA20051@minerva.redbrick.dcu.ie> On Tue, Mar 09, 2010 at 05:02:01PM -0500, Patrick W. Gilmore wrote: > On Mar 9, 2010, at 3:36 PM, Jake Khuon wrote: > > On Tue, 2010-03-09 at 15:29 -0500, Patrick W. Gilmore wrote: > > > >> The only "wow" here is "wow, why did cisco hype how far behind they > >> are?" > > > > Because in some organisations, the only vendor that matters is Cisco. > > Then why bother hyping at all? > > Anyone who needs even a significant fraction of 322 Tbps is not going to ignore competitors. > Lots of people who don't will use this as a reason to convince themselves that Cisco is still miles ahead of the competition. After all, $COMPEDITOR isn't hyping their 322 Tbp/s gear. > -- > TTFN, > patrick > > > -- -- From mpetach at netflight.com Tue Mar 9 16:30:53 2010 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 9 Mar 2010 14:30:53 -0800 Subject: CRS-3 In-Reply-To: <1268167392.9876.88.camel@localhost> References: <617164067-1268166137-cardhu_decombobulator_blackberry.rim.net-1066376024-@bda006.bisx.prod.on.blackberry> <1268167392.9876.88.camel@localhost> Message-ID: <63ac96a51003091430g15e73d2co2c8ee0e6e1a10e0a@mail.gmail.com> On Tue, Mar 9, 2010 at 12:43 PM, Jake Khuon wrote: > On Tue, 2010-03-09 at 20:22 +0000, deleskie at gmail.com wrote: >> What happened to CRS-2? :) > > It exploded and was destroyed during construction. ?Parts of it were > also recycled to build the next CRS. |8^) /me sits back patiently and waits for CRS-5, then...[1] "...our last, best hope for throughput..." [1] http://babylon5.wikia.com/wiki/Babylon From khuon at neebu.net Tue Mar 9 16:31:19 2010 From: khuon at neebu.net (Jake Khuon) Date: Tue, 09 Mar 2010 14:31:19 -0800 Subject: CRS-3 In-Reply-To: References: <1268166980.9876.85.camel@localhost> Message-ID: <1268173879.9876.90.camel@localhost> On Tue, 2010-03-09 at 17:02 -0500, Patrick W. Gilmore wrote: > On Mar 9, 2010, at 3:36 PM, Jake Khuon wrote: > > On Tue, 2010-03-09 at 15:29 -0500, Patrick W. Gilmore wrote: > > > >> The only "wow" here is "wow, why did cisco hype how far behind they > >> are?" > > > > Because in some organisations, the only vendor that matters is > Cisco. > > Then why bother hyping at all? > > Anyone who needs even a significant fraction of 322 Tbps is not going > to ignore competitors. Come now. You know the answer to that. While technically true, by that logic, Cisco should never perform any press releases. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From joel.esler at me.com Tue Mar 9 17:02:36 2010 From: joel.esler at me.com (Joel Esler) Date: Tue, 09 Mar 2010 18:02:36 -0500 Subject: CRS-3 In-Reply-To: <1268166980.9876.85.camel@localhost> References: <1268166980.9876.85.camel@localhost> Message-ID: <8E8378CC-FD9A-447E-AD8F-D70E55067A74@me.com> No one ever got fired for buying Cisco? (This isn't true btw -- I know of people that did get fired for buying Cisco. Just saying...) J On Mar 9, 2010, at 3:36 PM, Jake Khuon wrote: > On Tue, 2010-03-09 at 15:29 -0500, Patrick W. Gilmore wrote: > >> The only "wow" here is "wow, why did cisco hype how far behind they >> are?" > > Because in some organisations, the only vendor that matters is Cisco. -- Joel Esler http://blog.joelesler.net From patrick at ianai.net Tue Mar 9 17:45:57 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 9 Mar 2010 18:45:57 -0500 Subject: CRS-3 In-Reply-To: <1268173879.9876.90.camel@localhost> References: <1268166980.9876.85.camel@localhost> <1268173879.9876.90.camel@localhost> Message-ID: <3E7DF632-ADE8-4647-BF35-C0F6EF61C4A5@ianai.net> Sent from my iPhone, please excuse any errors. On Mar 9, 2010, at 17:31, Jake Khuon wrote: > On Tue, 2010-03-09 at 17:02 -0500, Patrick W. Gilmore wrote: >> On Mar 9, 2010, at 3:36 PM, Jake Khuon wrote: >>> On Tue, 2010-03-09 at 15:29 -0500, Patrick W. Gilmore wrote: >>> >>>> The only "wow" here is "wow, why did cisco hype how far behind they >>>> are?" >>> >>> Because in some organisations, the only vendor that matters is >> Cisco. >> >> Then why bother hyping at all? >> >> Anyone who needs even a significant fraction of 322 Tbps is not going >> to ignore competitors. > > Come now. You know the answer to that. While technically true, by > that > logic, Cisco should never perform any press releases. First, this wasn't a press release, this was an event they were hyping for quite a while. Second, doing a press release is fine, but even the most aggressive companies have a modicum of truth in their releases. If they said "look at our cool new router", one could overlook obvious marketing BS like comparing to the T640 instead of the T1600. But claiming to "revolutionize" the Internet while being afraid to compare yourself to your chief competitor's flagship product is just pathetic. -- TTFN, patrick From williams.bruce at gmail.com Tue Mar 9 18:08:33 2010 From: williams.bruce at gmail.com (Bruce Williams) Date: Tue, 9 Mar 2010 16:08:33 -0800 Subject: CRS-3 In-Reply-To: <001701cabfc8$d913fa50$8b3beef0$@com> References: <001701cabfc8$d913fa50$8b3beef0$@com> Message-ID: <775e001a1003091608hf9482ady90044289c76aaa3d@mail.gmail.com> > It's called doing the "wall street dance". Their stock price jumped 3% > yesterday in anticipation of the "big" announcement. Hype is hype, and > people still remember the magic of the dotcom bubble. "ZOMG! They increased > the size of the tubez! BUY! BUY!" > > [full disclosure: I own stock in Cisco] > > Tom Walsh > Express Web Systems, Inc. > > > Actually it is called "defining a market". Cisco is doing for the small innovative companies something they could not do for themselves. Want to bet the "Wall St. Industry Experts" discover the "play" waiting to happen in some of these companies next and some money comes their way? Bruce > -- ?Discovering...discovering...we will never cease discovering... and the end of all our discovering will be to return to the place where we began and to know it for the first time.? -T.S. Eliot From khuon at neebu.net Tue Mar 9 18:10:26 2010 From: khuon at neebu.net (Jake Khuon) Date: Tue, 09 Mar 2010 16:10:26 -0800 Subject: CRS-3 In-Reply-To: <3E7DF632-ADE8-4647-BF35-C0F6EF61C4A5@ianai.net> References: <1268166980.9876.85.camel@localhost> <1268173879.9876.90.camel@localhost> <3E7DF632-ADE8-4647-BF35-C0F6EF61C4A5@ianai.net> Message-ID: <1268179826.9876.113.camel@localhost> On Tue, 2010-03-09 at 18:45 -0500, Patrick W. Gilmore wrote: > Sent from my iPhone, please excuse any errors. > > On Mar 9, 2010, at 17:31, Jake Khuon wrote: > > On Tue, 2010-03-09 at 17:02 -0500, Patrick W. Gilmore wrote: > >> On Mar 9, 2010, at 3:36 PM, Jake Khuon wrote: > >>> On Tue, 2010-03-09 at 15:29 -0500, Patrick W. Gilmore wrote: > >>> > >>>> The only "wow" here is "wow, why did cisco hype how far behind they > >>>> are?" > >>> > >>> Because in some organisations, the only vendor that matters is > >> Cisco. > >> > >> Then why bother hyping at all? > >> > >> Anyone who needs even a significant fraction of 322 Tbps is not going > >> to ignore competitors. > > > > Come now. You know the answer to that. While technically true, by > > that > > logic, Cisco should never perform any press releases. > > First, this wasn't a press release, this was an event they were hyping > for quite a while. Second, doing a press release is fine, but even > the most aggressive companies have a modicum of truth in their releases. > > If they said "look at our cool new router", one could overlook obvious > marketing BS like comparing to the T640 instead of the T1600. But > claiming to "revolutionize" the Internet while being afraid to compare > yourself to your chief competitor's flagship product is just pathetic. Again, that may be true but I think you give marketing in general more credit for credibility than actually exists. Pathetic or not, it happens and some people don't actually see it for the blatant undertruth that it is... especially those who have been blinded by the Cisco "light". We in this industry often forget that not everyone looks for dotted T's and crossed I's when it comes to detail. For whatever reason, most people don't directly challenge the spindoctors. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From williams.bruce at gmail.com Tue Mar 9 18:37:46 2010 From: williams.bruce at gmail.com (Bruce Williams) Date: Tue, 9 Mar 2010 16:37:46 -0800 Subject: CRS-3 In-Reply-To: <001701cabfc8$d913fa50$8b3beef0$@com> References: <001701cabfc8$d913fa50$8b3beef0$@com> Message-ID: <775e001a1003091637y5088886bk2442a07e45288772@mail.gmail.com> On Tue, Mar 9, 2010 at 12:41 PM, Express Web Systems wrote: >> Wow what? >> >> Is there anything in the CRS-3 that competitors are not shipping _today_? >> >> If you look at some startups, they are doing 4-5 times as many Gbps per > slot, >> and pre-release equipment is in use in some networks already. >> >> The only "wow" here is "wow, why did cisco hype how far behind they are?" >> > > It's called doing the "wall street dance". Their stock price jumped 3% > yesterday in anticipation of the "big" announcement. Hype is hype, and > people still remember the magic of the dotcom bubble. "ZOMG! They increased > the size of the tubez! BUY! BUY!" > > [full disclosure: I own stock in Cisco] > > Tom Walsh > Express Web Systems, Inc. > > > Actually it is called "defining a market". Cisco is doing for the small innovative companies something they could not do for themselves. Want to bet the "Wall St. Industry Experts" discover the "play" waiting to happen in some of these companies next and some money comes their way? Bruce -- ?Discovering...discovering...we will never cease discovering... and the end of all our discovering will be to return to the place where we began and to know it for the first time.? -T.S. Eliot From tims at donet.com Tue Mar 9 19:00:45 2010 From: tims at donet.com (Tim Sanderson) Date: Tue, 9 Mar 2010 20:00:45 -0500 Subject: T1 aggregation and data center gateways Message-ID: <175DA64769AE0F4498D813EDBFB44949C144DAF0E7@intexch07.internal.donet.com> Currently have T1 aggregation on some Cisco 7206VXR routers. Core switches and data center gateways on a couple of Cisco 6509's. Looking for a model that could collapse both functions into just two devices, one being for hardware redundancy. Any recommendations on a good L3 switch that is also a good T1 aggregation device? Anyone have any experience with the newer Cisco stuff like the ASR 1000/7600/CRS-1? Tim Sanderson ________________________________ THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately. Thank you. From abalashov at evaristesys.com Tue Mar 9 19:04:52 2010 From: abalashov at evaristesys.com (Alex Balashov) Date: Tue, 09 Mar 2010 20:04:52 -0500 Subject: T1 aggregation and data center gateways In-Reply-To: <175DA64769AE0F4498D813EDBFB44949C144DAF0E7@intexch07.internal.donet.com> References: <175DA64769AE0F4498D813EDBFB44949C144DAF0E7@intexch07.internal.donet.com> Message-ID: <4B96F034.30202@evaristesys.com> On 03/09/2010 08:00 PM, Tim Sanderson wrote: > Currently have T1 aggregation on some Cisco 7206VXR routers. Core switches > and data center gateways on a couple of Cisco 6509's. Looking for a model > that could collapse both functions into just two devices, one being for > hardware redundancy. Any recommendations on a good L3 switch that is > also a good T1 aggregation device? Anyone have any experience with > the newer Cisco stuff like the ASR 1000/7600/CRS-1? Forgive the dumb question, but what's wrong with using a 6509 as a T1 aggregation device? Port density not cost-effective? I've seen it used that way on a number of occasions with cheap M13 muxes and DS3 interfaces. -- Alex Balashov - Principal Evariste Systems LLC Tel : +1 678-954-0670 Direct : +1 678-954-0671 Web : http://www.evaristesys.com/ From gbonser at seven.com Tue Mar 9 19:04:49 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 9 Mar 2010 17:04:49 -0800 Subject: CRS-3 In-Reply-To: <9e246b4d1003091339s44b0f034g904cd894b44867e9@mail.gmail.com> References: <9e246b4d1003091339s44b0f034g904cd894b44867e9@mail.gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6488@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Tim Durack > Sent: Tuesday, March 09, 2010 1:39 PM > To: Brian Feeny > > Subject: Re: CRS-3 > > "This intelligence also includes carrier-grade IPv6 (CGv6)" > > Can't wait to find out what this is. "accelerating the delivery of compelling new experiences" Sounds like someone created a new "web economy bullshit generator". And just how will I know when I have been delivered a compelling new experience? I was at least expecting something like "envisioneer out-of-the-box communities" or maybe "recontextualize customized experiences" or something. From john-nanog at johnpeach.com Tue Mar 9 19:20:03 2010 From: john-nanog at johnpeach.com (John Peach) Date: Tue, 09 Mar 2010 20:20:03 -0500 Subject: T1 aggregation and data center gateways In-Reply-To: <175DA64769AE0F4498D813EDBFB44949C144DAF0E7@intexch07.internal.donet.com> References: <175DA64769AE0F4498D813EDBFB44949C144DAF0E7@intexch07.internal.donet.com> Message-ID: <20100309202003.57f0d7de@milhouse.peachfamily.net> On Tue, 9 Mar 2010 20:00:45 -0500 Tim Sanderson wrote: [snip] > > ________________________________ > THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately. Thank you. Things get sillier by the day. A sig of more than 4 lines is too long, let alone all this completely unenforceable BS. If anyone sends me an email by mistake it will be published for all to see. -- John From mksmith at adhost.com Tue Mar 9 19:23:34 2010 From: mksmith at adhost.com (Michael K. Smith) Date: Tue, 09 Mar 2010 17:23:34 -0800 Subject: T1 aggregation and data center gateways In-Reply-To: <175DA64769AE0F4498D813EDBFB44949C144DAF0E7@intexch07.internal.donet.com> Message-ID: Hi Tim: On 3/9/10 5:00 PM, "Tim Sanderson" wrote: > Currently have T1 aggregation on some Cisco 7206VXR routers. Core switches and > data center gateways on a couple of Cisco 6509's. Looking for a model that > could collapse both functions into just two devices, one being for hardware > redundancy. Any recommendations on a good L3 switch that is also a good T1 > aggregation device? Anyone have any experience with the newer Cisco stuff like > the ASR 1000/7600/CRS-1? > > Tim Sanderson You might want to post this over to cisco-nsp because there are lots of options depending upon your configuration. If you're looking at port density it seems to me you would want your router/switch to have the biggest mux ports possible. So, you could look at OC-3 or even higher in the router platforms. You can get up to an OC-12 channelized, but it all depends upon your configuration. Regards, Mike From LarrySheldon at cox.net Tue Mar 9 19:38:50 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 09 Mar 2010 19:38:50 -0600 Subject: T1 aggregation and data center gateways In-Reply-To: <20100309202003.57f0d7de@milhouse.peachfamily.net> References: <175DA64769AE0F4498D813EDBFB44949C144DAF0E7@intexch07.internal.donet.com> <20100309202003.57f0d7de@milhouse.peachfamily.net> Message-ID: <4B96F82A.30400@cox.net> On 3/9/2010 7:20 PM, John Peach wrote: > On Tue, 9 Mar 2010 20:00:45 -0500 > Tim Sanderson wrote: > > [snip] >> >> ________________________________ >> THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately. Thank you. > > Things get sillier by the day. A sig of more than 4 lines is too long, > let alone all this completely unenforceable BS. If anyone sends me an > email by mistake it will be published for all to see. Whee! Been almost a week since somebody has tripped that one. Why not tell the lawyer that told the CIO to put that on every outgoing message. I'll tell you why not. It will do less good than whining about it here. Again. -- "Government big enough to supply everything you need is big enough to take everything you have."Remember: The Ark was built by amateurs, the Titanic by professionals.Requiescas in pace o emailEx turpi causa non oritur actioEppure si rinfrescaICBM Targeting Information:http://tinyurl.com/4sqczshttp://tinyurl.com/7tp8ml From Sam.Crooks at experian.com Tue Mar 9 22:47:46 2010 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Tue, 9 Mar 2010 22:47:46 -0600 Subject: CRS-3 In-Reply-To: References: Message-ID: "Spend the GDP of a small nation on a single box!" > -----Original Message----- > From: Brian Feeny [mailto:bfeeny at mac.com] > Sent: Tuesday, March 09, 2010 1:51 PM > To: nanog at nanog.org list > Subject: CRS-3 > > > So who is going to be the first to deploy these? > > http://newsroom.cisco.com/dlls/2010/prod_030910.html > > > - Download the entire Library of Congress in just over 1 second > - Stream every motion picture ever created in less than four minutes > > If nothing else you gotta love the Cisco Marketing machine! > > > > Brian From swmike at swm.pp.se Tue Mar 9 23:11:06 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Mar 2010 06:11:06 +0100 (CET) Subject: CRS-3 In-Reply-To: <63ac96a51003091430g15e73d2co2c8ee0e6e1a10e0a@mail.gmail.com> References: <617164067-1268166137-cardhu_decombobulator_blackberry.rim.net-1066376024-@bda006.bisx.prod.on.blackberry> <1268167392.9876.88.camel@localhost> <63ac96a51003091430g15e73d2co2c8ee0e6e1a10e0a@mail.gmail.com> Message-ID: On Tue, 9 Mar 2010, Matthew Petach wrote: > /me sits back patiently and waits for CRS-5, then...[1] CRS-3 is ~3 times as fast as CRS-1, so I guess the next iteration will be CRS-12 and then CRS-36, CRS-108 (perhaps CRS-100 just to make it easy). :P -- Mikael Abrahamsson email: swmike at swm.pp.se From rubensk at gmail.com Tue Mar 9 23:19:13 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 10 Mar 2010 02:19:13 -0300 Subject: CRS-3 In-Reply-To: References: Message-ID: <6bb5f5b11003092119h6822c5f8ob655ff0f15ddb8c5@mail.gmail.com> On Tue, Mar 9, 2010 at 4:51 PM, Brian Feeny wrote: > > So who is going to be the first to deploy these? > > http://newsroom.cisco.com/dlls/2010/prod_030910.html > > > - Download the entire Library of Congress in just over 1 second > - Stream every motion picture ever created in less than four minutes > > If nothing else you gotta love the Cisco Marketing machine! And the amazing thing is that the target audience of the campaign has nothing to do with the product. The very few carriers that can buy CRS-x already knew about the product and preliminar specs; the real message is to the consumer markets: there is more bandwidth out there. Don't be cheap: use, prefer and create applications requiring more bandwidth. If the market grows, Cisco grows with it, selling products across the board (newer Linksys APs, newer CPEs, newer PEs, newer core routers). The real enemy here for Cisco is not vendor-J,vendor-AL or vendor-H; it's a growing culture that speaks txtspk instead of plain language and would be happy with Telex bandwidths. That hurts business; HD video and HQ audio sell a lot of stuff, and that's the culture Cisco hopes will prevail. Rubens From mark at edgewire.sg Tue Mar 9 23:33:03 2010 From: mark at edgewire.sg (Mark) Date: Wed, 10 Mar 2010 13:33:03 +0800 Subject: CRS-3 In-Reply-To: <6bb5f5b11003092119h6822c5f8ob655ff0f15ddb8c5@mail.gmail.com> References: <6bb5f5b11003092119h6822c5f8ob655ff0f15ddb8c5@mail.gmail.com> Message-ID: <4C69CE11-9BBE-466E-A278-44E70A9E9E7E@edgewire.sg> I fail to see how using linksys's range of products is going to be comparable to enterprise grade cisco gear. Well, your average consumer wouldn't be involved with a CRS or for that matter, anything that remotely resembles a CRS. Not sure why you'd pull the consumer market into this marketing hype that cisco is going on about. :P On 10-Mar-2010, at 1:19 PM, Rubens Kuhl wrote: > On Tue, Mar 9, 2010 at 4:51 PM, Brian Feeny wrote: >> >> So who is going to be the first to deploy these? >> >> http://newsroom.cisco.com/dlls/2010/prod_030910.html >> >> >> - Download the entire Library of Congress in just over 1 second >> - Stream every motion picture ever created in less than four minutes >> >> If nothing else you gotta love the Cisco Marketing machine! > > And the amazing thing is that the target audience of the campaign has > nothing to do with the product. The very few carriers that can buy > CRS-x already knew about the product and preliminar specs; the real > message is to the consumer markets: there is more bandwidth out there. > Don't be cheap: use, prefer and create applications requiring more > bandwidth. If the market grows, Cisco grows with it, selling products > across the board (newer Linksys APs, newer CPEs, newer PEs, newer core > routers). > > The real enemy here for Cisco is not vendor-J,vendor-AL or vendor-H; > it's a growing culture that speaks txtspk instead of plain language > and would be happy with Telex bandwidths. That hurts business; HD > video and HQ audio sell a lot of stuff, and that's the culture Cisco > hopes will prevail. > > > Rubens > From nanog at enger.us Wed Mar 10 00:01:06 2010 From: nanog at enger.us (Robert Enger - NANOG) Date: Tue, 09 Mar 2010 22:01:06 -0800 Subject: CRS-3 In-Reply-To: <6bb5f5b11003092119h6822c5f8ob655ff0f15ddb8c5@mail.gmail.com> References: <6bb5f5b11003092119h6822c5f8ob655ff0f15ddb8c5@mail.gmail.com> Message-ID: <4B9735A2.2040308@enger.us> On 3/9/2010 9:19 PM, Rubens Kuhl wrote: > On Tue, Mar 9, 2010 at 4:51 PM, Brian Feeny wrote: >> So who is going to be the first to deploy these? >> >> http://newsroom.cisco.com/dlls/2010/prod_030910.html >> >> >> - Download the entire Library of Congress in just over 1 second >> - Stream every motion picture ever created in less than four minutes >> >> If nothing else you gotta love the Cisco Marketing machine! > And the amazing thing is that the target audience of the campaign has > nothing to do with the product. The very few carriers that can buy > CRS-x already knew about the product and preliminar specs; the real > message is to the consumer markets: there is more bandwidth out there. > Don't be cheap: use, prefer and create applications requiring more > bandwidth. If the market grows, Cisco grows with it, selling products > across the board (newer Linksys APs, newer CPEs, newer PEs, newer core > routers). > > The real enemy here for Cisco is not vendor-J,vendor-AL or vendor-H; > it's a growing culture that speaks txtspk instead of plain language > and would be happy with Telex bandwidths. That hurts business; HD > video and HQ audio sell a lot of stuff, and that's the culture Cisco > hopes will prevail. > > > Rubens > Let's hope for deep-color progressive, DCI/Cinema4k, or better yet Super Hi-Vision. We might as well enjoy good video quality. From drc at virtualized.org Wed Mar 10 00:42:25 2010 From: drc at virtualized.org (David Conrad) Date: Tue, 9 Mar 2010 22:42:25 -0800 Subject: CRS-3 In-Reply-To: References: Message-ID: On Mar 9, 2010, at 8:47 PM, Crooks, Sam wrote: > "Spend the GDP of a small nation on a single box!" I'll admit to being too lazy to dig through and/or translate the marketspeak. Anyone have any idea how much a fully configured CRS-3 would cost? Or how much power it would consume? Or how much heat it would generate? Or perhaps more interestingly, given the way things seem to be going, how many (tens of?) millions of RIB entries it'll allow? Just curious... Thanks, -drc From fergdawgster at gmail.com Wed Mar 10 00:55:17 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 9 Mar 2010 22:55:17 -0800 Subject: CRS-3 In-Reply-To: References: Message-ID: <6cd462c01003092255s7f4c6a9bm4b452e8527991811@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Mar 9, 2010 at 10:42 PM, David Conrad wrote: > On Mar 9, 2010, at 8:47 PM, Crooks, Sam wrote: >> "Spend the GDP of a small nation on a single box!" > > I'll admit to being too lazy to dig through and/or translate the > marketspeak. > > Anyone have any idea how much a fully configured CRS-3 would cost? Or > how much power it would consume? Or how much heat it would generate? > > Or perhaps more interestingly, given the way things seem to be going, how > many (tens of?) millions of RIB entries it'll allow? > > Just curious... > Admittedly, my information on these topics comes from NPR these days. :-) They said it costs ~US$90k, and that AT&T was in trails. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLl0JOq1pz9mNUZTMRAkPiAKD+LCW/Z27zwSZgI8otXNNetGN8aQCg8i4J M4QZTSQ2W9oV9JYdt7eaMxM= =S3te -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From arjan.van.der.oest at worldmax.nl Wed Mar 10 00:58:47 2010 From: arjan.van.der.oest at worldmax.nl (Arjan van der Oest) Date: Wed, 10 Mar 2010 07:58:47 +0100 Subject: CRS-3 References: <1268166980.9876.85.camel@localhost> Message-ID: Cisco did 100GE before, based upon the 802.3ba: http://www.10gea.org/100-ge-router-cisco-comcast.htm The 'wow' factor in this is news might be that these new linecards are nonblocking and will eventually support the final standard without hardware changes. Arjan -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Tue 3/9/2010 11:02 PM To: NANOG list Subject: Re: CRS-3 On Mar 9, 2010, at 3:36 PM, Jake Khuon wrote: > On Tue, 2010-03-09 at 15:29 -0500, Patrick W. Gilmore wrote: > >> The only "wow" here is "wow, why did cisco hype how far behind they >> are?" > > Because in some organisations, the only vendor that matters is Cisco. Then why bother hyping at all? Anyone who needs even a significant fraction of 322 Tbps is not going to ignore competitors. -- TTFN, patrick Internet communications are not secure; therefore, the integrity of this e-mail cannot be guaranteed following transmission on the Internet. This e-mail may contain confidential information. If you have received this e-mail in error, please notify the sender and erase this e-mail. Use of this e-mail by any person other than the addressee is strictly forbidden. This e-mail is believed to be free of any virus that might adversely affect the addressee's computer system; however, no responsibility is accepted for any loss or damage arising in any way from its use. All the preceding disclaimers also apply to any possible attachments to this e-mail. From drc at virtualized.org Wed Mar 10 01:06:39 2010 From: drc at virtualized.org (David Conrad) Date: Tue, 9 Mar 2010 23:06:39 -0800 Subject: CRS-3 In-Reply-To: <6cd462c01003092255s7f4c6a9bm4b452e8527991811@mail.gmail.com> References: <6cd462c01003092255s7f4c6a9bm4b452e8527991811@mail.gmail.com> Message-ID: <30AEEC40-2D84-404F-BFB8-A716E4B764B3@virtualized.org> On Mar 9, 2010, at 10:55 PM, Paul Ferguson wrote: >> Anyone have any idea how much a fully configured CRS-3 would cost? > Admittedly, my information on these topics comes from NPR these days. :-) > > They said it costs ~US$90k, and that AT&T was in trails. Somehow, I'm skeptical (not of the trials, but $90k for a fully configured CRS-3), but if it was on NPR it must be true... :-) Regards, -drc From swmike at swm.pp.se Wed Mar 10 01:15:30 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Mar 2010 08:15:30 +0100 (CET) Subject: CRS-3 In-Reply-To: References: Message-ID: On Tue, 9 Mar 2010, David Conrad wrote: > Anyone have any idea how much a fully configured CRS-3 would cost? Or > how much power it would consume? Or how much heat it would generate? Power is fairly easy, you need somewhere in the order of 14kW per rack (at least you need to provision that much), and at 72 racks that's ~1 MW. I'd imagine it'd be hard to get below an average cost of 50kUSD per slot for MSC and PLIM and optics, so at 64*16 slots that's at least ~50 milllion USD. > Or perhaps more interestingly, given the way things seem to be going, > how many (tens of?) millions of RIB entries it'll allow? Probably around there, yes, 10M RIB, 2-3M FIB. -- Mikael Abrahamsson email: swmike at swm.pp.se From ghicks at hicks-net.net Wed Mar 10 01:31:51 2010 From: ghicks at hicks-net.net (Gregory Hicks) Date: Tue, 9 Mar 2010 23:31:51 -0800 (PST) Subject: CRS-3 Message-ID: <201003100731.o2A7VoEt009554@metis.hicks-net.net> > Subject: Re: CRS-3 > From: David Conrad > Date: Tue, 9 Mar 2010 23:06:39 -0800 > > On Mar 9, 2010, at 10:55 PM, Paul Ferguson wrote: > >> Anyone have any idea how much a fully configured CRS-3 would cost? > > Admittedly, my information on these topics comes from NPR these days. :-) > > > > They said it costs ~US$90k, and that AT&T was in trails. > > Somehow, I'm skeptical (not of the trials, but $90k for a fully > configured CRS-3), but if it was on NPR it must be true... :-) The press release at http://newsroom.cisco.com/dlls/2010/prod_030910.html states that the pricing for the CRS-3 STARTS AT $90K... From jamel at cin.ufpe.br Wed Mar 10 04:42:00 2010 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Wed, 10 Mar 2010 07:42:00 -0300 Subject: Policies from experience Message-ID: Hi everyone, I am curious regarding the use of "policies", rules or goals to manage a network at the three levels: business, traffic engineering and routing. I have these questions: 1) What examples of policies could be enforced at each level? (the simplest case being that of routing policies using EGP that I can think of)? 2) Could there be a clear cut in terms of policies between these three levels: business, routing and TE ? 3) anyone using the Routing Policy Specification Language (RPSL) ? Thank you for taking the time. Djamel Sadok From lists at quux.de Wed Mar 10 04:55:35 2010 From: lists at quux.de (Jens Link) Date: Wed, 10 Mar 2010 11:55:35 +0100 Subject: IP4 Space In-Reply-To: <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> (Owen DeLong's message of "Fri, 5 Mar 2010 14:15:13 +0800") References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> Message-ID: <87iq94o388.fsf@laphroiag.quux.de> Owen DeLong writes: >> denial >> anger >> bargaining >> depression > acceptance <--- My dual-stacked network and I are here. So am I. But most IT people I talk to are still at the denial phase. And there is not much one can do about it. Jens, 566 days to go -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From gawul00+nanog at gmail.com Wed Mar 10 07:06:52 2010 From: gawul00+nanog at gmail.com (Andy Koch) Date: Wed, 10 Mar 2010 07:06:52 -0600 Subject: IP4 Space In-Reply-To: <87iq94o388.fsf@laphroiag.quux.de> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> Message-ID: On Wed, Mar 10, 2010 at 04:55, Jens Link wrote: > Owen DeLong writes: > >>> denial >>> anger >>> bargaining >>> depression >> acceptance ? ?<--- My dual-stacked network and I are here. > > So am I. But most IT people I talk to are still at the denial phase. And > there is not much one can do about it. > > Jens, 566 days to go > -- > ------------------------------------------------------------------------- > | Foelderichstr. 40 ?| 13595 Berlin, Germany | +49-151-18721264 ? ? ? ? | > | http://www.quux.de | http://blog.quux.de ? | jabber: jenslink at guug.de | > ------------------------------------------------------------------------- > > Or 374 days on the competing prediction http://ipv4depletion.com/?page_id=4 From swm at emanon.com Wed Mar 10 07:40:49 2010 From: swm at emanon.com (Scott Morris) Date: Wed, 10 Mar 2010 08:40:49 -0500 Subject: T1 aggregation and data center gateways In-Reply-To: <20100309202003.57f0d7de@milhouse.peachfamily.net> References: <175DA64769AE0F4498D813EDBFB44949C144DAF0E7@intexch07.internal.donet.com> <20100309202003.57f0d7de@milhouse.peachfamily.net> Message-ID: <4B97A161.2030606@emanon.com> Isn't that just CYA? Thank the lawyers and "corporate compliance offices" and professional whiners. Scott John Peach wrote: On Tue, 9 Mar 2010 20:00:45 -0500 Tim Sanderson [1] wrote: [snip] ________________________________ THIS MESSAGE IS INTENDED ONLY FOR PERSONAL AND CONFIDENTIAL USE OF THE INDIVIDUA L OR ENTITY TO WHOM IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEG ED, CONFIDENTIAL, AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent respons ible for delivering the message to the intended recipient, you are hereby notifi ed that you have received this message in error and that any review, disseminati on, distribution, or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by e-mail or telephone, and delete the original message immediately. Thank you. Things get sillier by the day. A sig of more than 4 lines is too long, let alone all this completely unenforceable BS. If anyone sends me an email by mistake it will be published for all to see. References 1. mailto:tims at donet.com From tim at pelican.org Wed Mar 10 08:09:18 2010 From: tim at pelican.org (Tim Franklin) Date: Wed, 10 Mar 2010 14:09:18 +0000 (GMT) Subject: T1 aggregation and data center gateways In-Reply-To: <13806908.01268229980591.JavaMail.root@jennyfur.pelican.org> Message-ID: <31489342.21268230158481.JavaMail.root@jennyfur.pelican.org> > Isn't that just CYA? Thank the lawyers and "corporate compliance > offices" and professional whiners. The obvious answer is that if your corporate email policy makes you look like an idiot, post to mailing lists from a personal email address that doesn't make you look like an idiot. This also spares the list from "out-of-office" messages from Exchange servers too stupid to refrain from sending such messages to mailing lists. Regards, Tim. From a.harrowell at gmail.com Wed Mar 10 08:14:52 2010 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Wed, 10 Mar 2010 14:14:52 +0000 Subject: T1 aggregation and data center gateways In-Reply-To: <31489342.21268230158481.JavaMail.root@jennyfur.pelican.org> References: <31489342.21268230158481.JavaMail.root@jennyfur.pelican.org> Message-ID: <201003101415.01646.a.harrowell@gmail.com> On Wednesday 10 March 2010 14:09:18 Tim Franklin wrote: > > Isn't that just CYA? Thank the lawyers and "corporate compliance > > offices" and professional whiners. > > The obvious answer is that if your corporate email policy makes you look > like an idiot, post to mailing lists from a personal email address that > doesn't make you look like an idiot. > > This also spares the list from "out-of-office" messages from Exchange > servers too stupid to refrain from sending such messages to mailing lists. > I think I'll leave this to my new sig. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From jbayles at readytechs.com Wed Mar 10 08:48:27 2010 From: jbayles at readytechs.com (Jonathan Bayles) Date: Wed, 10 Mar 2010 09:48:27 -0500 Subject: Cisco XR 12000 Series Router demonstration has been delayed... Message-ID: <386FCF83D8086E4A89655E41CD3B53D359DF357B02@rtexch01> The issue occurred during preventative maintenance of one of our data centers when a human error caused an electrical overload on the systems. This caused Cisco.com and other applications to go down. Because of the severity of the overload, the redundancy measures in some of the applications and power systems were impacted as well, though the system did shut down as designed to protect the people and the equipment. As a result, no data were lost and no one was injured. Cisco has plans already in process to add additional redundancies to increase the resilience of these systems. From owen at delong.com Wed Mar 10 10:12:51 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Mar 2010 08:12:51 -0800 Subject: IP4 Space In-Reply-To: <87iq94o388.fsf@laphroiag.quux.de> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> Message-ID: On Mar 10, 2010, at 2:55 AM, Jens Link wrote: > Owen DeLong writes: > >>> denial >>> anger >>> bargaining >>> depression >> acceptance <--- My dual-stacked network and I are here. > > So am I. But most IT people I talk to are still at the denial phase. And True > there is not much one can do about it. > I'm not convinced of this, however. I spend much of my time talking to groups of people about this. I have managed to get several members of such groups from denial to bargaining and sometimes eve depression in a single session. On rare occasion, acceptance even starts to set in. I think it is getting better and continuing to talk about it will help. Owen From rsnyder at toontown.erial.nj.us Wed Mar 10 10:30:10 2010 From: rsnyder at toontown.erial.nj.us (Bob Snyder) Date: Wed, 10 Mar 2010 11:30:10 -0500 Subject: CRS-3 In-Reply-To: <201003100731.o2A7VoEt009554@metis.hicks-net.net> References: <201003100731.o2A7VoEt009554@metis.hicks-net.net> Message-ID: <6edfd6c21003100830r227652d1md129f5cf23b70fc1@mail.gmail.com> On Wed, Mar 10, 2010 at 2:31 AM, Gregory Hicks wrote: > The press release at > http://newsroom.cisco.com/dlls/2010/prod_030910.html states that the > pricing for the CRS-3 STARTS AT $90K... Is that the cost for a nameplate you can stick on an empty rack with dark glass so you can fool people visiting your datacenter? I've put together BoMs for the CRS-1, and the pricing was at least an order of magnitude higher. Linecards are interesting. We get a 100Gb card, we get a linerate 14-port 10Gb card, but apparently there's still only a single port OC-768 40Gb card. Bob From rhuizinga at upcbroadband.com Wed Mar 10 10:39:24 2010 From: rhuizinga at upcbroadband.com (Huizinga, Rene) Date: Wed, 10 Mar 2010 17:39:24 +0100 Subject: CRS-3 In-Reply-To: <6edfd6c21003100830r227652d1md129f5cf23b70fc1@mail.gmail.com> References: <201003100731.o2A7VoEt009554@metis.hicks-net.net> <6edfd6c21003100830r227652d1md129f5cf23b70fc1@mail.gmail.com> Message-ID: <3B7DF58B7E6F3A4D80E1CEC35686B0E340937CD46D@AMS2PMS3001.upcit.ds.upc.biz> Cisco and linerate...if it would be a Juniper I could say OK, on a Cisco, first see then believe. Also, seeing CRS-1's, is the '3' in CRS-3 the multiplier or magnitude of problems to be expected compared to its 'little' buggy sister.. ? :) -----Original Message----- From: Bob Snyder [mailto:rsnyder at toontown.erial.nj.us] Sent: Wednesday, 10 March, 2010 17:30 To: nanog at nanog.org Subject: Re: CRS-3 On Wed, Mar 10, 2010 at 2:31 AM, Gregory Hicks wrote: > The press release at > http://newsroom.cisco.com/dlls/2010/prod_030910.html states that the > pricing for the CRS-3 STARTS AT $90K... Is that the cost for a nameplate you can stick on an empty rack with dark glass so you can fool people visiting your datacenter? I've put together BoMs for the CRS-1, and the pricing was at least an order of magnitude higher. Linecards are interesting. We get a 100Gb card, we get a linerate 14-port 10Gb card, but apparently there's still only a single port OC-768 40Gb card. Bob From giulianocm at uol.com.br Wed Mar 10 10:42:07 2010 From: giulianocm at uol.com.br (GIULIANO (UOL)) Date: Wed, 10 Mar 2010 13:42:07 -0300 Subject: CRS-3 x T1600 In-Reply-To: <6edfd6c21003100830r227652d1md129f5cf23b70fc1@mail.gmail.com> References: <201003100731.o2A7VoEt009554@metis.hicks-net.net> <6edfd6c21003100830r227652d1md129f5cf23b70fc1@mail.gmail.com> Message-ID: <4B97CBDF.6070605@uol.com.br> JUNIPER Networks did a press note about the new T-1600 components: http://www.juniper.net/us/en/company/press-center/press-releases/2010/pr_2010_02_04-08_30.html And now CISCO with the new components for the CRS-1 ... to increase it to "new" CRS-3. Both companies looks like want to reach 4 Tbps capacity with their CORE Routers. I think JUNIPER have been tested 100 Gbps ethernet line card for so long. http://www.juniper.net/us/en/company/press-center/press-releases/2009/pr_2009_06_08-09_00.html JUNIPER has talked about 5 Watts/Gigabit. CISCO said something about 3 Watts/Gigabit. Big and good fight. Best for all of us. From giulianocm at uol.com.br Wed Mar 10 10:44:33 2010 From: giulianocm at uol.com.br (GIULIANO (UOL)) Date: Wed, 10 Mar 2010 13:44:33 -0300 Subject: Res: CRS-3 x T1600 In-Reply-To: <4B97CBDF.6070605@uol.com.br> References: <201003100731.o2A7VoEt009554@metis.hicks-net.net> <6edfd6c21003100830r227652d1md129f5cf23b70fc1@mail.gmail.com> <4B97CBDF.6070605@uol.com.br> Message-ID: <4B97CC71.2000006@uol.com.br> JUNIPER Networks did a press note about the new T-1600 components: http://www.juniper.net/us/en/company/press-center/press-releases/2010/pr_2010_02_04-08_30.html And now CISCO with the new components for the CRS-1 ... to increase it to "new" CRS-3. T1600 - 250 Gbps full duplex / slot CRS-3 - 120 Gbps full duplex / slot CISCO is MUCH better using marketing than JUNIPER : ) Both companies looks like want to reach 4 Tbps capacity with their CORE Routers. I think JUNIPER have been tested 100 Gbps ethernet line card for so long. http://www.juniper.net/us/en/company/press-center/press-releases/2009/pr_2009_06_08-09_00.html JUNIPER has talked about 5 Watts/Gigabit. CISCO said something about 3 Watts/Gigabit. Big and good fight. Best for all of us. From james at freedomnet.co.nz Wed Mar 10 12:48:41 2010 From: james at freedomnet.co.nz (James Jones) Date: Wed, 10 Mar 2010 13:48:41 -0500 Subject: MPLS VLAN service Message-ID: <4B97E989.1080802@freedomnet.co.nz> I am looking for MPLS L2 VPN that will let give a ethernet port in springfield, MA @ one federal TO Wellington, NZ @ AT&T House. Can anyone here do this? Also can you provide me with some ball park pricing. Please reply off list. -- James Jones +1-413-667-9199 james at freedomnet.co.nz From w3yni1 at gmail.com Wed Mar 10 13:00:59 2010 From: w3yni1 at gmail.com (Charles Mills) Date: Wed, 10 Mar 2010 14:00:59 -0500 Subject: IPv6 enabled carriers? Message-ID: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> Does anyone have a list of carriers who are IPv6 capable today? I would assume this would be rolled out in larger cities first but anything outside of "testbed environments" and "trials" as in Comcast's recent announcement seems to be all that is available. I'm being tasked with coming up with an IPv6 migration plan for a data center. Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business and Qwest are capable as those are the typical ones I deal with. Thanks...Chuck From sethm at rollernet.us Wed Mar 10 13:18:35 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 10 Mar 2010 11:18:35 -0800 Subject: IPv6 enabled carriers? In-Reply-To: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> Message-ID: <4B97F08B.2070500@rollernet.us> On 3/10/10 11:00 AM, Charles Mills wrote: > Does anyone have a list of carriers who are IPv6 capable today? > > I would assume this would be rolled out in larger cities first but > anything outside of "testbed environments" and "trials" as in > Comcast's recent announcement seems to be all that is available. > > I'm being tasked with coming up with an IPv6 migration plan for a data center. > > Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business > and Qwest are capable as those are the typical ones I deal with. > Ones I have personal experience with: GLBX - yes SAVVIS - no VZB - yes, good luck ATT - "Beginning in 1Q2010 MIS will provide the ability to support IPv6 in a dual stack mode." When I disconnected my SAVVIS circuit in November 2009 I explicitly told them IPv6 was a deciding factor. Not all of Verizon's pops are IPv6 enabled, which may cause you trouble ordering it. It's put me in month 11 of trying to turn up a dual-stack circuit because they refuse to read the order and keep putting it in Sacramento (v4 only) when it needs to go to San Jose (dual-stack). Sprint wasn't on your list, but they are rolling out native IPv6 support on all of 1239. I've been using their 6175 testbed since 2005. ~Seth From jared at puck.nether.net Wed Mar 10 13:19:19 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 10 Mar 2010 14:19:19 -0500 Subject: IPv6 enabled carriers? In-Reply-To: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> Message-ID: <8E94771D-6DDF-4932-842D-21F57577ADBB@puck.nether.net> On Mar 10, 2010, at 2:00 PM, Charles Mills wrote: > Does anyone have a list of carriers who are IPv6 capable today? > > I would assume this would be rolled out in larger cities first but > anything outside of "testbed environments" and "trials" as in > Comcast's recent announcement seems to be all that is available. > > I'm being tasked with coming up with an IPv6 migration plan for a data center. > > Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business > and Qwest are capable as those are the typical ones I deal with. I believe most of the ones you've listed have service offerings in various stages of availability. You should be able to pop over here: telnet route-views.equinix.routeviews.org and take a look at the table easily enough to determine what providers have it enabled. Some have been operating with a different ASN for a number of years, including ATT and Sprint. If you're not feeding route-views, and are IPv6 enabled, please do. It helps those interested in routing research and is a valuable community asset. - Jared From cgrundemann at gmail.com Wed Mar 10 13:28:44 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 10 Mar 2010 12:28:44 -0700 Subject: IPv6 enabled carriers? In-Reply-To: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> Message-ID: <443de7ad1003101128u16be86bva3b4e28ad398731c@mail.gmail.com> SixXS maintains a list here: http://www.sixxs.net/faq/connectivity/?faq=ipv6transit. The IPv6 BGP weather map is a good resource: http://bgpmon.net/weathermap.php?inet=6 You can also use Geoff Huston's IPv6 CIDR report: http://www.cidr-report.org/v6/as2.0/ I should also note that my employer, tw telecom, offers IPv6 everywhere on 4323 - you have to ask for it, but it is available. ~Chris On Wed, Mar 10, 2010 at 12:00, Charles Mills wrote: > Does anyone have a list of carriers who are IPv6 capable today? > > I would assume this would be rolled out in larger cities first but > anything outside of "testbed environments" and "trials" as in > Comcast's recent announcement seems to be all that is available. > > I'm being tasked with coming up with an IPv6 migration plan for a data > center. > > Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business > and Qwest are capable as those are the typical ones I deal with. > > > Thanks...Chuck > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From gbonser at seven.com Wed Mar 10 13:32:51 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 10 Mar 2010 11:32:51 -0800 Subject: IPv6 enabled carriers? In-Reply-To: <4B97F08B.2070500@rollernet.us> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE64BF@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Seth Mattinen > Sent: Wednesday, March 10, 2010 11:19 AM > To: nanog at nanog.org > Subject: Re: IPv6 enabled carriers? > > > VZB - yes, good luck > > ... Not all of Verizon's pops are IPv6 > enabled, which may cause you trouble ordering it. > ~Seth Recent experience with VZB in a major central European city: VZB: we can tunnel 6 to you over 4 but the /48 we give you will probably change down the line once we roll out "real" v6. From swmike at swm.pp.se Wed Mar 10 13:47:51 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 10 Mar 2010 20:47:51 +0100 (CET) Subject: CRS-3 In-Reply-To: <6edfd6c21003100830r227652d1md129f5cf23b70fc1@mail.gmail.com> References: <201003100731.o2A7VoEt009554@metis.hicks-net.net> <6edfd6c21003100830r227652d1md129f5cf23b70fc1@mail.gmail.com> Message-ID: On Wed, 10 Mar 2010, Bob Snyder wrote: > Linecards are interesting. We get a 100Gb card, we get a linerate > 14-port 10Gb card, but apparently there's still only a single port > OC-768 40Gb card. There has been claims that volume for OC-768 is low so no major effort has been seen to reduce OC-768 MSA size, so apparently the parts needed for multiple OC-768 ports can't be physically fitted in one PLIM. -- Mikael Abrahamsson email: swmike at swm.pp.se From john at vanoppen.com Wed Mar 10 13:25:17 2010 From: john at vanoppen.com (John van Oppen) Date: Wed, 10 Mar 2010 11:25:17 -0800 Subject: IPv6 enabled carriers? References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <8E94771D-6DDF-4932-842D-21F57577ADBB@puck.nether.net> Message-ID: We have a dual-stack 10G link to XO here in Seattle so they are doing it as well... Savvis is not doing v6 yet either so far as I know, we are going to make that an issue at our next renewal. I am told that level3 is working on a full dual-stack roll-out currently and that it should be available "soon" and will replace the current tunneled options they have. Thanks, John van Oppen Spectrum Networks (AS11404) -----Original Message----- From: Jared Mauch [mailto:jared at puck.nether.net] Sent: Wednesday, March 10, 2010 11:19 AM To: Charles Mills Cc: NANOG list Subject: Re: IPv6 enabled carriers? On Mar 10, 2010, at 2:00 PM, Charles Mills wrote: > Does anyone have a list of carriers who are IPv6 capable today? > > I would assume this would be rolled out in larger cities first but > anything outside of "testbed environments" and "trials" as in > Comcast's recent announcement seems to be all that is available. > > I'm being tasked with coming up with an IPv6 migration plan for a data center. > > Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business > and Qwest are capable as those are the typical ones I deal with. I believe most of the ones you've listed have service offerings in various stages of availability. You should be able to pop over here: telnet route-views.equinix.routeviews.org and take a look at the table easily enough to determine what providers have it enabled. Some have been operating with a different ASN for a number of years, including ATT and Sprint. If you're not feeding route-views, and are IPv6 enabled, please do. It helps those interested in routing research and is a valuable community asset. - Jared From chris at uplogon.com Wed Mar 10 13:59:00 2010 From: chris at uplogon.com (Chris Gotstein) Date: Wed, 10 Mar 2010 13:59:00 -0600 Subject: IPv6 enabled carriers? In-Reply-To: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> Message-ID: <4B97FA04.8090105@uplogon.com> We are getting native IPv6 from HE and Qwest at this time. Qwest was doing a beta of IPv6 that we were (are) a part of. Not sure of they have ended the beta and rolled out to production. ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com On 3/10/2010 1:00 PM, Charles Mills wrote: > Does anyone have a list of carriers who are IPv6 capable today? > > I would assume this would be rolled out in larger cities first but > anything outside of "testbed environments" and "trials" as in > Comcast's recent announcement seems to be all that is available. > > I'm being tasked with coming up with an IPv6 migration plan for a data center. > > Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business > and Qwest are capable as those are the typical ones I deal with. > > > Thanks...Chuck > From m.hallgren at free.fr Wed Mar 10 14:07:45 2010 From: m.hallgren at free.fr (Michael Hallgren) Date: Wed, 10 Mar 2010 21:07:45 +0100 Subject: IPv6 enabled carriers? In-Reply-To: <4B97F08B.2070500@rollernet.us> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> Message-ID: <1268251665.5493.20.camel@home> Le mercredi 10 mars 2010 ? 11:18 -0800, Seth Mattinen a ?crit : > On 3/10/10 11:00 AM, Charles Mills wrote: > > Does anyone have a list of carriers who are IPv6 capable today? > > > > I would assume this would be rolled out in larger cities first but > > anything outside of "testbed environments" and "trials" as in > > Comcast's recent announcement seems to be all that is available. > > > > I'm being tasked with coming up with an IPv6 migration plan for a data center. > > > > Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business > > and Qwest are capable as those are the typical ones I deal with. > > > > Ones I have personal experience with: > > GLBX - yes > SAVVIS - no > VZB - yes, good luck > ATT - "Beginning in 1Q2010 MIS will provide the ability to support IPv6 > in a dual stack mode." > > When I disconnected my SAVVIS circuit in November 2009 I explicitly told > them IPv6 was a deciding factor. Not all of Verizon's pops are IPv6 > enabled, which may cause you trouble ordering it. It's put me in month > 11 of trying to turn up a dual-stack circuit because they refuse to read > the order and keep putting it in Sacramento (v4 only) when it needs to > go to San Jose (dual-stack). Sprint wasn't on your list, but they are > rolling out native IPv6 support on all of 1239. I've been using their > 6175 testbed since 2005. > + Tata AS6453, production network since quite some time now, dual stack. mh > ~Seth > -- michael hallgren, mh2198-ripe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From owen at delong.com Wed Mar 10 14:02:47 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Mar 2010 12:02:47 -0800 Subject: IPv6 enabled carriers? In-Reply-To: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> Message-ID: <4CFB43B1-31C1-4D8D-AB70-2FE38DB96F05@delong.com> On Mar 10, 2010, at 11:00 AM, Charles Mills wrote: > Does anyone have a list of carriers who are IPv6 capable today? > > I would assume this would be rolled out in larger cities first but > anything outside of "testbed environments" and "trials" as in > Comcast's recent announcement seems to be all that is available. > Check out http://www.getipv6.info there is some information there. Hurricane Electric has a full production dual-stack environment. > I'm being tasked with coming up with an IPv6 migration plan for a data center. > > Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business > and Qwest are capable as those are the typical ones I deal with. > To the best of my knowledge, each of those has varying degrees of IPv6 availability and none is "full production product" yet. My information could be old. Owen From michael.holstein at csuohio.edu Wed Mar 10 14:17:53 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 10 Mar 2010 15:17:53 -0500 Subject: ethernet to serial converters with ACLs Message-ID: <4B97FE71.8090700@csuohio.edu> Can anyone recommend a cheap Ethernet to Serial (RS232/422/485) converter with functionality like the Lantronix boxes .. except one that supports access lists (nothing complicated .. maybe a list of 5 approved hosts). I need a bunch of single port devices, not an access-server for a rack. I could build one out of a Pogoplug + USB/serial dongle .. (~$120 total) but would rather not re-invent the wheel. All the "secure" ones I see involve encrypting com port redirectors for the host PC .. I don't care about encrypting data in flight, I just want to restrict who can connect to the COM port on the other side of the IP device. It needs to work like the Lantronics ones do (take tcp/(port) and spit it out as rs232). Thanks, Michael Holstein Cleveland State University From routingbits at gmail.com Wed Mar 10 14:20:31 2010 From: routingbits at gmail.com (Routing Bits) Date: Wed, 10 Mar 2010 15:20:31 -0500 Subject: IPv6 enabled carriers? Message-ID: It looks like Comcast offers IPv6 today. Check the below link out to see if your data center is near any of their POP's. I believe Comcast's trials are for their Docsis products. http://www.comcast.com/dedicatedinternet/default.html From caleb.tennis at gmail.com Wed Mar 10 14:34:11 2010 From: caleb.tennis at gmail.com (Caleb Tennis) Date: Wed, 10 Mar 2010 15:34:11 -0500 Subject: ethernet to serial converters with ACLs In-Reply-To: <4B97FE71.8090700@csuohio.edu> References: <4B97FE71.8090700@csuohio.edu> Message-ID: On Mar 10, 2010, at 3:17 PM, Michael Holstein wrote: > Can anyone recommend a cheap Ethernet to Serial (RS232/422/485) > converter with functionality like the Lantronix boxes .. except one that > supports access lists (nothing complicated .. maybe a list of 5 approved > hosts). I need a bunch of single port devices, not an access-server for > a rack. We use SENA PS110 boxes ( http://www.sena.com/products/device_servers/hd_ps_x10.php ). They work very well, have various ACL features (dunno if it supports 5 named IP or not), and other configurables. Caleb From wallacerl at verizon.net Wed Mar 10 15:03:43 2010 From: wallacerl at verizon.net (Ralph Wallace) Date: Wed, 10 Mar 2010 16:03:43 -0500 Subject: NANOG Digest, Vol 26, Issue 50 In-Reply-To: References: Message-ID: <000901cac095$2adee030$809ca090$@net> >Message: 13 >Date: Wed, 10 Mar 2010 11:18:35 -0800 >From: Seth Mattinen >Subject: Re: IPv6 enabled carriers? >To: nanog at nanog.org >Message-ID: <4B97F08B.2070500 at rollernet.us> >Content-Type: text/plain; charset=UTF-8 >On 3/10/10 11:00 AM, Charles Mills wrote: >> Does anyone have a list of carriers who are IPv6 capable today? >> >> I would assume this would be rolled out in larger cities first but >> anything outside of "testbed environments" and "trials" as in >> Comcast's recent announcement seems to be all that is available. >> >> I'm being tasked with coming up with an IPv6 migration plan for a data center. >> >> Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business >> and Qwest are capable as those are the typical ones I deal with. >> >Ones I have personal experience with: >GLBX - yes >SAVVIS - no >VZB - yes, good luck >ATT - "Beginning in 1Q2010 MIS will provide the ability to support IPv6 >in a dual stack mode." >When I disconnected my SAVVIS circuit in November 2009 I explicitly told >them IPv6 was a deciding factor. Not all of Verizon's pops are IPv6 >enabled, which may cause you trouble ordering it. It's put me in month >11 of trying to turn up a dual-stack circuit because they refuse to read >the order and keep putting it in Sacramento (v4 only) when it needs to >go to San Jose (dual-stack). Sprint wasn't on your list, but they are >rolling out native IPv6 support on all of 1239. I've been using their >6175 testbed since 2005. >~Seth ------------------------------ Here's what I know: ATT - Yes; http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/ Level3 - Yes; http://www.level3.com/downloads/IPv6_Brochure.pdf GLBX (If we're talking Global Crossing) - Yes (I talked with them right after they came out of bankruptcy; look at Wikipedia) http://www.globalcrossing.com/ipkc/ipkc_ipv6.aspx Saavis - Don't know; claim was made in 2006 they would be ready in 2008 (based on the above from Seth, they probably blew it off) Verizon Business - Yes; LTE roll out is coming to "officially" open the v6 doors mandating v6 support for all connections and just "enabling" v4 connections; Verizon Federal has supported (via MCI) the DoD DREN for years, at least since 2005. Qwest - Yes; (I'm moderating an IPv6 panel with Owen Delong from HE and Qwest in April) Ones you didn't ask about, but are significant v6 players Sprint - Yes; Absolutely (Colleagues of mine helped them with some of their IPv6 security issues in 2008) NTT - Absolutely yes (Check out the Google IPv6 Implementer's conference and Rocky Mountain IPv6 Summit presentations from last year's conferences) Cheers, Ralph From jeroen at unfix.org Wed Mar 10 15:10:45 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 10 Mar 2010 22:10:45 +0100 Subject: IPv6 enabled carriers? In-Reply-To: <4CFB43B1-31C1-4D8D-AB70-2FE38DB96F05@delong.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4CFB43B1-31C1-4D8D-AB70-2FE38DB96F05@delong.com> Message-ID: <4B980AD5.7080101@spaghetti.zurich.ibm.com> Owen DeLong wrote: [..] > Hurricane Electric has a full production dual-stack environment. > >> I'm being tasked with coming up with an IPv6 migration plan for a data center. >> >> Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business >> and Qwest are capable as those are the typical ones I deal with. >> > To the best of my knowledge, each of those has varying degrees of IPv6 > availability and none is "full production product" yet. My information could > be old. Always fun to read how people who work for some place (you might want to use either your work address or actually disclose directly why you are pimping something) like to bash their competition else while they run a 'full production' network without providing true arguments to counter that, nevertheless lets take a look at that "full production network": 3 10g-3-2.core1.sjc2.ipv6.he.net (2001:470:0:3c::1) 66.649 ms 66.555 ms 66.511 ms 4 10g-3-2.core1.pao1.ipv6.he.net (2001:470:0:32::2) 59.644 ms 62.214 ms 62.164 ms 5 3ffe:80a::b2 (3ffe:80a::b2) 61.770 ms 62.135 ms 62.506 ms 6 hitachi1.otemachi.wide.ad.jp (2001:200:0:4401::3) 182.958 ms 181.156 ms 181.346 ms 7 2001:200:0:1c04::251 (2001:200:0:1c04::251) 183.827 ms 181.617 ms 181.554 ms Yes, 6bone is still alive (sing along to that well known Portal tune ;) I, and others, have mentioned that problem already several times since 2006-06-06, you know the day that 6bone got shut down. It is also still amazing that "full production networks" are not able to do proper uRPF or let alone IRR based filtering as in that case you would not even see that nonsense... Also if you are running such a "full production network" you might want to disclose the traffic levels that you do. Or is there something to hide there? Thus: please actually FINALLY fix your "full production network" by finally renumbering at PAIX. You are peering with other folks, thus you know who is on the other side, as such, after 4 years, you might want to finally move on from this 6bone space and possibly deploy uRPF. Then again, you'll notice those traffic levels one day when you will go into history as the source of the first large spoofed DoS attack against whatever truly important service. Thanks for your attention. Greets, Jeroen (who has no true ISP hat ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From joe.abley at icann.org Wed Mar 10 15:13:46 2010 From: joe.abley at icann.org (Joe Abley) Date: Wed, 10 Mar 2010 13:13:46 -0800 Subject: Signing of the ARPA zone Message-ID: <167FF0F1-B800-41AB-ACD6-E282C9DCD8FE@icann.org> Colleagues, This is a technical, operational announcement regarding changes to the ARPA top-level domain. Apologies in advance for duplicates received through different mailing lists. No specific action is requested of operators. This message is for your information only. The ARPA zone is about to be signed using DNSSEC. The technical parameters by which ARPA will be signed are as follows: KSK Algorithm and Size: 2048 bit RSA KSK Rollover: every 2-5 years, scheduled rollover to follow RFC 5011 KSK Signature Algorithm: SHA-256 Validity period for signatures made with KSK: 15 days; new signatures published every 10 days ZSK Algorithm and Size: 1024 bit RSA ZSK Rollover: every 3 months ZSK Signature Algorithm: SHA-256 Authenticated proof of non-existence: NSEC Validity period for signatures made with ZSK: 7 days; zone generated and re-signed twice per day The twelve root server operators [1] will begin to serve a signed ARPA zone instead of the (current) unsigned ARPA zone during a maintenance window which will open at 2010-03-15 0001 UTC and close at 2010-03-17 2359 UTC. Individual root server operators will carry out their maintenance at times within that window according to their own operational preference. The trust anchor for the ARPA zone will be published in the ITAR [2], and in the root zone in the form of a DS record once the root zone is signed. If you have any concerns or require further information, please let me know. Regards, Joe Abley Director DNS Operations, ICANN [1] [2] From mirkomaffioli at gmail.com Wed Mar 10 15:46:24 2010 From: mirkomaffioli at gmail.com (Mirko Maffioli) Date: Wed, 10 Mar 2010 22:46:24 +0100 Subject: 10GBase-t switch Message-ID: <413ff53f1003101346u81d3034hee0e669a8867cf83@mail.gmail.com> I'm searching for a switch with at least one 10Gbase-T ethernet port and some gigabit ethernet for lab test. >From cisco web site i've seen for example a 3560 model with X2 module and CX4 port but nothing with 10Gb-T. Unfortunately my budget couldn't arrive to nexus or cat6500.... Do you have some other vendor model i can check? Bye Mirko From bblackford at gmail.com Wed Mar 10 16:04:56 2010 From: bblackford at gmail.com (Bill Blackford) Date: Wed, 10 Mar 2010 14:04:56 -0800 Subject: 10GBase-t switch In-Reply-To: <413ff53f1003101346u81d3034hee0e669a8867cf83@mail.gmail.com> References: <413ff53f1003101346u81d3034hee0e669a8867cf83@mail.gmail.com> Message-ID: <680a83091003101404h16622b34k8cd3e45722508acb@mail.gmail.com> You might look at Juniper EX3200 with a EX-UM-2XFP and then optics of your choice (EX-XFP-10GE-SR) -b On Wed, Mar 10, 2010 at 1:46 PM, Mirko Maffioli wrote: > I'm searching for a switch with at least one 10Gbase-T ethernet port > and some gigabit ethernet for lab test. > >From cisco web site i've seen for example a 3560 model with X2 module > and CX4 port but nothing with 10Gb-T. > > Unfortunately my budget couldn't arrive to nexus or cat6500.... > > Do you have some other vendor model i can check? > > Bye > Mirko > > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From sgridelli at gmail.com Wed Mar 10 16:18:08 2010 From: sgridelli at gmail.com (Stefano Gridelli) Date: Wed, 10 Mar 2010 17:18:08 -0500 Subject: Wireless Ethernet bridge Message-ID: Hi All, I need a wireless bridge solution that allows to pass jumbo frames over a distance of 3 miles, using the 5.8 GHz band. The original solution was a Proxim Tsunami GX 200, but unfortunately it doesn't go beyond an MTU of 1536 bytes: we need at least 1544 bytes, ideally between 4470 and 9212 bytes MTU. The handoff should be MM fiber, the desired throughput 200 Mbps. Thanks, Stefano From mike.lyon at gmail.com Wed Mar 10 16:23:33 2010 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 10 Mar 2010 14:23:33 -0800 Subject: Wireless Ethernet bridge In-Reply-To: References: Message-ID: <1b5c1c151003101423l4b35c2fck10eada542442603f@mail.gmail.com> Check out DragonWave: http://www.dragonwaveinc.com/ -Mike On Wed, Mar 10, 2010 at 2:18 PM, Stefano Gridelli wrote: > Hi All, > > I need a wireless bridge solution that allows to pass jumbo frames over a > distance of 3 miles, using the 5.8 GHz band. The original solution was a > Proxim Tsunami GX 200, but unfortunately it doesn't go beyond an MTU of > 1536 > bytes: we need at least 1544 bytes, ideally between 4470 and 9212 bytes > MTU. The handoff should be MM fiber, the desired throughput 200 Mbps. > > Thanks, > Stefano > From lists at quux.de Wed Mar 10 16:26:34 2010 From: lists at quux.de (Jens Link) Date: Wed, 10 Mar 2010 23:26:34 +0100 Subject: IP4 Space In-Reply-To: (Owen DeLong's message of "Wed, 10 Mar 2010 08:12:51 -0800") References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> Message-ID: <87ljdzq0dh.fsf@laphroiag.quux.de> Owen DeLong writes: > I spend much of my time talking to groups of people about this. I > have managed to get several members of such groups from denial to > bargaining and sometimes eve depression in a single session. I did several presentations about IPv6 basics myself and there was very positive feedback but those people had already in interest in IPv6. I always quote an admin form a big German university: "We'll start with IPv6 in 13 years. It's when my colleague retires." > On rare occasion, acceptance even starts to set in. Thats true. I did one presentation, had a two hour train ride with someone from the audience and a couple of days later I got an email from him that his company network is running IPv6. But this is one person from a couple of hundred. > I think it is getting better and continuing to talk about it will help. Thats also true and I'm looking forward to this weekend when I once again will try to tell people why they should learn IPv6 now. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From SBrown at clackesd.k12.or.us Wed Mar 10 16:31:06 2010 From: SBrown at clackesd.k12.or.us (Scott Brown/Clack/ESD) Date: Wed, 10 Mar 2010 14:31:06 -0800 Subject: Wireless Ethernet bridge In-Reply-To: <1b5c1c151003101423l4b35c2fck10eada542442603f@mail.gmail.com> References: <1b5c1c151003101423l4b35c2fck10eada542442603f@mail.gmail.com> Message-ID: The Dragonwave would be my first choice too, but they are not in the 5.8GHz band. The Motorola PTP-600 has a 2000 byte MTU, but doesn't do multimode handoff. What radio to get will come down to what you are willing to give up -- if you are willing to drop the 5.8Ghz band and go with 11Ghz then the Dragonwave is for you -- the new Horizon Quantum is amazing (and pretty inexpensive when I priced it out) Bridgewave isn't bad either - you can get to 1.25Gbps with some fiber handoff. Scott Mike Lyon wrote on 03/10/2010 02:23:33 PM: > From: Mike Lyon > To: Stefano Gridelli > Cc: nanog at nanog.org > Date: 03/10/2010 02:23 PM > Subject: Re: Wireless Ethernet bridge > > Check out DragonWave: > > http://www.dragonwaveinc.com/ > > -Mike > > > > On Wed, Mar 10, 2010 at 2:18 PM, Stefano Gridelli wrote: > > > Hi All, > > > > I need a wireless bridge solution that allows to pass jumbo frames over a > > distance of 3 miles, using the 5.8 GHz band. The original solution was a > > Proxim Tsunami GX 200, but unfortunately it doesn't go beyond an MTU of > > 1536 > > bytes: we need at least 1544 bytes, ideally between 4470 and 9212 bytes > > MTU. The handoff should be MM fiber, the desired throughput 200 Mbps. > > > > Thanks, > > Stefano > > From owen at delong.com Wed Mar 10 16:41:20 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Mar 2010 14:41:20 -0800 Subject: IP4 Space In-Reply-To: <87ljdzq0dh.fsf@laphroiag.quux.de> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> <87ljdzq0dh.fsf@laphroiag.quux.de> Message-ID: On Mar 10, 2010, at 2:26 PM, Jens Link wrote: > Owen DeLong writes: > >> I spend much of my time talking to groups of people about this. I >> have managed to get several members of such groups from denial to >> bargaining and sometimes eve depression in a single session. > > I did several presentations about IPv6 basics myself and there was very > positive feedback but those people had already in interest in IPv6. > In some cases, yes. I've given a few presentations to audiences that started out downright hostile to IPv6 and many to audiences who were asking questions like "Can't we just use LSN?". > I always quote an admin form a big German university: "We'll start with > IPv6 in 13 years. It's when my colleague retires." > ROFL... Yep... I'm sure that will apply in several cases, but, there are places where I do see minds changing. Owen >> On rare occasion, acceptance even starts to set in. > > Thats true. I did one presentation, had a two hour train ride > with someone from the audience and a couple of days later I got an > email from him that his company network is running IPv6. > > But this is one person from a couple of hundred. > >> I think it is getting better and continuing to talk about it will help. > > Thats also true and I'm looking forward to this weekend when I once again > will try to tell people why they should learn IPv6 now. > > Jens > -- > ------------------------------------------------------------------------- > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | > | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | > ------------------------------------------------------------------------- From atporter at gmail.com Wed Mar 10 16:59:42 2010 From: atporter at gmail.com (Aaron Porter) Date: Wed, 10 Mar 2010 14:59:42 -0800 Subject: 10GBase-t switch In-Reply-To: <413ff53f1003101346u81d3034hee0e669a8867cf83@mail.gmail.com> References: <413ff53f1003101346u81d3034hee0e669a8867cf83@mail.gmail.com> Message-ID: <667aab921003101459i7badce12y1d4d07a95e89f604@mail.gmail.com> On Wed, Mar 10, 2010 at 1:46 PM, Mirko Maffioli wrote: > I'm searching for a switch with at least one 10Gbase-T ethernet port > and some gigabit ethernet for lab test. We're looking at Arista for this kind of config http://www.aristanetworks.com/en/products/7100t From jimb at jsbc.cc Wed Mar 10 18:40:37 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Wed, 10 Mar 2010 16:40:37 -0800 Subject: IP4 Space In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> Message-ID: <4B983C05.7030202@jsbc.cc> On 3/10/2010 05:06, Andy Koch wrote: > On Wed, Mar 10, 2010 at 04:55, Jens Link wrote: > >> Owen DeLong writes: >> >> >>>> denial >>>> anger >>>> bargaining >>>> depression >>>> >>> acceptance <--- My dual-stacked network and I are here. >>> >> So am I. But most IT people I talk to are still at the denial phase. And >> there is not much one can do about it. >> Denial, incredulity, and even anger have often been the reaction I get from IT people when I bring up IPv4 exhaustion and IPv6. I'm careful to try to be "cool" about it too, trying not to be preachy or annoying about it. Some recent samples of IT people I talk to regularly in IRC: > sam: Basically. We've had ipv6 for how many years in the UNIX world > and we STILL haven't switched yet ... > Ken: only Jim cares about IPv6 > sam: 15 years of hype and we might get to it in another 5 > sam: Emphasis on might > sam: Everything I've installed in the last 2 years has ipv6 disabled > Ken: i finally got an email from comcast about my participating in > their ipv6 trials ... haha ... TRIALS - they're still at least 2 years > out i'm sure I doubt I'm the only one who's run across these sorts of attitudes. At least Ken is willing to participate in the Comcast trial. :) IMHO, only personally experienced pain is going to push a lot of these sorts of people into ipv6. By pain, I mean things such as not being able to deploy their new service (web site, email server, VPN box, whatever) on the internet due to lack of ipv4 addresses, having to implement double NAT, CGN/LSN, or being forced to live behind such an arrangement ["what do you mean I can't port forward the port for my favorite game/new service?!?!" (yes, I know some schemes will still allow customer port forwards, but this will be made more difficult, painful, since many users will now be sharing the same publics.)] Once the "pain" hits, many will be doing crash courses in ipv6 and rolling it out as quickly as they can. I think it's just human nature. :) - Jim From owen at delong.com Wed Mar 10 18:57:33 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Mar 2010 16:57:33 -0800 Subject: IP4 Space In-Reply-To: <4B983C05.7030202@jsbc.cc> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> <4B983C05.7030202@jsbc.cc> Message-ID: > > IMHO, only personally experienced pain is going to push a lot of these > sorts of people into ipv6. By pain, I mean things such as not being > able to deploy their new service (web site, email server, VPN box, > whatever) on the internet due to lack of ipv4 addresses, having to > implement double NAT, CGN/LSN, or being forced to live behind such an > arrangement ["what do you mean I can't port forward the port for my > favorite game/new service?!?!" (yes, I know some schemes will still > allow customer port forwards, but this will be made more difficult, > painful, since many users will now be sharing the same publics.)] > > Once the "pain" hits, many will be doing crash courses in ipv6 and > rolling it out as quickly as they can. I think it's just human > nature. :) > > - Jim > > Yep... We all know you can't get an ostrich's head out of the sand with a shovel. Having said that, I do think we have other tools besides shovels at our disposal. I try to avoid being preachy, but, at the same time, there are some pretty hard numbers available. It's not the guys on IRC that need the most convincing anyway. They know, and in many cases, while they're still in denial, they don't need to change because they couldn't get support from above if they did. The target really needs to be the CxOs and the management, especially in places where there is content facing the general public. Fortunately, Google, Yahoo, Netflix, etc. get it and have moved forward with IPv6. Some others are coming along. I just prodded the IT department at Wells Fargo today while working on troubleshooting an IPv4-based email problem asking them why my messages weren't reaching them over IPv6 as well. The main thing we need to convey to our colleagues in the IRC crowd is that IPv6 really isn't as difficult as some have made it out to be. While it does require some different thinking, mostly in the area of address planning, the rest of it is pretty much business as usual just like IPv4. The other hurdle I've encountered is fear about "switching" to IPv6. We need to be clear that we aren't "switching" to IPv6, we're "adding IPv6 capabilities to the existing IPv4 network". The former creates a lot more fear of change than the latter. Owen (Oh, and in case anyone doesn't know, yes, I work for Hurricane Electric. I went to work there because I liked what they were doing with IPv6. I'd recommend their products (and did) even if I did not work there.) From joelja at bogus.com Wed Mar 10 20:17:22 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 10 Mar 2010 18:17:22 -0800 Subject: 10GBase-t switch In-Reply-To: <680a83091003101404h16622b34k8cd3e45722508acb@mail.gmail.com> References: <413ff53f1003101346u81d3034hee0e669a8867cf83@mail.gmail.com> <680a83091003101404h16622b34k8cd3e45722508acb@mail.gmail.com> Message-ID: <4B9852B2.3020300@bogus.com> arista 7120t-4s... On 03/10/2010 02:04 PM, Bill Blackford wrote: > You might look at Juniper EX3200 with a EX-UM-2XFP and then optics of your > choice (EX-XFP-10GE-SR) > > -b > > On Wed, Mar 10, 2010 at 1:46 PM, Mirko Maffioli wrote: > >> I'm searching for a switch with at least one 10Gbase-T ethernet port >> and some gigabit ethernet for lab test. >> >From cisco web site i've seen for example a 3560 model with X2 module >> and CX4 port but nothing with 10Gb-T. >> >> Unfortunately my budget couldn't arrive to nexus or cat6500.... >> >> Do you have some other vendor model i can check? >> >> Bye >> Mirko >> >> > > From jimb at jsbc.cc Wed Mar 10 20:46:19 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Wed, 10 Mar 2010 18:46:19 -0800 Subject: IP4 Space In-Reply-To: References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> <4B983C05.7030202@jsbc.cc> Message-ID: <4B98597B.3060101@jsbc.cc> On 3/10/2010 16:57, Owen DeLong wrote: >> >> IMHO, only personally experienced pain is going to push a lot of these >> sorts of people into ipv6. By pain, I mean things such as not being >> able to deploy their new service (web site, email server, VPN box, >> whatever) on the internet due to lack of ipv4 addresses, having to >> implement double NAT, CGN/LSN, or being forced to live behind such an >> arrangement ["what do you mean I can't port forward the port for my >> favorite game/new service?!?!" (yes, I know some schemes will still >> allow customer port forwards, but this will be made more difficult, >> painful, since many users will now be sharing the same publics.)] >> >> Once the "pain" hits, many will be doing crash courses in ipv6 and >> rolling it out as quickly as they can. I think it's just human >> nature. :) >> >> - Jim >> >> > 8<--- > > I try to avoid being preachy, but, at the same time, there are some > pretty hard numbers available. It's not the guys on IRC that need > the most convincing anyway. They know, and in many cases, > while they're still in denial, they don't need to change because > they couldn't get support from above if they did. > > The target really needs to be the CxOs and the management, > especially in places where there is content facing the general > public. Fortunately, Google, Yahoo, Netflix, etc. get it and have > moved forward with IPv6. Some others are coming along. True. CxOs can basically order it to be done. But for the "guys in the trenches", I often talk about the issues just to give them a heads up, so they don't get caught off guard when ipv4 exhaustion hits. Plus, they can also exert pressure upwards that can cause decisions to be made. And in the case of small shops and start ups, they often are the primary decision makers/influencers for all things IT anyway (a situation I'm very familiar with). 8<--- > The main thing we need to convey to our colleagues in the IRC > crowd is that IPv6 really isn't as difficult as some have made > it out to be. While it does require some different thinking, mostly > in the area of address planning, the rest of it is pretty much > business as usual just like IPv4. > > The other hurdle I've encountered is fear about "switching" to > IPv6. We need to be clear that we aren't "switching" to IPv6, > we're "adding IPv6 capabilities to the existing IPv4 network". > The former creates a lot more fear of change than the latter. Yep. I always try to convey how similar everything is for day to day network operations. I try to tell them that if they understand IPv4 CIDR, subnetting, etc, they're already 3/4 of the way there for IPv6. IMHO, address planning for the average company is far simpler under IPv6. Typically they'll be given a /48, and then they'll have 64Ki /64s to use for subnets, and that's it, and often all they'll ever need. To me this is simpler than the typical assortment of RFC1918s with heavy VLSM. Not to mention the RFC1918 overlap complications that arise with partnerships, mergers, etc. :-) Yes. I always emphasize dual-stack too. I tell them to just give it a try by setting up, say, an HE tunnel to one machine. Then later terminate the tunnel to a router and try it on a few more boxes. Another thing I do if they're running Vista or Windows 7, is to ping an IPv6 address, and when Teredo gets them ping replies, I tell them "see, you're already running IPv6 and have basic connectivity". Although I don't know if this is a good idea, since Teredo isn't the most reliable thing. :p > Owen > > (Oh, and in case anyone doesn't know, yes, I work for Hurricane > Electric. I went to work there because I liked what they were doing > with IPv6. I'd recommend their products (and did) even if I did not > work there.) > I get my IPv6 over an HE 6in4 tunnel. :-) I wish my ISP (who shall remain unnamed) provided native IPv6 service, but this is the response I got last time I inquired: > Unfortunately, we don't have a status on changing to IPv6. We currently offer only ADSL2, Fiber and T1. And then after a second inquiry about a few months later: > We are aware of the IPv4 situation and at this point and time we have no > plans to switch over to IPv6. A shame since I'm otherwise very pleased with this ISP. I may hit them up again since it's been nearly a year since the last inquiry. Or at least try to get through to someone other than a TSE or a Billing & Collections Manager. :) From dts at senie.com Wed Mar 10 21:00:32 2010 From: dts at senie.com (Daniel Senie) Date: Wed, 10 Mar 2010 22:00:32 -0500 Subject: IP4 Space In-Reply-To: <4B983C05.7030202@jsbc.cc> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> <4B983C05.7030202@jsbc.cc> Message-ID: <88A50944-0767-48A5-A631-28E84B3CE587@senie.com> Well, it's like this... there's still no native IPv6 connectivity in most data centers, residences, businesses or wireless, most vendors of networking equipment have not had a lot of mileage on their IPv6 code if they even have it fully working, and, frankly, the IPv6 community has been predicting a falling sky for so long that people just gave up listening. Add in a whole lot of other bits of argument that just exasperate those dealing with today's problems, and it's pretty easy to understand, if you've not been one of the ones pushing IPV6 for all these years, that there's a lot of listener fatigue. Engineers don't make good salespeople. IPv6 is a good example. So we will wind up muddling along for several more years as the vendors shake out their code, routers wedge, firewalls freak out, and predictions of collapse are repeated daily. And to fellow engineers: we will all be blamed for the failure. Sorry, that's just the way it will be. Don't bother trying to deflect blame. Just deal with the issues, solve them as best you can, and move on. On Mar 10, 2010, at 7:40 PM, Jim Burwell wrote: > On 3/10/2010 05:06, Andy Koch wrote: >> On Wed, Mar 10, 2010 at 04:55, Jens Link wrote: >> >>> Owen DeLong writes: >>> >>> >>>>> denial >>>>> anger >>>>> bargaining >>>>> depression >>>>> >>>> acceptance <--- My dual-stacked network and I are here. >>>> >>> So am I. But most IT people I talk to are still at the denial phase. And >>> there is not much one can do about it. >>> > Denial, incredulity, and even anger have often been the reaction I get > from IT people when I bring up IPv4 exhaustion and IPv6. I'm careful to > try to be "cool" about it too, trying not to be preachy or annoying > about it. > > Some recent samples of IT people I talk to regularly in IRC: > >> sam: Basically. We've had ipv6 for how many years in the UNIX world >> and we STILL haven't switched yet ... >> Ken: only Jim cares about IPv6 >> sam: 15 years of hype and we might get to it in another 5 >> sam: Emphasis on might >> sam: Everything I've installed in the last 2 years has ipv6 disabled >> Ken: i finally got an email from comcast about my participating in >> their ipv6 trials ... haha ... TRIALS - they're still at least 2 years >> out i'm sure > I doubt I'm the only one who's run across these sorts of attitudes. At > least Ken is willing to participate in the Comcast trial. :) > > IMHO, only personally experienced pain is going to push a lot of these > sorts of people into ipv6. By pain, I mean things such as not being > able to deploy their new service (web site, email server, VPN box, > whatever) on the internet due to lack of ipv4 addresses, having to > implement double NAT, CGN/LSN, or being forced to live behind such an > arrangement ["what do you mean I can't port forward the port for my > favorite game/new service?!?!" (yes, I know some schemes will still > allow customer port forwards, but this will be made more difficult, > painful, since many users will now be sharing the same publics.)] > > Once the "pain" hits, many will be doing crash courses in ipv6 and > rolling it out as quickly as they can. I think it's just human nature. :) > > - Jim > > > From rbk at mnsginc.com Wed Mar 10 21:06:21 2010 From: rbk at mnsginc.com (R. Benjamin Kessler) Date: Wed, 10 Mar 2010 22:06:21 -0500 Subject: ethernet to serial converters with ACLs In-Reply-To: References: <4B97FE71.8090700@csuohio.edu> Message-ID: <0B608FCDCF43BF4C9194C896C532024371A993@mnsg-svr2.mnsg.net> >On Mar 10, 2010, at 3:17 PM, Michael Holstein wrote: >> Can anyone recommend a cheap Ethernet to Serial (RS232/422/485) >> converter with functionality like the Lantronix boxes .. except one that >> supports access lists (nothing complicated .. maybe a list of 5 approved >> hosts). I need a bunch of single port devices, not an access-server for >> a rack. >We use SENA PS110 boxes ( >http://www.sena.com/products/device_servers/hd_ps_x10.php ). They work >very well, have various ACL features (dunno if it supports 5 named IP or >not), and other configurables. >Caleb On a similar topic, any good solutions for out-of-band serial console/Ethernet solutions that use EV-DO/GSM wireless Internet? From randy at psg.com Wed Mar 10 21:26:16 2010 From: randy at psg.com (Randy Bush) Date: Thu, 11 Mar 2010 12:26:16 +0900 Subject: 10GBase-t switch In-Reply-To: <4B9852B2.3020300@bogus.com> References: <413ff53f1003101346u81d3034hee0e669a8867cf83@mail.gmail.com> <680a83091003101404h16622b34k8cd3e45722508acb@mail.gmail.com> <4B9852B2.3020300@bogus.com> Message-ID: > arista 7120t-4s... hot box. but you are giving away the secret sauce! randy From accesss801 at gmail.com Wed Mar 10 21:40:48 2010 From: accesss801 at gmail.com (Daniel) Date: Wed, 10 Mar 2010 20:40:48 -0700 Subject: Qwest DNS Problems? Message-ID: <24535bbb1003101940o6616d9f7r80ca6522a9612029@mail.gmail.com> Did anyone notice any issues with Qwest DNS the past hour or two? We've had users with intermittent issues and the weird thing is while they can't resolve certain domains within Qwest's network I can query the same DNS servers from outside of Qwest's network and the names resolve just fine. Dan From LarrySheldon at cox.net Wed Mar 10 21:44:18 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 10 Mar 2010 21:44:18 -0600 Subject: Qwest DNS Problems? In-Reply-To: <24535bbb1003101940o6616d9f7r80ca6522a9612029@mail.gmail.com> References: <24535bbb1003101940o6616d9f7r80ca6522a9612029@mail.gmail.com> Message-ID: <4B986712.3070808@cox.net> On 3/10/2010 9:40 PM, Daniel wrote: > Did anyone notice any issues with Qwest DNS the past hour or two? We've had > users with intermittent issues and the weird thing is while they can't > resolve certain domains within Qwest's network I can query the same DNS > servers from outside of Qwest's network and the names resolve just fine. Sounds like their DHCP servers have a bad default domain name or some such. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From Joe.Goldberg at falconstor.com Wed Mar 10 21:47:38 2010 From: Joe.Goldberg at falconstor.com (Joe Goldberg) Date: Wed, 10 Mar 2010 22:47:38 -0500 Subject: 10GBase-t switch References: <413ff53f1003101346u81d3034hee0e669a8867cf83@mail.gmail.com> <667aab921003101459i7badce12y1d4d07a95e89f604@mail.gmail.com> Message-ID: <629000C394462748817B16908F1AC93E48D181@CORPEXCH04.FalconStor.Net> I have to agree the Arista is a great box at a great price (comparatively). I was really impressed with the performance in our testing for top of rack switches. The Juniper EX3200 with 10GigE uplink card works really well too but you are limited to 2x10GE ports per switch. We have a couple of them deployed in that configuration in our closets. Joe -----Original Message----- From: Aaron Porter [mailto:atporter at gmail.com] Sent: Wednesday, March 10, 2010 6:00 PM To: mirkomaffioli at gmail.com Cc: nanog at nanog.org Subject: Re: 10GBase-t switch On Wed, Mar 10, 2010 at 1:46 PM, Mirko Maffioli wrote: > I'm searching for a switch with at least one 10Gbase-T ethernet port > and some gigabit ethernet for lab test. We're looking at Arista for this kind of config http://www.aristanetworks.com/en/products/7100t From meekjt at gmail.com Wed Mar 10 21:52:09 2010 From: meekjt at gmail.com (Jon Meek) Date: Wed, 10 Mar 2010 22:52:09 -0500 Subject: ethernet to serial converters with ACLs In-Reply-To: <0B608FCDCF43BF4C9194C896C532024371A993@mnsg-svr2.mnsg.net> References: <4B97FE71.8090700@csuohio.edu> <0B608FCDCF43BF4C9194C896C532024371A993@mnsg-svr2.mnsg.net> Message-ID: Avocent / Cyclades boxes have ACL capability (they run Linux) and can be used with EV-DO/GSM modems. They may not be the lowest cost solution, but there is a central management system and a wide range of serial interface units from single port to at least 32 ports. Jon Full disclosure: I was a member of their Customer Advisory Board On Wed, Mar 10, 2010 at 10:06 PM, R. Benjamin Kessler wrote: > >>On Mar 10, 2010, at 3:17 PM, Michael Holstein wrote: > >>> Can anyone recommend a cheap Ethernet to Serial (RS232/422/485) >>> converter with functionality like the Lantronix boxes .. except one > that >>> supports access lists (nothing complicated .. maybe a list of 5 > approved >>> hosts). I need a bunch of single port devices, not an access-server > for >>> a rack. > >>We use SENA PS110 boxes ( >>http://www.sena.com/products/device_servers/hd_ps_x10.php ). ?They work >>very well, have various ACL features (dunno if it supports 5 named IP > or >not), and other configurables. > >>Caleb > > On a similar topic, any good solutions for out-of-band serial > console/Ethernet solutions that use EV-DO/GSM wireless Internet? > > From uri.joskovitch at telrad.com Wed Mar 10 22:05:42 2010 From: uri.joskovitch at telrad.com (Uri Joskovitch) Date: Thu, 11 Mar 2010 06:05:42 +0200 Subject: ethernet to serial converters with ACLs In-Reply-To: References: <4B97FE71.8090700@csuohio.edu><0B608FCDCF43BF4C9194C896C532024371A993@mnsg-svr2.mnsg.net> Message-ID: <02755D474772E74E97471FC5BBE7641B02E872BB@TLRD-MAIL1.Telrad.co.il> What would be there cost in qty of hundreds? Thanks Uri From ryan at deadfrog.net Wed Mar 10 23:03:04 2010 From: ryan at deadfrog.net (Ryan Wilkins) Date: Wed, 10 Mar 2010 23:03:04 -0600 Subject: Wireless Ethernet bridge In-Reply-To: References: <1b5c1c151003101423l4b35c2fck10eada542442603f@mail.gmail.com> Message-ID: Instead of the PTP600, you might try looking at the PTP800. Again, not 5.8 GHz but does up to 368 Mbps full duplex over the air interface, jumbo frames up to 9600 bytes, AES 128 or 256 bit encryption, 11, 18, 23, or 26 GHz depending on what regulatory agency you fall under. Will do fiber or copper handoff at gigabit speeds. I also have two BridgeWave links installed. The older stuff (AR80- AES) won't do jumbo frames. The newer stuff (FlexPort-AES) will do jumbo frames to something like 9200 bytes. These links operate at 80 GHz. Both models have had issues but the support has been very good. Handoff is fiber on the older line and SFP (presumably fiber) on the newer line. Neither are inexpensive. You're looking at about USD $32k or so for the BridgeWave radios per link. The PTP600 and 800 are about the same at USD $15k or so per link. Prices vary (wildly) with options. Lab testing of the PTP600 yielded about 225 Mbps each way even though the advertised speed was closer to 150 Mbps each way. In the end, we ended up returning the PTP600 before it was installed, not because it was a substandard product, but rather because our landlord chose to make liberal use of the 5.8 GHz band for security cameras. I have no doubt that we would have closed the links at 5.8 GHz but it would have likely killed our landlord's camera network. Instead of causing problems, we chose to return the radios and go with the PTP800 which weren't available at the time we were investigating this radio solution. Good luck on your search. Ryan Wilkins On Mar 10, 2010, at 4:31 PM, Scott Brown/Clack/ESD wrote: > The Dragonwave would be my first choice too, but they are not in the > 5.8GHz > band. > > The Motorola PTP-600 has a 2000 byte MTU, but doesn't do multimode > handoff. > > What radio to get will come down to what you are willing to give up > -- if > you are willing to drop the 5.8Ghz band and go with 11Ghz then the > Dragonwave is for you -- the new Horizon Quantum is amazing (and > pretty > inexpensive when I priced it out) > > Bridgewave isn't bad either - you can get to 1.25Gbps with some fiber > handoff. > > > Scott > > Mike Lyon wrote on 03/10/2010 02:23:33 PM: > >> From: Mike Lyon >> To: Stefano Gridelli >> Cc: nanog at nanog.org >> Date: 03/10/2010 02:23 PM >> Subject: Re: Wireless Ethernet bridge >> >> Check out DragonWave: >> >> http://www.dragonwaveinc.com/ >> >> -Mike >> >> >> >> On Wed, Mar 10, 2010 at 2:18 PM, Stefano Gridelli > wrote: >> >>> Hi All, >>> >>> I need a wireless bridge solution that allows to pass jumbo frames >>> over > a >>> distance of 3 miles, using the 5.8 GHz band. The original solution >>> was > a >>> Proxim Tsunami GX 200, but unfortunately it doesn't go beyond an >>> MTU of >>> 1536 >>> bytes: we need at least 1544 bytes, ideally between 4470 and 9212 >>> bytes >>> MTU. The handoff should be MM fiber, the desired throughput 200 >>> Mbps. >>> >>> Thanks, >>> Stefano >>> > > From oberman at es.net Thu Mar 11 00:04:07 2010 From: oberman at es.net (Kevin Oberman) Date: Wed, 10 Mar 2010 22:04:07 -0800 Subject: 10GBase-t switch In-Reply-To: Your message of "Thu, 11 Mar 2010 12:26:16 +0900." Message-ID: <20100311060407.13AFB1CC0D@ptavv.es.net> > Date: Thu, 11 Mar 2010 12:26:16 +0900 > From: Randy Bush > > > arista 7120t-4s... > > hot box. but you are giving away the secret sauce! Hot box for the datacenter, but small buffers make it unsuited for long distances. In the right place, this box can't be beaten in the price/performance realm. Some of their salescritters can be annoying, too, but YMMV. We may have just hit a bad one. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From pekkas at netcore.fi Thu Mar 11 00:37:17 2010 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 11 Mar 2010 08:37:17 +0200 (EET) Subject: IPv6 enabled carriers? In-Reply-To: <443de7ad1003101128u16be86bva3b4e28ad398731c@mail.gmail.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <443de7ad1003101128u16be86bva3b4e28ad398731c@mail.gmail.com> Message-ID: On Wed, 10 Mar 2010, Chris Grundemann wrote: > SixXS maintains a list here: > http://www.sixxs.net/faq/connectivity/?faq=ipv6transit. I think that list should also include TeliaSonera. TSIC does offer v6 transit, although their product sheet only mentions IPv4. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From positivelyoptimistic at gmail.com Thu Mar 11 01:22:40 2010 From: positivelyoptimistic at gmail.com (Express Networks) Date: Thu, 11 Mar 2010 02:22:40 -0500 Subject: FW: ethernet to serial converters with ACLs In-Reply-To: <5660BE35FEDB3C46AB40375444749E60640A016534@EXVMBX016-2.exch016.msoutlookonline.net> References: <5660BE35FEDB3C46AB40375444749E60640A016534@EXVMBX016-2.exch016.msoutlookonline.net> Message-ID: <8dbb1e641003102322u3216b415l1640dd0e8203c170@mail.gmail.com> We've used mikrotik routerboards that support ev-do as wireless serial adapters.. It is only good for a single port application.. but it works.. and at a price of $99.. it would certainly support access lists.. we have them dial back to a pptp concentrator... just a thought.. > > -----Original Message----- > From: Jon Meek [mailto:meekjt at gmail.com] > Sent: Wednesday, March 10, 2010 10:52 PM > To: R. Benjamin Kessler > Cc: nanog at nanog.org > Subject: Re: ethernet to serial converters with ACLs > > Avocent / Cyclades boxes have ACL capability (they run Linux) and can > be used with EV-DO/GSM modems. They may not be the lowest cost > solution, but there is a central management system and a wide range of > serial interface units from single port to at least 32 ports. > > Jon > Full disclosure: I was a member of their Customer Advisory Board > > On Wed, Mar 10, 2010 at 10:06 PM, R. Benjamin Kessler > wrote: > > > >>On Mar 10, 2010, at 3:17 PM, Michael Holstein wrote: > > > >>> Can anyone recommend a cheap Ethernet to Serial (RS232/422/485) > >>> converter with functionality like the Lantronix boxes .. except one > > that > >>> supports access lists (nothing complicated .. maybe a list of 5 > > approved > >>> hosts). I need a bunch of single port devices, not an access-server > > for > >>> a rack. > > > >>We use SENA PS110 boxes ( > >>http://www.sena.com/products/device_servers/hd_ps_x10.php ). They work > >>very well, have various ACL features (dunno if it supports 5 named IP > > or >not), and other configurables. > > > >>Caleb > > > > On a similar topic, any good solutions for out-of-band serial > > console/Ethernet solutions that use EV-DO/GSM wireless Internet? > > > > > > From jeroen at unfix.org Thu Mar 11 04:06:12 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Mar 2010 11:06:12 +0100 Subject: IPv6 enabled carriers? In-Reply-To: References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <443de7ad1003101128u16be86bva3b4e28ad398731c@mail.gmail.com> Message-ID: <4B98C094.3050808@spaghetti.zurich.ibm.com> Pekka Savola wrote: > On Wed, 10 Mar 2010, Chris Grundemann wrote: >> SixXS maintains a list here: >> http://www.sixxs.net/faq/connectivity/?faq=ipv6transit. > > I think that list should also include TeliaSonera. TSIC does offer v6 > transit, although their product sheet only mentions IPv4. "Updates & addons can be directed to The SixXS Staff." aka info at sixxs.net ;) All of these entries have been requested by the company themselves as such the company states that they can deliver. As the page states, peeringdb is also an excellent place to figure out where those providers are truly present (again according to what they provide to these systems). Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Thu Mar 11 04:08:55 2010 From: randy at psg.com (Randy Bush) Date: Thu, 11 Mar 2010 19:08:55 +0900 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <20100227062038.38AD01CC0E@ptavv.es.net> References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> Message-ID: > I'm sorry, but some people are spending too much time denying > history. IPv6 has been largely ready for YEARS. Less than five years ago > a lot of engineers were declaring IPv6 dead and telling people that > double and triple NAT was the way of the future. It's only been over the > past two years that a clear majority of the networks seemed to agree > that IPv6 was the way out of the mess. (I know some are still in > denial.) http://www.hactrn.net/sra/vorlons a decade old, but still rings true randy From brunner at nic-naa.net Thu Mar 11 04:33:08 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 11 Mar 2010 05:33:08 -0500 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> Message-ID: <4B98C6E4.6020203@nic-naa.net> What NANOG contributors, if any, are invited by a government, to join their national delegation to the initial meeting of the ITU's IPv6 Group in Geneva next week? From tvest at eyeconomics.com Thu Mar 11 06:12:00 2010 From: tvest at eyeconomics.com (Tom Vest) Date: Thu, 11 Mar 2010 07:12:00 -0500 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> Message-ID: On Mar 11, 2010, at 5:08 AM, Randy Bush wrote: >> I'm sorry, but some people are spending too much time denying >> history. IPv6 has been largely ready for YEARS. Less than five years ago >> a lot of engineers were declaring IPv6 dead and telling people that >> double and triple NAT was the way of the future. It's only been over the >> past two years that a clear majority of the networks seemed to agree >> that IPv6 was the way out of the mess. (I know some are still in >> denial.) > > http://www.hactrn.net/sra/vorlons > > a decade old, but still rings true > > randy It's a nice essay, but the author seems to have overlooked the contingent fact that he's a member of a species that is actually supported by the ecosystem that he's writing about. The Sahara Desert is an ecosystem too, as is the surface of the moon. Of course, the Internet is really only like an ecosystem in the way that Tokyo and Los Angeles and Lagos are individually like ecosystems. If you think you'd be indifferent to the question of which of these places you'd prefer to live in, and prefer your children to live in -- even knowing that there are no suburbs or country retreats to escape to, anywhere -- then I guess it really is just a philosophical question. TV From henry at AegisInfoSys.com Thu Mar 11 06:34:38 2010 From: henry at AegisInfoSys.com (Henry Yen) Date: Thu, 11 Mar 2010 07:34:38 -0500 Subject: ethernet to serial converters with ACLs In-Reply-To: <4B97FE71.8090700@csuohio.edu>; from Michael Holstein on Wed, Mar 10, 2010 at 15:17:53PM -0500 References: <4B97FE71.8090700@csuohio.edu> Message-ID: <20100311073438.Y25919@AegisInfoSys.com> On Wed, Mar 10, 2010 at 15:17:53PM -0500, Michael Holstein wrote: > Can anyone recommend a cheap Ethernet to Serial (RS232/422/485) > converter with functionality like the Lantronix boxes .. except one that > supports access lists (nothing complicated .. maybe a list of 5 approved > hosts). I need a bunch of single port devices, not an access-server for > a rack. > > I could build one out of a Pogoplug + USB/serial dongle .. (~$120 total) > but would rather not re-invent the wheel. > > All the "secure" ones I see involve encrypting com port redirectors for > the host PC .. I don't care about encrypting data in flight, I just want > to restrict who can connect to the COM port on the other side of the IP > device. It needs to work like the Lantronics ones do (take tcp/(port) > and spit it out as rs232). I may not understand your query, but I think the Perle IOLAN serial/terminal ethernet mini-servers can do that. They pop up on ebay in various shades of slightly-used, for around $40. Similar devices are Comtrol DeviceMasters, which are less featureful (and even cheaper). -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From mcallahan at bullseyetelecom.com Thu Mar 11 07:17:12 2010 From: mcallahan at bullseyetelecom.com (Mike Callahan) Date: Thu, 11 Mar 2010 08:17:12 -0500 Subject: Best VPN Appliance In-Reply-To: Message-ID: <90DF793301873F469B0B7878B4CFD4F4015A4B38BDC9@EXMAIL.bullseyetelecom.com> +1 for the ShrewSoft Client for Windows 7. Works like a champ. Mike -----Original Message----- From: Jon Auer [mailto:jda at tapodi.net] Sent: Monday, March 08, 2010 2:54 PM To: Blomberg, Orin P (DOH) Cc: nanog at nanog.org Subject: Re: Best VPN Appliance If you can use 3rd party VPN clients the ShrewSoft IPSec client on Windows 7 works great with Cisco concentrators. http://www.shrew.net/software On Mon, Mar 8, 2010 at 1:37 PM, Blomberg, Orin P (DOH) wrote: > There is also the fact to consider that Cisco has said there will be no > support for Windows 64-bit on their IPSEC client, they are pushing > people to the AnyConnect (An SSL-based clientless IPSEC) who want to use > Windows 64-bit or other OSs, so in the future the argument for having a > separate box for client-based IPSEC will be moot. > > Orin > > -----Original Message----- > From: Stefan Fouant [mailto:sfouant at shortestpathfirst.net] > Sent: Monday, March 08, 2010 11:29 AM > To: Voll, Toivo; Chris Campbell; Dawood Iqbal > Cc: nanog at nanog.org > Subject: Re: Best VPN Appliance > > Toivo, > > The SA Series absolutely supports IPsec if you are using Network > Connect. It defaults to using IPsec and if that is not supported then > it will fall back to SSL. Of course, NC is not as secure as W-SAM, > J-SAM, or Core Access in terms of role and resource granularity control > but the support for IPsec is absolutely there. > > HTHs. > > Stefan Fouant > ------Original Message------ > From: Voll, Toivo > To: Chris Campbell > To: Dawood Iqbal > Cc: nanog at nanog.org > Subject: RE: Best VPN Appliance > Sent: Mar 8, 2010 11:56 AM > > We're generally happy with our Juniper SA6500s, but they, and a lot of > the other SSL VPN vendor appliances will not support IPSec. Cisco's ASA > does, but it's less feature-rich in the SSL VPN arena. The Juniper was > the most mature and flexible of all the offerings we looked at, but also > the most expensive, and it's not perfect either. > > Having migrated from Cisco's 3000 series appliances, the current SSL > VPNs are a totally different mindset and about two orders of magnitude > more complicated. Have a very good understanding of exactly what problem > you're trying to solve with the product and what kind of policies and > requirements you have to meet, or it's going to be a mess. I can answer > more specific questions on our experiences and testing off-list. > > -- > Toivo Voll > University of South Florida > Information Technology Communications > > > > > -----Original Message----- > From: Chris Campbell [mailto:Chris.Campbell at nebulassolutions.com] > Sent: Friday, March 05, 2010 11:36 AM > To: Dawood Iqbal > Cc: nanog at nanog.org > Subject: Re: Best VPN Appliance > > The Juniper SA is by far and away the market leader and in my opinion > the best end user experience. > > On 5 Mar 2010, at 15:57, Dawood Iqbal wrote: > >> Hello All, >> >> >> >> Is it possible to get your ideas on what VPN appliances are good to > have in >> enterprise network? >> >> >> >> Requirements are; >> >> SSL >> >> IPSec >> >> Client and Web VPN support (Win/MAC/iPhone/Android) >> >> If webvpn is used, then when any user connects via webvpn, we should > be able >> to re-direct him to any and ONLY specific application i.e SAP. >> >> If 2 boxes are installed then they should replicate data seamlessly. >> >> >> >> >> >> Regards, >> >> dI >> > > > > > Sent from my Verizon Wireless BlackBerry > > From r.bhatia at ipax.at Thu Mar 11 08:50:09 2010 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Thu, 11 Mar 2010 15:50:09 +0100 Subject: 10GBase-t switch In-Reply-To: <20100311060407.13AFB1CC0D@ptavv.es.net> References: <20100311060407.13AFB1CC0D@ptavv.es.net> Message-ID: <4B990321.10908@ipax.at> On 03/11/2010 07:04 AM, Kevin Oberman wrote: >> Date: Thu, 11 Mar 2010 12:26:16 +0900 >> From: Randy Bush >> >>> arista 7120t-4s... >> >> hot box. but you are giving away the secret sauce! > > Hot box for the datacenter, but small buffers make it unsuited for > long distances. In the right place, this box can't be beaten in the > price/performance realm. "Arista EOS" - what good/bad things do you have to say about their management capabilities? which "known" brand can it be compared to? thanks, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From rubensk at gmail.com Thu Mar 11 09:21:18 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 11 Mar 2010 12:21:18 -0300 Subject: 10GBase-t switch In-Reply-To: <4B990321.10908@ipax.at> References: <20100311060407.13AFB1CC0D@ptavv.es.net> <4B990321.10908@ipax.at> Message-ID: <6bb5f5b11003110721l44a7bdefybb539fa03ac4065a@mail.gmail.com> > "Arista EOS" - what good/bad things do you have to say about their > management capabilities? which "known" brand can it be compared to? I couldn't help myself thinking that the name of an operanting system shouldn't resemble "End of Sales" that much. Rubens From dylan.ebner at crlmed.com Thu Mar 11 09:29:17 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Thu, 11 Mar 2010 15:29:17 +0000 Subject: 10GBase-t switch In-Reply-To: <4B990321.10908@ipax.at> References: <20100311060407.13AFB1CC0D@ptavv.es.net> <4B990321.10908@ipax.at> Message-ID: <017265BF3B9640499754DD48777C3D2067B738F2A9@MBX9.EXCHPROD.USA.NET> Do the Arista switches support netflow? From a management perspective netflow can be vital. This is something we have been unhappy with on our 3560 and 3750 cisco's. Dylan -----Original Message----- From: Raoul Bhatia [IPAX] [mailto:r.bhatia at ipax.at] Sent: Thursday, March 11, 2010 8:50 AM To: nanog at nanog.org Subject: Re: 10GBase-t switch On 03/11/2010 07:04 AM, Kevin Oberman wrote: >> Date: Thu, 11 Mar 2010 12:26:16 +0900 >> From: Randy Bush >> >>> arista 7120t-4s... >> >> hot box. but you are giving away the secret sauce! > > Hot box for the datacenter, but small buffers make it unsuited for > long distances. In the right place, this box can't be beaten in the > price/performance realm. "Arista EOS" - what good/bad things do you have to say about their management capabilities? which "known" brand can it be compared to? thanks, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From voipuser at optonline.net Thu Mar 11 10:00:59 2010 From: voipuser at optonline.net (Abdul Nazeer) Date: Thu, 11 Mar 2010 11:00:59 -0500 Subject: Need advise for a linux firewall In-Reply-To: References: Message-ID: <4B9913BB.3030104@optonline.net> Looking for advise on setting up a linux based dedicated firewall. Apparently, there are plenty: http://en.wikipedia.org/wiki/List_of_router_or_firewall_distributions I'm looking to have the firewall sit in front of a public network of windows boxes. Also, would want to be able to load-balance and re-shape traffic inside the network. I was hoping to accomplish this using iptables, but if anyone has any other suggestion, I'd love to hear it. Thanks! Abdul Nazeer From aaron.urbain at gmail.com Thu Mar 11 10:12:56 2010 From: aaron.urbain at gmail.com (Aaron Urbain) Date: Thu, 11 Mar 2010 11:12:56 -0500 Subject: Need advise for a linux firewall In-Reply-To: <4B9913BB.3030104@optonline.net> References: <4B9913BB.3030104@optonline.net> Message-ID: fwbuilder From mirkomaffioli at gmail.com Thu Mar 11 10:16:20 2010 From: mirkomaffioli at gmail.com (Mirko Maffioli) Date: Thu, 11 Mar 2010 17:16:20 +0100 Subject: Need advise for a linux firewall In-Reply-To: <4B9913BB.3030104@optonline.net> References: <4B9913BB.3030104@optonline.net> Message-ID: <413ff53f1003110816v2a3eb74cq119025916402e70a@mail.gmail.com> try http://www.zeroshell.net/eng/ 2010/3/11 Abdul Nazeer : > Looking for advise on setting up a linux based dedicated firewall. > Apparently, there are plenty: > > http://en.wikipedia.org/wiki/List_of_router_or_firewall_distributions > > I'm looking to have the firewall sit in front of a public network of > windows boxes. Also, would want to be able to load-balance and re-shape > traffic inside the network. I was hoping to accomplish this using > iptables, but if anyone has any other suggestion, I'd love to hear it. > > Thanks! > Abdul Nazeer > > From gordslater at ieee.org Thu Mar 11 10:22:38 2010 From: gordslater at ieee.org (gordon b slater) Date: Thu, 11 Mar 2010 16:22:38 +0000 Subject: Need advise for a linux firewall In-Reply-To: <4B9913BB.3030104@optonline.net> References: <4B9913BB.3030104@optonline.net> Message-ID: <1268324558.10083.32.camel@ub-g-d2> On Thu, 2010-03-11 at 11:00 -0500, Abdul Nazeer wrote: > iptables, but if anyone has any other suggestion, I'd love to hear it. PFsense, (being freeBSD-based, comes under your "other" category) It uses the OpenBSD-based pf firewall, with a web-based GUI for almost everything (except maybe console resets). works for me in several locations, some `heavy and high`. One caveat for the current PFsense: traffic shaping in 1.2.3 release is somewhat borked (1.2.2 works much better) and it doesn't work with more than 2 interfaces, so 1 wan - 1 lan is OK. Check out the user forums for specifics scenario gotchas if any. There's a good (recent) book about it, covers 1.2.3 release, very good it is too, with lots of help for multi-wan, VLAN, IPsec, etc etc. Routes Gigabit nicely with "normal" (pci-e or pci-x) hardware. Check out the hardware sizing guide for examples. What I particularly like is the "alias" function, it makes working with huge groups of IPs easy. BGPd, etc are all available as packages - you can for example use minicom to get CLI via the console port into a cisco ADSL router or local SCADA kit Been stable for me for a couple of years now, several instances Oh, did I mention failover ? CARP Me like :) Gord -- rockin ze bedroom From sgridelli at gmail.com Thu Mar 11 10:50:43 2010 From: sgridelli at gmail.com (Stefano Gridelli) Date: Thu, 11 Mar 2010 11:50:43 -0500 Subject: Wireless Ethernet bridge In-Reply-To: References: <1b5c1c151003101423l4b35c2fck10eada542442603f@mail.gmail.com> Message-ID: The motorola PTP 600 seems thus far the most valid solution. We want to remain on ISM bands, because we don't want to take the burden of renewing the license with FCC every x years ... we need something that once installed requires the least maintenance effort possible. We already have antennas and cables that work with the 5.8 GHz spectrum. There's a distance of 3 miles between the two antennas and there's LOS available. The copper handoff could be solved with a media converter ... I am also proposed an Exalt EX-5i at 200 Mbps. Does anybody have this hardware installed and can share any experience had? Thanks On Wed, Mar 10, 2010 at 5:31 PM, Scott Brown/Clack/ESD < SBrown at clackesd.k12.or.us> wrote: > The Dragonwave would be my first choice too, but they are not in the 5.8GHz > band. > > The Motorola PTP-600 has a 2000 byte MTU, but doesn't do multimode handoff. > > What radio to get will come down to what you are willing to give up -- if > you are willing to drop the 5.8Ghz band and go with 11Ghz then the > Dragonwave is for you -- the new Horizon Quantum is amazing (and pretty > inexpensive when I priced it out) > > Bridgewave isn't bad either - you can get to 1.25Gbps with some fiber > handoff. > > > Scott > > Mike Lyon wrote on 03/10/2010 02:23:33 PM: > > > From: Mike Lyon > > To: Stefano Gridelli > > Cc: nanog at nanog.org > > Date: 03/10/2010 02:23 PM > > Subject: Re: Wireless Ethernet bridge > > > > Check out DragonWave: > > > > http://www.dragonwaveinc.com/ > > > > -Mike > > > > > > > > On Wed, Mar 10, 2010 at 2:18 PM, Stefano Gridelli > wrote: > > > > > Hi All, > > > > > > I need a wireless bridge solution that allows to pass jumbo frames over > a > > > distance of 3 miles, using the 5.8 GHz band. The original solution was > a > > > Proxim Tsunami GX 200, but unfortunately it doesn't go beyond an MTU of > > > 1536 > > > bytes: we need at least 1544 bytes, ideally between 4470 and 9212 bytes > > > MTU. The handoff should be MM fiber, the desired throughput 200 Mbps. > > > > > > Thanks, > > > Stefano > > > > > > From marty.anstey at sunwave.net Thu Mar 11 11:01:02 2010 From: marty.anstey at sunwave.net (Marty Anstey) Date: Thu, 11 Mar 2010 09:01:02 -0800 Subject: Need advise for a linux firewall In-Reply-To: <1268324558.10083.32.camel@ub-g-d2> References: <4B9913BB.3030104@optonline.net> <1268324558.10083.32.camel@ub-g-d2> Message-ID: <4B9921CE.5060009@sunwave.net> > > PFsense, (being freeBSD-based, comes under your "other" category) > It uses the OpenBSD-based pf firewall, with a web-based GUI for almost > everything (except maybe console resets). works for me in several > locations, some `heavy and high`. > > +1 for pfsense. I've been running it for over 18 months with no problems whatsoever. It does everything I needed it to do, and quite a bit more. -M From rekoil at semihuman.com Thu Mar 11 11:01:22 2010 From: rekoil at semihuman.com (Chris Woodfield) Date: Thu, 11 Mar 2010 12:01:22 -0500 Subject: IPv6 enabled carriers? In-Reply-To: <4B97F08B.2070500@rollernet.us> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> Message-ID: <9026A043-BBCD-4D97-853F-6749B86D33DB@semihuman.com> To pile on in the spirit of "if people don't complain, nothing will change" - is VZB still insisting on filtering >/32 at their peers? While ARIN is allocating /40s and /48s directly? -C On Mar 10, 2010, at 2:18 PM, Seth Mattinen wrote: > On 3/10/10 11:00 AM, Charles Mills wrote: >> Does anyone have a list of carriers who are IPv6 capable today? >> >> I would assume this would be rolled out in larger cities first but >> anything outside of "testbed environments" and "trials" as in >> Comcast's recent announcement seems to be all that is available. >> >> I'm being tasked with coming up with an IPv6 migration plan for a >> data center. >> >> Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business >> and Qwest are capable as those are the typical ones I deal with. >> > > Ones I have personal experience with: > > GLBX - yes > SAVVIS - no > VZB - yes, good luck > ATT - "Beginning in 1Q2010 MIS will provide the ability to support > IPv6 > in a dual stack mode." > > When I disconnected my SAVVIS circuit in November 2009 I explicitly > told > them IPv6 was a deciding factor. Not all of Verizon's pops are IPv6 > enabled, which may cause you trouble ordering it. It's put me in month > 11 of trying to turn up a dual-stack circuit because they refuse to > read > the order and keep putting it in Sacramento (v4 only) when it needs to > go to San Jose (dual-stack). Sprint wasn't on your list, but they are > rolling out native IPv6 support on all of 1239. I've been using their > 6175 testbed since 2005. > > ~Seth > From pstewart at nexicomgroup.net Thu Mar 11 11:01:29 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 11 Mar 2010 12:01:29 -0500 Subject: Wireless Ethernet bridge In-Reply-To: References: <1b5c1c151003101423l4b35c2fck10eada542442603f@mail.gmail.com> Message-ID: We love the PTP600 platform and it works very well for our needs - as good as any path profile has shown us. Depending on the height of the tower, you can handoff via copper or via multimode fiber (someone said it doesn't do multimode, we do it all the time with their "fiber kits" from Motorola). In all of our installs we use multimode and if the tower is short enough use cat5 as a backup connection. I'm not 100% on the MTU size but I'm pretty sure it supports at least "mini-jumbo". We are going to be pushing MPLS type traffic carrying VPLS paths across PTP600's this year and when we looked at any challenges we didn't find any on the surface.... Paul -----Original Message----- From: Stefano Gridelli [mailto:sgridelli at gmail.com] Sent: Thursday, March 11, 2010 11:51 AM To: Scott Brown/Clack/ESD Cc: nanog at nanog.org Subject: Re: Wireless Ethernet bridge The motorola PTP 600 seems thus far the most valid solution. We want to remain on ISM bands, because we don't want to take the burden of renewing the license with FCC every x years ... we need something that once installed requires the least maintenance effort possible. We already have antennas and cables that work with the 5.8 GHz spectrum. There's a distance of 3 miles between the two antennas and there's LOS available. The copper handoff could be solved with a media converter ... I am also proposed an Exalt EX-5i at 200 Mbps. Does anybody have this hardware installed and can share any experience had? Thanks On Wed, Mar 10, 2010 at 5:31 PM, Scott Brown/Clack/ESD < SBrown at clackesd.k12.or.us> wrote: > The Dragonwave would be my first choice too, but they are not in the 5.8GHz > band. > > The Motorola PTP-600 has a 2000 byte MTU, but doesn't do multimode handoff. > > What radio to get will come down to what you are willing to give up -- if > you are willing to drop the 5.8Ghz band and go with 11Ghz then the > Dragonwave is for you -- the new Horizon Quantum is amazing (and pretty > inexpensive when I priced it out) > > Bridgewave isn't bad either - you can get to 1.25Gbps with some fiber > handoff. > > > Scott > > Mike Lyon wrote on 03/10/2010 02:23:33 PM: > > > From: Mike Lyon > > To: Stefano Gridelli > > Cc: nanog at nanog.org > > Date: 03/10/2010 02:23 PM > > Subject: Re: Wireless Ethernet bridge > > > > Check out DragonWave: > > > > http://www.dragonwaveinc.com/ > > > > -Mike > > > > > > > > On Wed, Mar 10, 2010 at 2:18 PM, Stefano Gridelli > wrote: > > > > > Hi All, > > > > > > I need a wireless bridge solution that allows to pass jumbo frames over > a > > > distance of 3 miles, using the 5.8 GHz band. The original solution was > a > > > Proxim Tsunami GX 200, but unfortunately it doesn't go beyond an MTU of > > > 1536 > > > bytes: we need at least 1544 bytes, ideally between 4470 and 9212 bytes > > > MTU. The handoff should be MM fiber, the desired throughput 200 Mbps. > > > > > > Thanks, > > > Stefano > > > > > > ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From gordslater at ieee.org Thu Mar 11 11:06:11 2010 From: gordslater at ieee.org (gordon b slater) Date: Thu, 11 Mar 2010 17:06:11 +0000 Subject: Need advise for a linux firewall In-Reply-To: <4B9921CE.5060009@sunwave.net> References: <4B9913BB.3030104@optonline.net> <1268324558.10083.32.camel@ub-g-d2> <4B9921CE.5060009@sunwave.net> Message-ID: <1268327171.10083.38.camel@ub-g-d2> On Thu, 2010-03-11 at 09:01 -0800, Marty Anstey wrote: > +1 for pfsense. I've been running it for over 18 months with no problems > whatsoever. It does everything I needed it to do, and quite a bit more. actually, reading back on the nanog list for a few plays (playing catch-up here) pfsense would have made a good contender for the "best VPN appliance thread :) Gord -- ALERT: kitchen-sensor-03 reports over-temp From sethm at rollernet.us Thu Mar 11 11:10:59 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 11 Mar 2010 09:10:59 -0800 Subject: IPv6 enabled carriers? In-Reply-To: <9026A043-BBCD-4D97-853F-6749B86D33DB@semihuman.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> <9026A043-BBCD-4D97-853F-6749B86D33DB@semihuman.com> Message-ID: <4B992423.4040806@rollernet.us> On 3/11/10 9:01 AM, Chris Woodfield wrote: > To pile on in the spirit of "if people don't complain, nothing will > change" - is VZB still insisting on filtering >/32 at their peers? While > ARIN is allocating /40s and /48s directly? > As far as I know, yes. ~Seth From r.engehausen at gmail.com Thu Mar 11 11:42:52 2010 From: r.engehausen at gmail.com (Roy) Date: Thu, 11 Mar 2010 09:42:52 -0800 Subject: Wireless Ethernet bridge In-Reply-To: References: <1b5c1c151003101423l4b35c2fck10eada542442603f@mail.gmail.com> Message-ID: <4B992B9C.5020105@gmail.com> Airaya will do 1600 bytes packets. http://www.airaya.com/ On 3/11/2010 8:50 AM, Stefano Gridelli wrote: > The motorola PTP 600 seems thus far the most valid solution. We want to > remain on ISM bands, because we don't want to take the burden of renewing > the license with FCC every x years ... we need something that once installed > requires the least maintenance effort possible. > We already have antennas and cables that work with the 5.8 GHz spectrum. > There's a distance of 3 miles between the two antennas and there's LOS > available. > The copper handoff could be solved with a media converter ... > > I am also proposed an Exalt EX-5i at 200 Mbps. Does anybody have this > hardware installed and can share any experience had? > > Thanks > > On Wed, Mar 10, 2010 at 5:31 PM, Scott Brown/Clack/ESD< > SBrown at clackesd.k12.or.us> wrote: > > >> The Dragonwave would be my first choice too, but they are not in the 5.8GHz >> band. >> >> The Motorola PTP-600 has a 2000 byte MTU, but doesn't do multimode handoff. >> >> What radio to get will come down to what you are willing to give up -- if >> you are willing to drop the 5.8Ghz band and go with 11Ghz then the >> Dragonwave is for you -- the new Horizon Quantum is amazing (and pretty >> inexpensive when I priced it out) >> >> Bridgewave isn't bad either - you can get to 1.25Gbps with some fiber >> handoff. >> >> >> Scott >> >> Mike Lyon wrote on 03/10/2010 02:23:33 PM: >> >> >>> From: Mike Lyon >>> To: Stefano Gridelli >>> Cc: nanog at nanog.org >>> Date: 03/10/2010 02:23 PM >>> Subject: Re: Wireless Ethernet bridge >>> >>> Check out DragonWave: >>> >>> http://www.dragonwaveinc.com/ >>> >>> -Mike >>> >>> >>> >>> On Wed, Mar 10, 2010 at 2:18 PM, Stefano Gridelli >>> >> wrote: >> >>> >>>> Hi All, >>>> >>>> I need a wireless bridge solution that allows to pass jumbo frames over >>>> >> a >> >>>> distance of 3 miles, using the 5.8 GHz band. The original solution was >>>> >> a >> >>>> Proxim Tsunami GX 200, but unfortunately it doesn't go beyond an MTU of >>>> 1536 >>>> bytes: we need at least 1544 bytes, ideally between 4470 and 9212 bytes >>>> MTU. The handoff should be MM fiber, the desired throughput 200 Mbps. >>>> >>>> Thanks, >>>> Stefano >>>> >>>> >> >> >> > From trejrco at gmail.com Thu Mar 11 11:54:24 2010 From: trejrco at gmail.com (TJ) Date: Thu, 11 Mar 2010 12:54:24 -0500 Subject: IPv6 enabled carriers? In-Reply-To: <9026A043-BBCD-4D97-853F-6749B86D33DB@semihuman.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> <9026A043-BBCD-4D97-853F-6749B86D33DB@semihuman.com> Message-ID: <71bfd60c1003110954v2dcb4f6awdca72690f559d315@mail.gmail.com> On Thu, Mar 11, 2010 at 12:01 PM, Chris Woodfield wrote: > To pile on in the spirit of "if people don't complain, nothing will change" > - is VZB still insisting on filtering >/32 at their peers? While ARIN is > allocating /40s and /48s directly? > I believe so ... will be even more impactful as LTE gets deployed. Another nit - They are also blocking Protocol41 on their EV-DO network. While this is a 'noble, if poorly thought out, effort' to prevent IPv6 from impacting their cel phone users - it kind of messes up those of us who have aircards (and got used to 6to4 for quick and dirty IPv6 connectivity). /TJ From setient at gmail.com Thu Mar 11 12:07:42 2010 From: setient at gmail.com (Ronald Cotoni) Date: Thu, 11 Mar 2010 13:07:42 -0500 Subject: Need advise for a linux firewall In-Reply-To: <1268327171.10083.38.camel@ub-g-d2> References: <4B9913BB.3030104@optonline.net> <1268324558.10083.32.camel@ub-g-d2> <4B9921CE.5060009@sunwave.net> <1268327171.10083.38.camel@ub-g-d2> Message-ID: <2f1d68351003111007g6fe7a2c3n534bfc33e800623f@mail.gmail.com> On Thu, Mar 11, 2010 at 12:06 PM, gordon b slater wrote: > On Thu, 2010-03-11 at 09:01 -0800, Marty Anstey wrote: > >> +1 for pfsense. I've been running it for over 18 months with no problems >> whatsoever. It does everything I needed it to do, and quite a bit more. > > > actually, reading back on the nanog list for a few plays (playing > catch-up here) pfsense would have made a good contender for the "best > VPN appliance thread :) > > Gord > > -- > ALERT: kitchen-sensor-03 reports over-temp > > > I use PFsense 1.2.3 in my office environment with 4 nics, 2 100 mbit and 2 gigabit. I have different network segments and all are sharing the same internet connection. It works great and has been online since we moved into this new office a month ago. I also use it as a VPN end point for when I need to troubleshoot our network and I am out and about. It is great and can also do other office type filtering/monitoring. It has Squid plugins, IMSPector plugins and it also can do tcpdumps (very useful IMHO) Ronald Cotoni From lists at billfehring.com Thu Mar 11 12:10:47 2010 From: lists at billfehring.com (Bill Fehring) Date: Thu, 11 Mar 2010 10:10:47 -0800 Subject: ethernet to serial converters with ACLs In-Reply-To: <0B608FCDCF43BF4C9194C896C532024371A993@mnsg-svr2.mnsg.net> References: <4B97FE71.8090700@csuohio.edu> <0B608FCDCF43BF4C9194C896C532024371A993@mnsg-svr2.mnsg.net> Message-ID: On Wed, Mar 10, 2010 at 19:06, R. Benjamin Kessler wrote:> > On a similar topic, any good solutions for out-of-band serial > console/Ethernet solutions that use EV-DO/GSM wireless Internet? Check these out: http://www.opengear.com/product-acm5000.html From joelm at freewirebroadband.com Thu Mar 11 12:10:55 2010 From: joelm at freewirebroadband.com (Joel Mulkey) Date: Thu, 11 Mar 2010 10:10:55 -0800 Subject: Wireless Ethernet bridge In-Reply-To: References: <1b5c1c151003101423l4b35c2fck10eada542442603f@mail.gmail.com> Message-ID: We have used the 2.4GHz version of the Exalt radio - the EX-2.4i. We were fairly happy with it. The latency and jitter was great for a TDD radio, better than any I have seen. It was very reliable from a data-forwarding perspective. The management interface was nice when it worked, but the HTTP interface would lock up after extended periods of operation. We also got unusable values from some of the SNMP error/discard counters. In the end we took it out due to the need for more bandwidth and some issues with intermittent interference (to be expected in 2.4GHz). If the specs meet your needs then it would probably be a good solution. Joel Mulkey CIO Freewire Broadband Direct: 503-616-2557 | Support: 503-614-8282 http://www.gofreewire.com http://twitter.com/FreewireNetwork On Mar 11, 2010, at 8:50 AM, Stefano Gridelli wrote: > The motorola PTP 600 seems thus far the most valid solution. We want to > remain on ISM bands, because we don't want to take the burden of renewing > the license with FCC every x years ... we need something that once installed > requires the least maintenance effort possible. > We already have antennas and cables that work with the 5.8 GHz spectrum. > There's a distance of 3 miles between the two antennas and there's LOS > available. > The copper handoff could be solved with a media converter ... > > I am also proposed an Exalt EX-5i at 200 Mbps. Does anybody have this > hardware installed and can share any experience had? > > Thanks > > On Wed, Mar 10, 2010 at 5:31 PM, Scott Brown/Clack/ESD < > SBrown at clackesd.k12.or.us> wrote: > >> The Dragonwave would be my first choice too, but they are not in the 5.8GHz >> band. >> >> The Motorola PTP-600 has a 2000 byte MTU, but doesn't do multimode handoff. >> >> What radio to get will come down to what you are willing to give up -- if >> you are willing to drop the 5.8Ghz band and go with 11Ghz then the >> Dragonwave is for you -- the new Horizon Quantum is amazing (and pretty >> inexpensive when I priced it out) >> >> Bridgewave isn't bad either - you can get to 1.25Gbps with some fiber >> handoff. >> >> >> Scott >> >> Mike Lyon wrote on 03/10/2010 02:23:33 PM: >> >>> From: Mike Lyon >>> To: Stefano Gridelli >>> Cc: nanog at nanog.org >>> Date: 03/10/2010 02:23 PM >>> Subject: Re: Wireless Ethernet bridge >>> >>> Check out DragonWave: >>> >>> http://www.dragonwaveinc.com/ >>> >>> -Mike >>> >>> >>> >>> On Wed, Mar 10, 2010 at 2:18 PM, Stefano Gridelli >> wrote: >>> >>>> Hi All, >>>> >>>> I need a wireless bridge solution that allows to pass jumbo frames over >> a >>>> distance of 3 miles, using the 5.8 GHz band. The original solution was >> a >>>> Proxim Tsunami GX 200, but unfortunately it doesn't go beyond an MTU of >>>> 1536 >>>> bytes: we need at least 1544 bytes, ideally between 4470 and 9212 bytes >>>> MTU. The handoff should be MM fiber, the desired throughput 200 Mbps. >>>> >>>> Thanks, >>>> Stefano >>>> >> >> >> From bogstad at pobox.com Thu Mar 11 12:16:05 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Thu, 11 Mar 2010 13:16:05 -0500 Subject: IP4 Space In-Reply-To: <88A50944-0767-48A5-A631-28E84B3CE587@senie.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> <4B983C05.7030202@jsbc.cc> <88A50944-0767-48A5-A631-28E84B3CE587@senie.com> Message-ID: <2d6a9f6f1003111016t16ddc73frc4a430e22089149d@mail.gmail.com> On Wed, Mar 10, 2010 at 10:00 PM, Daniel Senie wrote: > Well, it's like this... there's still no native IPv6 connectivity in most data centers, residences, >businesses or wireless, most vendors of networking equipment have not had a lot of mileage on >their IPv6 code if they even have it fully working, and, frankly, the IPv6 community has been >predicting a falling sky for so long that people just gave up listening. Add in a whole lot of other bits >of argument that just exasperate those dealing with today's problems, and it's pretty easy to >understand, if you've not been one of the ones pushing IPV6 for all these years, that there's a lot of >listener fatigue. I fall into this category, but I'm trying to get better. This may be OT for this forum, but as someone whose network admin hat has mostly been at the LAN/MAN level, I'm less concerned about IPv6 peering, etc. then I am with what applications/servers don't play well with IPv6 and how do I work around those issues. Where does one go to find out how organizations have switched their internal IT infrastructure to IPv6? Does it make sense/work to do this for internal operations even if our outside connections are IPv4 only (forget about tunneling). Even more mundane questions like how to deal with IPv4 only networked printers when everything else is IPv6? If anyone in the Boston metro area wants to present to the local system administrators group (www.bblisa.org) on why we should care (and more importantly what to do) please contact me off list. We're mostly a bunch of senior Unix system administrator who are comfortable in our IPv4 world and (I think) see IPv6 as a whole bunch of work to mostly get back to where we already are. We've all heard about the coming address apocalypse, but it always seems somewhere in the distant future. Thanks, Bill Bogstad From mvh at hosteurope.de Thu Mar 11 12:25:19 2010 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Thu, 11 Mar 2010 19:25:19 +0100 Subject: 10GBase-t switch In-Reply-To: <017265BF3B9640499754DD48777C3D2067B738F2A9@MBX9.EXCHPROD.USA.NET> References: <20100311060407.13AFB1CC0D@ptavv.es.net> <4B990321.10908@ipax.at> <017265BF3B9640499754DD48777C3D2067B738F2A9@MBX9.EXCHPROD.USA.NET> Message-ID: <4B99358F.6020802@hosteurope.de> Hi, Am 11.03.10 16:29 schrieb Dylan Ebner: > Do the Arista switches support netflow? nothing about it in the datasheets, and regarding documentation: "A registered account and a valid support contract is required to access the Software Download and Documentation section of the website." Service fail. .m -- Malte von dem Hagen Teamleitung Network Engineering & Operation Abteilung Technik ----------------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de Welserstra?e 14 - 51149 K?ln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht K?ln - USt-IdNr.: DE187370678 Gesch?ftsf?hrer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulverm?ller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From mvh at hosteurope.de Thu Mar 11 12:26:27 2010 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Thu, 11 Mar 2010 19:26:27 +0100 Subject: 10GBase-t switch In-Reply-To: <4B990321.10908@ipax.at> References: <20100311060407.13AFB1CC0D@ptavv.es.net> <4B990321.10908@ipax.at> Message-ID: <4B9935D3.1010508@hosteurope.de> Hi, Am 11.03.10 15:50 schrieb Raoul Bhatia [IPAX]: > which "known" brand can it be compared to? the CLI looks IOSish. Pity. .m -- Malte von dem Hagen Teamleitung Network Engineering & Operation Abteilung Technik ----------------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de Welserstra?e 14 - 51149 K?ln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht K?ln - USt-IdNr.: DE187370678 Gesch?ftsf?hrer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulverm?ller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Thu Mar 11 12:30:02 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 11 Mar 2010 19:30:02 +0100 Subject: Filtered 6to4, what else to use (Re: IPv6 enabled carriers?) In-Reply-To: <71bfd60c1003110954v2dcb4f6awdca72690f559d315@mail.gmail.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> <9026A043-BBCD-4D97-853F-6749B86D33DB@semihuman.com> <71bfd60c1003110954v2dcb4f6awdca72690f559d315@mail.gmail.com> Message-ID: <4B9936AA.2090407@spaghetti.zurich.ibm.com> TJ wrote: > On Thu, Mar 11, 2010 at 12:01 PM, Chris Woodfield wrote: > >> To pile on in the spirit of "if people don't complain, nothing will change" >> - is VZB still insisting on filtering >/32 at their peers? While ARIN is >> allocating /40s and /48s directly? >> > > I believe so ... will be even more impactful as LTE gets deployed. > > Another nit - They are also blocking Protocol41 on their EV-DO network. > While this is a 'noble, if poorly thought out, effort' to prevent IPv6 from > impacting their cel phone users - it kind of messes up those of us who have > aircards (and got used to 6to4 for quick and dirty IPv6 connectivity). If you want quick&dirty then 6to4 is not going to help you in most cases anyway, as you are mostly landing behind a NAT, as such Teredo (miredo on non-windows boxes) is a way out and there is of course TSP which can run over TSP and AYIYA. For some magical reason I prefer the last ;) Also note that is it is their network, they can filter all they want, just like you do you in your own. (How did you btw determine that it is filtered, maybe the 6to4 packets are just not coming back from a broken relay somewhere, that is very hard to determine) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From dhubbard at dino.hostasaurus.com Thu Mar 11 12:31:23 2010 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 11 Mar 2010 13:31:23 -0500 Subject: 10GBase-t switch Message-ID: From: Malte von dem Hagen [mailto:mvh at hosteurope.de] > > Hi, > > Am 11.03.10 16:29 schrieb Dylan Ebner: > > Do the Arista switches support netflow? > > nothing about it in the datasheets, and regarding documentation: > > "A registered account and a valid support contract is > required to access the > Software Download and Documentation section of the website." > > Service fail. +1 After Brocade started doing that with the Foundry docs, which hung me out to dry one night when I needed some docs I didn't have easy access to, I decided I will try to avoid buying from companies that require a support contract to read the manual. David From Wesley.E.George at sprint.com Thu Mar 11 12:35:14 2010 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 11 Mar 2010 12:35:14 -0600 Subject: IPv6 enabled carriers? In-Reply-To: <4B97F08B.2070500@rollernet.us> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> Message-ID: -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Wednesday, March 10, 2010 2:19 PM To: nanog at nanog.org Subject: Re: IPv6 enabled carriers? On 3/10/10 11:00 AM, Charles Mills wrote: > Does anyone have a list of carriers who are IPv6 capable today? > Sprint wasn't on your list, but they are rolling out native IPv6 support on all of 1239. I've been using their 6175 testbed since 2005. ~Seth Not trying to make a big shameless plug here, but I thought I should at least confirm this to be true. Mostly domestic until ~mid-year, limited port availability in the next couple of months, more sites and port speeds available as the year and the rollout progresses. www.sprintv6.net or your Sprint sales droid will have updates as they're available. Thanks, Wes _________________________________ Wesley George Sprint Core Network Engineering - IP O:703-689-7505 M:703-864-4902 http://www.sprint.net This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From Greg.Whynott at oicr.on.ca Thu Mar 11 12:43:21 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Thu, 11 Mar 2010 13:43:21 -0500 Subject: 10GBase-t switch In-Reply-To: References: Message-ID: I will likely never buy or recommend Foundry equipment again. In a previous gig, a HPC enviorment, they caused us many problems, support was horrible, and thier 10Gbit kit was the pits when it was first released (no idea how it is now or what they offer, its been 5 years since. burnt once, twice shy). We replaced most all our Foundry L2 gear with HP 8212s which met our expectations. Brocade is the king of license gouging, it is no surprise they want money to view a pdf. Force10 and Extreme are both having sales this month on 24 port 10Gbit switches, $20k off almost. -g ________________________________________ From: David Hubbard [dhubbard at dino.hostasaurus.com] Sent: Thursday, March 11, 2010 1:31 PM To: nanog at nanog.org Subject: RE: 10GBase-t switch From: Malte von dem Hagen [mailto:mvh at hosteurope.de] > > Hi, > > Am 11.03.10 16:29 schrieb Dylan Ebner: > > Do the Arista switches support netflow? > > nothing about it in the datasheets, and regarding documentation: > > "A registered account and a valid support contract is > required to access the > Software Download and Documentation section of the website." > > Service fail. +1 After Brocade started doing that with the Foundry docs, which hung me out to dry one night when I needed some docs I didn't have easy access to, I decided I will try to avoid buying from companies that require a support contract to read the manual. David From voipuser at optonline.net Thu Mar 11 13:26:02 2010 From: voipuser at optonline.net (Abdul Nazeer) Date: Thu, 11 Mar 2010 14:26:02 -0500 Subject: Need advise for a linux firewall In-Reply-To: <1268324558.10083.32.camel@ub-g-d2> References: <4B9913BB.3030104@optonline.net> <1268324558.10083.32.camel@ub-g-d2> Message-ID: <4B9943CA.7070405@optonline.net> On 03/11/2010 11:22 AM, gordon b slater wrote: > On Thu, 2010-03-11 at 11:00 -0500, Abdul Nazeer wrote: > > >> iptables, but if anyone has any other suggestion, I'd love to hear it. >> > PFsense, (being freeBSD-based, comes under your "other" category) > It uses the OpenBSD-based pf firewall, with a web-based GUI for almost > everything (except maybe console resets). works for me in several > locations, some `heavy and high`. > Looks interesting. Will give it a shot, thanks! From stljim at gmail.com Thu Mar 11 13:45:32 2010 From: stljim at gmail.com (Jim Miller) Date: Fri, 12 Mar 2010 00:15:32 +0430 Subject: Need advise for a linux firewall In-Reply-To: <4B9943CA.7070405@optonline.net> References: <4B9913BB.3030104@optonline.net> <1268324558.10083.32.camel@ub-g-d2> <4B9943CA.7070405@optonline.net> Message-ID: <5e382f341003111145p61e4bdf6xfa8b80b6d82e9ff1@mail.gmail.com> On Thu, Mar 11, 2010 at 11:56 PM, Abdul Nazeer wrote: > On 03/11/2010 11:22 AM, gordon b slater wrote: > > On Thu, 2010-03-11 at 11:00 -0500, Abdul Nazeer wrote: > > > > > >> iptables, but if anyone has any other suggestion, I'd love to hear it. > >> > > PFsense, (being freeBSD-based, comes under your "other" category) > > It uses the OpenBSD-based pf firewall, with a web-based GUI for almost > > everything (except maybe console resets). works for me in several > > locations, some `heavy and high`. > > > Looks interesting. Will give it a shot, thanks! > > For a very long time I used the following setup with great success: 1. Debian based linux for the firewall box. With Debian you can do a very light setup. 2. FWBuilder to builder for the GUI front end. It's been around for quite a long time now and has built in RCS for revision control. 3. Quagga for OSPF routing.. We only had about .. 4-5 firewalls but made a lot of internal routing changes and OSPF _really_ made things easy when we made changes 4. OpenVPN for after-hours access and off-site staff access. Anyway, just my $0.02 --Jim From owen at delong.com Thu Mar 11 14:04:31 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 11 Mar 2010 12:04:31 -0800 Subject: IP4 Space In-Reply-To: <2d6a9f6f1003111016t16ddc73frc4a430e22089149d@mail.gmail.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> <4B983C05.7030202@jsbc.cc> <88A50944-0767-48A5-A631-28E84B3CE587@senie.com> <2d6a9f6f1003111016t16ddc73frc4a430e22089149d@mail.gmail.com> Message-ID: On Mar 11, 2010, at 10:16 AM, Bill Bogstad wrote: > On Wed, Mar 10, 2010 at 10:00 PM, Daniel Senie wrote: >> Well, it's like this... there's still no native IPv6 connectivity >> in most data centers, residences, >businesses or wireless, most >> vendors of networking equipment have not had a lot of mileage on >> >their IPv6 code if they even have it fully working, and, frankly, >> the IPv6 community has been >predicting a falling sky for so long >> that people just gave up listening. Add in a whole lot of other >> bits >of argument that just exasperate those dealing with today's >> problems, and it's pretty easy to >understand, if you've not been >> one of the ones pushing IPV6 for all these years, that there's a >> lot of >listener fatigue. > > I fall into this category, but I'm trying to get better. This may be > OT for this forum, but as someone whose network admin hat has mostly > been at the LAN/MAN level, I'm less concerned about IPv6 peering, etc. > then I am with what applications/servers don't play well with IPv6 and > how do I work around those issues. Where does one go to find out how > organizations have switched their internal IT infrastructure to IPv6? > Does it make sense/work to do this for internal operations even if our > outside connections are IPv4 only (forget about tunneling). Even more > mundane questions like how to deal with IPv4 only networked printers > when everything else is IPv6? > First, it's best not to approach this as switching to IPv6. Think of it, instead, for now, as adding IPv6 capability to as much of your IPv4 environment as possible. I don't know of any applications which are negatively impacted by having IPv6 capabilities. Several end-user applications do not play well if you remove their IPv4 capabilities, although that is getting fixed for the most popular internet-oriented ones fairly quickly. The most important things to get on dual stack initially all play well. These would include your internet-facing services such as your mail gateway, web servers, etc. > If anyone in the Boston metro area wants to present to the local > system administrators group > (www.bblisa.org) on why we should care (and more importantly what to > do) please contact me off list. We're mostly a bunch of senior Unix > system administrator who are comfortable in our IPv4 world > and (I think) see IPv6 as a whole bunch of work to mostly get back to > where we already are. We've all heard about the coming address > apocalypse, but it always seems somewhere in the distant future. > If you can get 50 people or more in the room, I'd be happy to come present to your group. Hurricane Electric will pay my travel. Owen From davet1 at gmail.com Thu Mar 11 14:51:00 2010 From: davet1 at gmail.com (Dave Temkin) Date: Thu, 11 Mar 2010 12:51:00 -0800 Subject: 10GBase-t switch In-Reply-To: <20100311060407.13AFB1CC0D@ptavv.es.net> References: <20100311060407.13AFB1CC0D@ptavv.es.net> Message-ID: <4B9957B4.7080009@gmail.com> Kevin Oberman wrote: >> Date: Thu, 11 Mar 2010 12:26:16 +0900 >> From: Randy Bush >> >> >>> arista 7120t-4s... >>> >> hot box. but you are giving away the secret sauce! >> > > Hot box for the datacenter, but small buffers make it unsuited for > long distances. In the right place, this box can't be beaten in the > price/performance realm. > > Can you point to another 1U box that has more than 16MB per-port buffer? -Dave From trejrco at gmail.com Thu Mar 11 15:08:40 2010 From: trejrco at gmail.com (TJ) Date: Thu, 11 Mar 2010 16:08:40 -0500 Subject: Filtered 6to4, what else to use (Re: IPv6 enabled carriers?) In-Reply-To: <4B9936AA.2090407@spaghetti.zurich.ibm.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> <9026A043-BBCD-4D97-853F-6749B86D33DB@semihuman.com> <71bfd60c1003110954v2dcb4f6awdca72690f559d315@mail.gmail.com> <4B9936AA.2090407@spaghetti.zurich.ibm.com> Message-ID: <71bfd60c1003111308k14aefcafm5ef5b40fffa3e041@mail.gmail.com> On Thu, Mar 11, 2010 at 1:30 PM, Jeroen Massar wrote: > TJ wrote: > > On Thu, Mar 11, 2010 at 12:01 PM, Chris Woodfield >wrote: > > > >> To pile on in the spirit of "if people don't complain, nothing will > change" > >> - is VZB still insisting on filtering >/32 at their peers? While ARIN is > >> allocating /40s and /48s directly? > >> > > > > I believe so ... will be even more impactful as LTE gets deployed. > > > > Another nit - They are also blocking Protocol41 on their EV-DO network. > > While this is a 'noble, if poorly thought out, effort' to prevent IPv6 > from > > impacting their cel phone users - it kind of messes up those of us who > have > > aircards (and got used to 6to4 for quick and dirty IPv6 connectivity). > > If you want quick&dirty then 6to4 is not going to help you in most cases > anyway, as you are mostly landing behind a NAT, as such Teredo (miredo > on non-windows boxes) is a way out and there is of course TSP which can > run over TSP and AYIYA. For some magical reason I prefer the last ;) > In general, yes - but VZW's EV-DO (currently) always hands-out a public IP ... > Also note that is it is their network, they can filter all they want, > just like you do you in your own. > Sure, and ISPs that do this (too much) get bad press and lose customers ... > > (How did you btw determine that it is filtered, maybe the 6to4 packets > are just not coming back from a broken relay somewhere, that is very > hard to determine) > Because someone (who may have been employed by my employer) showed them that cel phones were horrendously exposed (I am looking at you, Windows Mobile devices) to IPv6 via Prot41 ... and their answer, rather than fix the problem, was to just block Prot41 (whether this is an ACL or they black-hole 192.88.99.1 I don't care, they should (IMHO) stop). Atleast that was what I heard, and 6to4 currently fails - leading me to believe this to be the case. (I also believe they are munging AAAAs queries or replies, but haven't taken the time to poke into that or work around it as I just use less-quick and less-dirty IPv6 connectivity - which may include the options you plugged :) ) -- /TJ From arnold at nipper.de Thu Mar 11 15:20:41 2010 From: arnold at nipper.de (Arnold Nipper) Date: Thu, 11 Mar 2010 22:20:41 +0100 Subject: 10GBase-t switch In-Reply-To: <017265BF3B9640499754DD48777C3D2067B738F2A9@MBX9.EXCHPROD.USA.NET> References: <20100311060407.13AFB1CC0D@ptavv.es.net> <4B990321.10908@ipax.at> <017265BF3B9640499754DD48777C3D2067B738F2A9@MBX9.EXCHPROD.USA.NET> Message-ID: <4B995EA9.2050708@nipper.de> On 11.03.2010 16:29 Dylan Ebner wrote > Do the Arista switches support netflow? From a management perspective > netflow can be vital. This is something we have been unhappy with on > our 3560 and 3750 cisco's. > They don't (yet). Given you buy enoughboxes, Arista may be willing to implement this feature. Would like to have this as well. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From pl+list at pmacct.net Thu Mar 11 15:30:38 2010 From: pl+list at pmacct.net (Paolo Lucente) Date: Thu, 11 Mar 2010 21:30:38 +0000 Subject: 10GBase-t switch In-Reply-To: <4B995EA9.2050708@nipper.de> References: <20100311060407.13AFB1CC0D@ptavv.es.net> <4B990321.10908@ipax.at> <017265BF3B9640499754DD48777C3D2067B738F2A9@MBX9.EXCHPROD.USA.NET> <4B995EA9.2050708@nipper.de> Message-ID: <20100311213038.GA7593@moussaka.pmacct.net> On Thu, Mar 11, 2010 at 10:20:41PM +0100, Arnold Nipper wrote: > On 11.03.2010 16:29 Dylan Ebner wrote > > > Do the Arista switches support netflow? From a management perspective > > netflow can be vital. This is something we have been unhappy with on > > our 3560 and 3750 cisco's. > > > > They don't (yet). Given you buy enoughboxes, Arista may be willing to > implement this feature. Would like to have this as well. And if you have to request a vendor of L2 devices to implement something in this sense then definitely ask for sFlow. Cheers, Paolo From morrowc.lists at gmail.com Thu Mar 11 16:05:09 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Mar 2010 17:05:09 -0500 Subject: IPv6 enabled carriers? In-Reply-To: <71bfd60c1003110954v2dcb4f6awdca72690f559d315@mail.gmail.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> <9026A043-BBCD-4D97-853F-6749B86D33DB@semihuman.com> <71bfd60c1003110954v2dcb4f6awdca72690f559d315@mail.gmail.com> Message-ID: <75cb24521003111405i30822f9ambfdd7ec4eece9260@mail.gmail.com> On Thu, Mar 11, 2010 at 12:54 PM, TJ wrote: > On Thu, Mar 11, 2010 at 12:01 PM, Chris Woodfield wrote: > >> To pile on in the spirit of "if people don't complain, nothing will change" >> - is VZB still insisting on filtering >/32 at their peers? While ARIN is >> allocating /40s and /48s directly? >> > > I believe so ... will be even more impactful as LTE gets deployed. how so exactly?? LTE is really just a 'last mile' tech... whether it's v4 or v6 doesnt' seem to matter (to the fact that it's LTE) > Another nit - They are also blocking Protocol41 on their EV-DO network. vzw not vzb > While this is a 'noble, if poorly thought out, effort' to prevent IPv6 from > impacting their cel phone users - it kind of messes up those of us who have > aircards (and got used to 6to4 for quick and dirty IPv6 connectivity). there are other carriers ya know? From cb.list6 at gmail.com Thu Mar 11 16:18:35 2010 From: cb.list6 at gmail.com (cb.list6 at gmail.com) Date: Thu, 11 Mar 2010 22:18:35 +0000 Subject: IPv6 enabled carriers? In-Reply-To: <75cb24521003111405i30822f9ambfdd7ec4eece9260@mail.gmail.com> Message-ID: <0016e64be064c2995d04818dcb6b@google.com> On Mar 11, 2010 2:05pm, Christopher Morrow wrote: > On Thu, Mar 11, 2010 at 12:54 PM, TJ trejrco at gmail.com> wrote: > > On Thu, Mar 11, 2010 at 12:01 PM, Chris Woodfield > rekoil at semihuman.com>wrote: > > > >> To pile on in the spirit of "if people don't complain, nothing will > change" > >> - is VZB still insisting on filtering >/32 at their peers? While ARIN > is > >> allocating /40s and /48s directly? > >> > > > > I believe so ... will be even more impactful as LTE gets deployed. > how so exactly?? LTE is really just a 'last mile' tech... whether it's > v4 or v6 doesnt' seem to matter (to the fact that it's LTE) Agreed. But, the hope is that LTE will be a "green field" IPv6 deployment both to the end-user device and in the infrastructure. There are some material difference in LTE (dual-stack bearers) that make LTE more IPv6 friendly. > > Another nit - They are also blocking Protocol41 on their EV-DO network. > vzw not vzb > > While this is a 'noble, if poorly thought out, effort' to prevent IPv6 > from > > impacting their cel phone users - it kind of messes up those of us who > have > > aircards (and got used to 6to4 for quick and dirty IPv6 connectivity). > there are other carriers ya know? And, some of those carriers, are working very hard to deploy native IPv6 to the customer, and have beta networks on the air now. http://www.ietf.org/mail-archive/web/3gv6/current/msg00269.html -Cameron [t-mobile employee] From oberman at es.net Thu Mar 11 16:19:15 2010 From: oberman at es.net (Kevin Oberman) Date: Thu, 11 Mar 2010 14:19:15 -0800 Subject: 10GBase-t switch In-Reply-To: Your message of "Thu, 11 Mar 2010 12:51:00 PST." <4B9957B4.7080009@gmail.com> Message-ID: <20100311221915.0206C1CC18@ptavv.es.net> > Date: Thu, 11 Mar 2010 12:51:00 -0800 > From: Dave Temkin > > Kevin Oberman wrote: > >> Date: Thu, 11 Mar 2010 12:26:16 +0900 > >> From: Randy Bush > >> > >> > >>> arista 7120t-4s... > >>> > >> hot box. but you are giving away the secret sauce! > >> > > > > Hot box for the datacenter, but small buffers make it unsuited for > > long distances. In the right place, this box can't be beaten in the > > price/performance realm. > > > > > Can you point to another 1U box that has more than 16MB per-port buffer? I cannot. It's just that this is not enough buffer for longer distances with multiple well loaded ports. As I keep saying, this is the best price/performance box I have seen. I am not criticizing it, just pointing out that it may not be the solution to all purposes. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From w.d.clayton at gmail.com Thu Mar 11 17:54:04 2010 From: w.d.clayton at gmail.com (Will Clayton) Date: Thu, 11 Mar 2010 17:54:04 -0600 Subject: Need advise for a linux firewall In-Reply-To: <5e382f341003111145p61e4bdf6xfa8b80b6d82e9ff1@mail.gmail.com> References: <4B9913BB.3030104@optonline.net> <1268324558.10083.32.camel@ub-g-d2> <4B9943CA.7070405@optonline.net> <5e382f341003111145p61e4bdf6xfa8b80b6d82e9ff1@mail.gmail.com> Message-ID: <69069bc21003111554q5adfd820h78458ab8bdf9c7a7@mail.gmail.com> Microtik makes a pretty robust Linux based firewall appliance-on-a-usb-stick. It does a lot out of the box like BGP, VPN, MPLS,QoS and all kinds of other crazy things you wouldn't expect to fit on one gig of flash. It takes my HP about 10 seconds to load a full table. My vote is for PFSense though. PF is a lot of fun itself and I have seen awesome throughput with no load on very low end hardware. On Thu, Mar 11, 2010 at 1:45 PM, Jim Miller wrote: > On Thu, Mar 11, 2010 at 11:56 PM, Abdul Nazeer >wrote: > > > On 03/11/2010 11:22 AM, gordon b slater wrote: > > > On Thu, 2010-03-11 at 11:00 -0500, Abdul Nazeer wrote: > > > > > > > > >> iptables, but if anyone has any other suggestion, I'd love to hear it. > > >> > > > PFsense, (being freeBSD-based, comes under your "other" category) > > > It uses the OpenBSD-based pf firewall, with a web-based GUI for almost > > > everything (except maybe console resets). works for me in several > > > locations, some `heavy and high`. > > > > > Looks interesting. Will give it a shot, thanks! > > > > For a very long time I used the following setup with great success: > 1. Debian based linux for the firewall box. With Debian you can do a very > light setup. > 2. FWBuilder to builder for the GUI front end. It's been around for quite > a > long time now and has built in RCS for revision control. > 3. Quagga for OSPF routing.. We only had about .. 4-5 firewalls but made a > lot of internal routing changes and OSPF _really_ made things easy when we > made changes > 4. OpenVPN for after-hours access and off-site staff access. > > Anyway, just my $0.02 > > --Jim > From Michael.Balasko at cityofhenderson.com Thu Mar 11 18:23:59 2010 From: Michael.Balasko at cityofhenderson.com (Michael Balasko) Date: Thu, 11 Mar 2010 16:23:59 -0800 Subject: 10GBase-t switch In-Reply-To: <20100311221915.0206C1CC18@ptavv.es.net> References: Your message of "Thu, 11 Mar 2010 12:51:00 PST."<4B9957B4.7080009@gmail.com> <20100311221915.0206C1CC18@ptavv.es.net> Message-ID: <9AF22D15085E7D409ED5710CBC779E930DEC7CC7@COHNTCS09.ci.henderson.nv.us> +1 for the Arista boxes. We are a pure Cisco shop and looked at them to start replacing some gear where it made sense. We didn't buy them because they didn't do Rapid-PVST+ at the time. Yeah I know that's a Cisco-centric thing, but they were tentative on implementing it but the timeline just didn't meet our needs. Observations: Seriously knowledgeable technical/dev guys and I know for a fact that a pile of them came from the old Cisco 4K team back when the 4K's were walking circles around the 6K team in terms of innovation. If it make sense they are willing to implement features and they did so for us even though we were a demo. We had a question way back when distance limitations with SFP+ CU/CR/DA 5 meter cables and they actually got us on the phone with folks at Intel that normal people just don't have access to. Even though we don't have any Arista kit, their initial efforts left an excellent impression on us. P.S. They will give you temp access to the site if you ask but I too agree that it should be an open model. Michael Balasko CCSP, MCSE Network Specialist II City of Henderson, Nevada 240 Water St. Henderson, Nevada 89015 From trejrco at gmail.com Thu Mar 11 18:25:36 2010 From: trejrco at gmail.com (TJ) Date: Thu, 11 Mar 2010 19:25:36 -0500 Subject: IPv6 enabled carriers? In-Reply-To: <71bfd60c1003111451g15b5e2f1qd4f66481ad58959d@mail.gmail.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> <9026A043-BBCD-4D97-853F-6749B86D33DB@semihuman.com> <71bfd60c1003110954v2dcb4f6awdca72690f559d315@mail.gmail.com> <75cb24521003111405i30822f9ambfdd7ec4eece9260@mail.gmail.com> <71bfd60c1003111451g15b5e2f1qd4f66481ad58959d@mail.gmail.com> Message-ID: <000001cac17a$8accaa00$a065fe00$@com> Hmm, apologies - I was not explicit in calling out VZW; meant to, my bad and thanks for pointing it out! Posting from phone, while distracted . less than ideal. /TJ From: TJ [mailto:trejrco at gmail.com] Sent: Thursday, March 11, 2010 17:52 To: Christopher Morrow Subject: Re: IPv6 enabled carriers? VZW's LTE HW spec's mandate IPv6 support, that's why it is relevant. Yes, VZW - thought I made that pretty clear in my post ... (cough)also not verizon residential(cough) Yes, there are other carriers - none of which appear to have the level of coverage I need in the areas I spend my time. Or the Droid ;). (Although a strong IPv6 rollout might convince me ...) /TJ On Mar 11, 2010 5:05 PM, "Christopher Morrow" wrote: On Thu, Mar 11, 2010 at 12:54 PM, TJ wrote: > On Thu, Mar 11, 2010 at 12:01 PM, ... how so exactly?? LTE is really just a 'last mile' tech... whether it's v4 or v6 doesnt' seem to matter (to the fact that it's LTE) > Another nit - They are also blocking Protocol41 on their EV-DO network. vzw not vzb > While this is a 'noble, if poorly thought out, effort' to prevent IPv6 from > impacting their cel... there are other carriers ya know? From sparctacus at gmail.com Thu Mar 11 18:32:43 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Thu, 11 Mar 2010 16:32:43 -0800 Subject: Need advise for a linux firewall In-Reply-To: <4B9943CA.7070405@optonline.net> References: <4B9913BB.3030104@optonline.net> <1268324558.10083.32.camel@ub-g-d2> <4B9943CA.7070405@optonline.net> Message-ID: <53d706301003111632x171830cfg8a012bfec759805a@mail.gmail.com> On Thu, Mar 11, 2010 at 11:26 AM, Abdul Nazeer wrote: > On 03/11/2010 11:22 AM, gordon b slater wrote: >> On Thu, 2010-03-11 at 11:00 -0500, Abdul Nazeer wrote: >> >> >>> iptables, but if anyone has any other suggestion, I'd love to hear it. >>> >> PFsense, (being freeBSD-based, comes ?under your "other" category) >> It uses the OpenBSD-based pf firewall, with a web-based GUI for almost >> everything (except maybe console resets). works for me in ?several >> locations, some `heavy and high`. >> > Looks interesting. Will give it a shot, thanks! Great new book on pfsense as well. http://www.reedmedia.net/books/pfsense/ From DStaal at usa.net Thu Mar 11 18:37:20 2010 From: DStaal at usa.net (Daniel Staal) Date: Thu, 11 Mar 2010 19:37:20 -0500 Subject: Need advise for a linux firewall In-Reply-To: <1268324558.10083.32.camel@ub-g-d2> References: <4B9913BB.3030104@optonline.net> <1268324558.10083.32.camel@ub-g-d2> Message-ID: <3D2A0B16F08C109A2154567F@mac-pro.magehandbook.com> --As of March 11, 2010 4:22:38 PM +0000, gordon b slater is alleged to have said: > One caveat for the current PFsense: traffic shaping in 1.2.3 release is > somewhat borked (1.2.2 works much better) and it doesn't work with more > than 2 interfaces, so 1 wan - 1 lan is OK. --As for the rest, it is mine. One more, given the other current thread going on at the moment: The current version of PFsense doesn't support IPv6 through the GUI. (The OS and PF support it, but you have to log in to a shell to configure it.) It's on their to-do list. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From marka at isc.org Thu Mar 11 18:42:50 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 12 Mar 2010 11:42:50 +1100 Subject: IP4 Space In-Reply-To: Your message of "Thu, 11 Mar 2010 13:16:05 CDT." <2d6a9f6f1003111016t16ddc73frc4a430e22089149d@mail.gmail.com> References: <4B9004A7.2090907@rollernet.us> <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> <4B983C05.7030202@jsbc.cc> <88A50944-0767-48A5-A631-28E84B3CE587@senie.com> <2d6a9f6f1003111016t16ddc73frc4a430e22089149d@mail.gmail.com> Message-ID: <201003120042.o2C0goOt069392@drugs.dv.isc.org> In message <2d6a9f6f1003111016t16ddc73frc4a430e22089149d at mail.gmail.com>, Bill Bogstad writes: > I fall into this category, but I'm trying to get better. This may be > OT for this forum, but as someone whose network admin hat has mostly > been at the LAN/MAN level, I'm less concerned about IPv6 peering, etc. > then I am with what applications/servers don't play well with IPv6 and > how do I work around those issues. You test and file bug reports. Multi-homing support has been a host requirement for 20+ years now. IPv4 + IPv6 is just a example of multi-homing so there really should be no reason for any application to break when IPv6 support is added. > Where does one go to find out how organizations have switched their > internal IT infrastructure to IPv6? I think you will find that most organizations *added* IPv6. > Does it make sense/work to do this for internal operations even if our > outside connections are IPv4 only (forget about tunneling). Even more > mundane questions like how to deal with IPv4 only networked printers > when everything else is IPv6? I don't recommend turning on IPv6 internally without having external IPv6 connectivity. You don't have to offer IPv6 service publically but being able to get out to the internet over IPv6 removes a whole class of problems in applications which don't support multi-homing properly and try IPv6 first. You really don't want all the timeouts. This doesn't have to be native IPv6 connectivity. Tunnels work just fine for this initially. As for IPv4 only printers you can continue to run dual stack internally forever if you want. Otherwise put them on their own vlan and connect to them over NAT64 or run a proxy service. > If anyone in the Boston metro area wants to present to the local > system administrators group > (www.bblisa.org) on why we should care (and more importantly what to > do) please contact me off list. We're mostly a bunch of senior Unix > system administrator who are comfortable in our IPv4 world > and (I think) see IPv6 as a whole bunch of work to mostly get back to > where we already are. We've all heard about the coming address > apocalypse, but it always seems somewhere in the distant future. > > Thanks, > Bill Bogstad -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mark at streamservice.nl Thu Mar 11 18:48:03 2010 From: mark at streamservice.nl (Mark Scholten) Date: Fri, 12 Mar 2010 01:48:03 +0100 Subject: Need advise for a linux firewall In-Reply-To: <3D2A0B16F08C109A2154567F@mac-pro.magehandbook.com> References: <4B9913BB.3030104@optonline.net> <1268324558.10083.32.camel@ub-g-d2> <3D2A0B16F08C109A2154567F@mac-pro.magehandbook.com> Message-ID: <000201cac17d$ac63b9d0$052b2d70$@nl> > -----Original Message----- > From: Daniel Staal [mailto:DStaal at usa.net] > Sent: Friday, March 12, 2010 1:37 AM > To: nanog at nanog.org > Subject: Re: Need advise for a linux firewall > > --As of March 11, 2010 4:22:38 PM +0000, gordon b slater is alleged to > have > said: > > > One caveat for the current PFsense: traffic shaping in 1.2.3 release > is > > somewhat borked (1.2.2 works much better) and it doesn't work with > more > > than 2 interfaces, so 1 wan - 1 lan is OK. > > --As for the rest, it is mine. > > One more, given the other current thread going on at the moment: The > current version of PFsense doesn't support IPv6 through the GUI. (The > OS > and PF support it, but you have to log in to a shell to configure it.) > That is why we use Debian with IPtables (works great, easy to manage). Deploying anything now that doesn't fully support IPv6 is something I won't do unless there is no other option (and I strongly advice everyone else to be at least IPv6 ready). > It's on their to-do list. > > Daniel T. Staal > > --------------------------------------------------------------- > This email copyright the author. Unless otherwise noted, you > are expressly allowed to retransmit, quote, or otherwise use > the contents for non-commercial purposes. This copyright will > expire 5 years after the author's death, or in 30 years, > whichever is longer, unless such a period is in excess of > local copyright law. > --------------------------------------------------------------- Sorry, legally I am allowed to do that by local laws. Regards, Mark From brandon.galbraith at gmail.com Thu Mar 11 19:10:23 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 11 Mar 2010 19:10:23 -0600 Subject: ethernet to serial converters with ACLs In-Reply-To: References: <4B97FE71.8090700@csuohio.edu> <0B608FCDCF43BF4C9194C896C532024371A993@mnsg-svr2.mnsg.net> Message-ID: <366100671003111710i309b500dif50addca46aaac5c@mail.gmail.com> How do these compare to the Avocent/Cyclades serial console products? SNMP seems poorly implemented in the Cyclades, and if folks have good things to say about using the OpenGear stuff, it's a direction I'd want to move in. Private replies preferred to keep s/n down. On Thu, Mar 11, 2010 at 12:10 PM, Bill Fehring wrote: > On Wed, Mar 10, 2010 at 19:06, R. Benjamin Kessler > wrote:> > > On a similar topic, any good solutions for out-of-band serial > > console/Ethernet solutions that use EV-DO/GSM wireless Internet? > > Check these out: http://www.opengear.com/product-acm5000.html > > -- Brandon Galbraith Mobile: 630.400.6992 FNAL: 630.840.2141 From morrowc.lists at gmail.com Thu Mar 11 20:40:37 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Mar 2010 21:40:37 -0500 Subject: IPv6 enabled carriers? In-Reply-To: <000001cac17a$8accaa00$a065fe00$@com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> <9026A043-BBCD-4D97-853F-6749B86D33DB@semihuman.com> <71bfd60c1003110954v2dcb4f6awdca72690f559d315@mail.gmail.com> <75cb24521003111405i30822f9ambfdd7ec4eece9260@mail.gmail.com> <71bfd60c1003111451g15b5e2f1qd4f66481ad58959d@mail.gmail.com> <000001cac17a$8accaa00$a065fe00$@com> Message-ID: <75cb24521003111840n435e7fbbla1090299fb3330fe@mail.gmail.com> On Thu, Mar 11, 2010 at 7:25 PM, TJ wrote: > Hmm, apologies - I was not explicit in calling out VZW; meant to, my bad and > thanks for pointing it out! yup, the core point I was trying to make was that LTE is really just a vzw network change, and has basically nothing to do with 'verizon' networks (19262 or 70X). in the end though, I'm sure they'll put v6 on it (lte)... eventually :) -Chris From cb.list6 at gmail.com Thu Mar 11 20:52:28 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 11 Mar 2010 18:52:28 -0800 Subject: IPv6 enabled carriers? In-Reply-To: <75cb24521003111840n435e7fbbla1090299fb3330fe@mail.gmail.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> <4B97F08B.2070500@rollernet.us> <9026A043-BBCD-4D97-853F-6749B86D33DB@semihuman.com> <71bfd60c1003110954v2dcb4f6awdca72690f559d315@mail.gmail.com> <75cb24521003111405i30822f9ambfdd7ec4eece9260@mail.gmail.com> <71bfd60c1003111451g15b5e2f1qd4f66481ad58959d@mail.gmail.com> <000001cac17a$8accaa00$a065fe00$@com> <75cb24521003111840n435e7fbbla1090299fb3330fe@mail.gmail.com> Message-ID: On Thu, Mar 11, 2010 at 6:40 PM, Christopher Morrow wrote: > On Thu, Mar 11, 2010 at 7:25 PM, TJ wrote: >> Hmm, apologies - I was not explicit in calling out VZW; meant to, my bad and >> thanks for pointing it out! > > yup, the core point I was trying to make was that LTE is really just a > vzw network change, and has basically nothing to do with 'verizon' > networks (19262 or 70X). in the end though, I'm sure they'll put v6 on > it (lte)... eventually :) > IPv6 is mandatory on all VZW LTE devices, all SMS functions on VZW LTE devices will be handled as IPv6. The device requirements are publicly available. > -Chris > > From jbfixurpc at gmail.com Fri Mar 12 00:18:23 2010 From: jbfixurpc at gmail.com (Joe) Date: Fri, 12 Mar 2010 01:18:23 -0500 Subject: OT: Anyone seeing these sorts of probes? Port 46993 udp? In-Reply-To: <201003120042.o2C0goOt069392@drugs.dv.isc.org> Message-ID: <001e01cac1ab$d380ea50$4401a8c0@jgbpc> Not to distract from the IPV4/IPV6 thread, but just wondering if anyone has seen this beavior or perhaps can enlighten me to its orgin/virus/meaning? Internet Protocol, Src: 183.0.215.179 (183.0.215.179), Dst: 192.168.1.52 (192.168.1.52) User Datagram Protocol, Src Port: 64514 (64514), Dst Port: 46993 (46993) Data (101 bytes) 0000 64 31 3a 61 64 32 3a 69 64 32 30 3a 49 10 78 b3 d1:ad2:id20:I.x. 0010 9d 3f ab 23 75 7e d4 35 d7 cf c0 13 98 bf 84 30 .?.#u~.5.......0 0020 39 3a 69 6e 66 6f 5f 68 61 73 68 32 30 3a 09 61 9:info_hash20:.a 0030 e1 d8 9d cf ab 6a 2e 32 e8 42 92 73 b3 41 a3 72 .....j.2.B.s.A.r 0040 c7 f1 65 31 3a 71 39 3a 67 65 74 5f 70 65 65 72 ..e1:q9:get_peer 0050 73 31 3a 74 38 3a 31 30 30 30 34 32 35 35 31 3a s1:t8:100042551: 0060 79 31 3a 71 65 y1:qe Internet Protocol, Src: 183.0.215.179 (183.0.215.179), Dst: 192.168.1.52 (192.168.1.52) User Datagram Protocol, Src Port: 64514 (64514), Dst Port: 46993 (46993) Data (101 bytes) 0000 64 31 3a 61 64 32 3a 69 64 32 30 3a 49 10 78 b3 d1:ad2:id20:I.x. 0010 9d 3f ab 23 75 7e d4 35 d7 cf c0 13 98 bf 84 30 .?.#u~.5.......0 0020 39 3a 69 6e 66 6f 5f 68 61 73 68 32 30 3a 09 61 9:info_hash20:.a 0030 e1 d8 9d cf ab 6a 2e 32 e8 42 92 73 b3 41 a3 72 .....j.2.B.s.A.r 0040 c7 f1 65 31 3a 71 39 3a 67 65 74 5f 70 65 65 72 ..e1:q9:get_peer 0050 73 31 3a 74 38 3a 31 30 30 30 34 32 35 35 31 3a s1:t8:100042551: 0060 79 31 3a 71 65 y1:qe I'm seeing thousands of these per minute at one location, hundreds of unique ip addresses. Some sort of bot net maybe? Thanks much Joe From mysidia at gmail.com Fri Mar 12 00:31:06 2010 From: mysidia at gmail.com (James Hess) Date: Fri, 12 Mar 2010 00:31:06 -0600 Subject: OT: Anyone seeing these sorts of probes? Port 46993 udp? In-Reply-To: <001e01cac1ab$d380ea50$4401a8c0@jgbpc> References: <201003120042.o2C0goOt069392@drugs.dv.isc.org> <001e01cac1ab$d380ea50$4401a8c0@jgbpc> Message-ID: <6eb799ab1003112231u7d076163ra391a961601e37da@mail.gmail.com> Well, those UDP captures appear to be BitTorrent Peer-to-Peer file sharing traffic, or something disguised as such. Note the "64 31 3a 61 64 32 3a 69 64 32 30 3a" and also the textual reference to info_hash On Fri, Mar 12, 2010 at 12:18 AM, Joe wrote: > > Not to distract from the IPV4/IPV6 thread, but just wondering if anyone has > seen this beavior or perhaps can enlighten me to its orgin/virus/meaning? > > Internet Protocol, Src: 183.0.215.179 (183.0.215.179), Dst: 192.168.1.52 > (192.168.1.52) > User Datagram Protocol, Src Port: 64514 (64514), Dst Port: 46993 (46993) > Data (101 bytes) > > 0000 ?64 31 3a 61 64 32 3a 69 64 32 30 3a 49 10 78 b3 ? d1:ad2:id20:I.x. > 0010 ?9d 3f ab 23 75 7e d4 35 d7 cf c0 13 98 bf 84 30 ? .?.#u~.5.......0 > 0020 ?39 3a 69 6e 66 6f 5f 68 61 73 68 32 30 3a 09 61 ? 9:info_hash20:.a > 0030 ?e1 d8 9d cf ab 6a 2e 32 e8 42 92 73 b3 41 a3 72 ? .....j.2.B.s.A.r > 0040 ?c7 f1 65 31 3a 71 39 3a 67 65 74 5f 70 65 65 72 ? ..e1:q9:get_peer > 0050 ?73 31 3a 74 38 3a 31 30 30 30 34 32 35 35 31 3a ? s1:t8:100042551: > 0060 ?79 31 3a 71 65 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?y1:qe > > > Internet Protocol, Src: 183.0.215.179 (183.0.215.179), Dst: 192.168.1.52 > (192.168.1.52) > User Datagram Protocol, Src Port: 64514 (64514), Dst Port: 46993 (46993) > Data (101 bytes) > > 0000 ?64 31 3a 61 64 32 3a 69 64 32 30 3a 49 10 78 b3 ? d1:ad2:id20:I.x. > 0010 ?9d 3f ab 23 75 7e d4 35 d7 cf c0 13 98 bf 84 30 ? .?.#u~.5.......0 > 0020 ?39 3a 69 6e 66 6f 5f 68 61 73 68 32 30 3a 09 61 ? 9:info_hash20:.a > 0030 ?e1 d8 9d cf ab 6a 2e 32 e8 42 92 73 b3 41 a3 72 ? .....j.2.B.s.A.r > 0040 ?c7 f1 65 31 3a 71 39 3a 67 65 74 5f 70 65 65 72 ? ..e1:q9:get_peer > 0050 ?73 31 3a 74 38 3a 31 30 30 30 34 32 35 35 31 3a ? s1:t8:100042551: > 0060 ?79 31 3a 71 65 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?y1:qe > > I'm seeing thousands of these per minute at one location, hundreds of unique > ip addresses. Some sort of bot net maybe? > > > Thanks much > > Joe > > > -- -J From nathan at stonekitty.net Fri Mar 12 00:52:54 2010 From: nathan at stonekitty.net (Nathan) Date: Thu, 11 Mar 2010 22:52:54 -0800 Subject: YouTube AS36561 began announcing 1.0.0.0/8 Message-ID: Hello, I'm hoping to alleviate the "what's going on!?" type messages here this time. :) Here's an except from the APNIC provided LOA I provided to a couple networks, to carry a new announcement... "To whom it may concern, APNIC and YouTube are cooperating in a project to investigate the properties of unwanted traffic that is being sent to specific destinations in the address block of 1.0.0.0/8. This address block has been recently allocated to APNIC from the IANA, and APNIC and YouTube are wanting to undertake this investigation prior to the commencement of ordinary allocations. Accordingly, APNIC authorizes AS36351 to periodically advertise a route for 1.0.0.0/8 from now until 21 March 2010, and requests that AS36351's peers and upstreams accept this as a legitimate routing advertisement." In a continuation of last weeks experiments... we are now announcing 1.0.0.0/8 instead of 1.1.1.0/24 and 1.2.3.0/24. Cheers ,N (nathan at youtube.com - AS36561) From pcprognosis at verizon.net Fri Mar 12 02:42:11 2010 From: pcprognosis at verizon.net (Clinton Popovich) Date: Fri, 12 Mar 2010 03:42:11 -0500 Subject: OT: Anyone seeing these sorts of probes? Port 46993 udp? In-Reply-To: <6eb799ab1003112231u7d076163ra391a961601e37da@mail.gmail.com> References: <201003120042.o2C0goOt069392@drugs.dv.isc.org> <001e01cac1ab$d380ea50$4401a8c0@jgbpc> <6eb799ab1003112231u7d076163ra391a961601e37da@mail.gmail.com> Message-ID: <4B99FE63.4090707@verizon.net> I agree, this looks to be bit torrent traffic, The Pirate Bay has a practice of injecting fake client IP address. I have a feeling that is what your seeing. I would write more but power is out and the battery is going.... James Hess wrote: > Well, those UDP captures appear to be BitTorrent Peer-to-Peer file > sharing traffic, or something disguised as such. > Note the "64 31 3a 61 64 32 3a 69 64 32 30 3a" > and also the textual reference to info_hash > > On Fri, Mar 12, 2010 at 12:18 AM, Joe wrote: > >> Not to distract from the IPV4/IPV6 thread, but just wondering if anyone has >> seen this beavior or perhaps can enlighten me to its orgin/virus/meaning? >> >> Internet Protocol, Src: 183.0.215.179 (183.0.215.179), Dst: 192.168.1.52 >> (192.168.1.52) >> User Datagram Protocol, Src Port: 64514 (64514), Dst Port: 46993 (46993) >> Data (101 bytes) >> >> 0000 64 31 3a 61 64 32 3a 69 64 32 30 3a 49 10 78 b3 d1:ad2:id20:I.x. >> 0010 9d 3f ab 23 75 7e d4 35 d7 cf c0 13 98 bf 84 30 .?.#u~.5.......0 >> 0020 39 3a 69 6e 66 6f 5f 68 61 73 68 32 30 3a 09 61 9:info_hash20:.a >> 0030 e1 d8 9d cf ab 6a 2e 32 e8 42 92 73 b3 41 a3 72 .....j.2.B.s.A.r >> 0040 c7 f1 65 31 3a 71 39 3a 67 65 74 5f 70 65 65 72 ..e1:q9:get_peer >> 0050 73 31 3a 74 38 3a 31 30 30 30 34 32 35 35 31 3a s1:t8:100042551: >> 0060 79 31 3a 71 65 y1:qe >> >> >> Internet Protocol, Src: 183.0.215.179 (183.0.215.179), Dst: 192.168.1.52 >> (192.168.1.52) >> User Datagram Protocol, Src Port: 64514 (64514), Dst Port: 46993 (46993) >> Data (101 bytes) >> >> 0000 64 31 3a 61 64 32 3a 69 64 32 30 3a 49 10 78 b3 d1:ad2:id20:I.x. >> 0010 9d 3f ab 23 75 7e d4 35 d7 cf c0 13 98 bf 84 30 .?.#u~.5.......0 >> 0020 39 3a 69 6e 66 6f 5f 68 61 73 68 32 30 3a 09 61 9:info_hash20:.a >> 0030 e1 d8 9d cf ab 6a 2e 32 e8 42 92 73 b3 41 a3 72 .....j.2.B.s.A.r >> 0040 c7 f1 65 31 3a 71 39 3a 67 65 74 5f 70 65 65 72 ..e1:q9:get_peer >> 0050 73 31 3a 74 38 3a 31 30 30 30 34 32 35 35 31 3a s1:t8:100042551: >> 0060 79 31 3a 71 65 y1:qe >> >> I'm seeing thousands of these per minute at one location, hundreds of unique >> ip addresses. Some sort of bot net maybe? >> >> >> Thanks much >> >> Joe >> >> >> >> > > > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2739 - Release Date: 03/11/10 16:50:00 > > From nenolod at systeminplace.net Fri Mar 12 02:53:27 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 12 Mar 2010 02:53:27 -0600 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: References: Message-ID: <1268384007.1220.21.camel@petrie> On Thu, 2010-03-11 at 22:52 -0800, Nathan wrote: > Hello, > > I'm hoping to alleviate the "what's going on!?" type messages here this time. :) > Any IPs we can ping and get a response back from to verify everything is ok? 1.2.3.4 isn't pingable, for example. :( William From tjc at ecs.soton.ac.uk Fri Mar 12 06:24:49 2010 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 12 Mar 2010 12:24:49 +0000 Subject: IP4 Space In-Reply-To: <201003120042.o2C0goOt069392@drugs.dv.isc.org> References: <862A664C-A61F-4119-9F22-2FC9785A49D0@delong.com> <4B909D67.7070409@bogus.com> <3BBEE365-C435-4177-9F5C-D3271204FFCB@delong.com> <87iq94o388.fsf@laphroiag.quux.de> <4B983C05.7030202@jsbc.cc> <88A50944-0767-48A5-A631-28E84B3CE587@senie.com> <2d6a9f6f1003111016t16ddc73frc4a430e22089149d@mail.gmail.com> <201003120042.o2C0goOt069392@drugs.dv.isc.org> <20100312122449.GK21233@login.ecs.soton.ac.uk> Message-ID: On Fri, Mar 12, 2010 at 11:42:50AM +1100, Mark Andrews wrote: > > > Does it make sense/work to do this for internal operations even if our > > outside connections are IPv4 only (forget about tunneling). Even more > > mundane questions like how to deal with IPv4 only networked printers > > when everything else is IPv6? > > As for IPv4 only printers you can continue to run dual stack > internally forever if you want. Otherwise put them on their > own vlan and connect to them over NAT64 or run a proxy service. Our approach to v6 deployment has always been about enabling capability where it is available. The trick is then to have the right tools to manage and monitor it. The interesting thing about printers is that even quite low end network printers (like the HP Laserjet I have) have had IPv6 for quite a while. You can even configure DHCPv6 on the one I'm using. Just look for capabilities/features as you refresh equipment and it makes things that little easier. Tim From patrick at ianai.net Fri Mar 12 06:34:10 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 12 Mar 2010 07:34:10 -0500 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: References: Message-ID: <6221C75D-A46C-457C-AC28-95D32ABA28D1@ianai.net> On Mar 12, 2010, at 1:52 AM, Nathan wrote: > I'm hoping to alleviate the "what's going on!?" type messages here this time. :) Oh, I understand what's going on exactly. YouTube is trying to balance their ratios. :) -- TTFN, patrick > Here's an except from the APNIC provided LOA I provided to a couple > networks, to carry a new announcement... > > "To whom it may concern, > > APNIC and YouTube are cooperating in a project to investigate the > properties of unwanted traffic that is being sent to specific > destinations in the address block of 1.0.0.0/8. This address block has > been recently allocated to APNIC from the IANA, and > APNIC and YouTube are wanting to undertake this investigation prior to > the commencement of ordinary allocations. > Accordingly, APNIC authorizes AS36351 to periodically advertise a > route for 1.0.0.0/8 from now until 21 March 2010, and > requests that AS36351's peers and upstreams accept this as a > legitimate routing advertisement." > > > In a continuation of last weeks experiments... we are now announcing > 1.0.0.0/8 instead of 1.1.1.0/24 and 1.2.3.0/24. > > Cheers > ,N (nathan at youtube.com - AS36561) > From tme at americafree.tv Fri Mar 12 07:43:22 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 12 Mar 2010 08:43:22 -0500 Subject: FCC releases Internet speed test tool Message-ID: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> This might be useful to some. Article : http://www.reuters.com/article/idUSTRE62B08720100312 site : http://www.broadband.gov/ It requires giving your address. Regards Marshall From jared at puck.nether.net Fri Mar 12 07:55:39 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 12 Mar 2010 08:55:39 -0500 Subject: FCC releases Internet speed test tool In-Reply-To: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> References: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> Message-ID: If you have fios please don't use this, if you have relatives with dial, make them use it :) - Jared On Mar 12, 2010, at 8:43 AM, Marshall Eubanks wrote: > This might be useful to some. > > Article : > > http://www.reuters.com/article/idUSTRE62B08720100312 > > site : > > http://www.broadband.gov/ > > It requires giving your address. > > Regards > Marshall From randy at psg.com Fri Mar 12 07:57:59 2010 From: randy at psg.com (Randy Bush) Date: Fri, 12 Mar 2010 22:57:59 +0900 Subject: FCC releases Internet speed test tool In-Reply-To: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> References: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> Message-ID: > http://www.broadband.gov/ i suspect the bandwidth tests are a bit latency sensitive > It requires giving your address. did not really like a tokyo postal code randy From alan at clegg.com Fri Mar 12 08:08:20 2010 From: alan at clegg.com (Alan Clegg) Date: Fri, 12 Mar 2010 09:08:20 -0500 Subject: FCC releases Internet speed test tool In-Reply-To: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> References: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> Message-ID: <4B9A4AD4.6000409@clegg.com> Marshall Eubanks wrote: > http://www.broadband.gov/ ;; ANSWER SECTION: www.broadband.gov. 86400 IN A 4.21.126.148 www.broadband.gov. 86400 IN RRSIG A 7 3 86400 20100309192609 ( 20091209192609 46640 broadband.gov. [...] ) Expired signatures... zone won't validate. AlanC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From jgreco at ns.sol.net Fri Mar 12 08:16:29 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 12 Mar 2010 08:16:29 -0600 (CST) Subject: FCC releases Internet speed test tool In-Reply-To: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> from "Marshall Eubanks" at Mar 12, 2010 08:43:22 AM Message-ID: <201003121416.o2CEGTRv093042@aurora.sol.net> > This might be useful to some. > > Article : > > http://www.reuters.com/article/idUSTRE62B08720100312 > > site : > > http://www.broadband.gov/ > > It requires giving your address. Correction: it _requires_ Java. It _asks_ for your address. It seems like it'd work fine if you gave it your neighbor's address. :-) I noted that I got wildly varying numbers on a laptop and an iPhone (there is also an iPhone app) and the iPhone app doesn't ask for an address. Both on the same wifi, and the numbers were off by a lot. ... 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 jgreco at ns.sol.net Fri Mar 12 08:24:09 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 12 Mar 2010 08:24:09 -0600 (CST) Subject: FCC releases Internet speed test tool In-Reply-To: <201003121416.o2CEGTRv093042@aurora.sol.net> from "Joe Greco" at Mar 12, 2010 08:16:29 AM Message-ID: <201003121424.o2CEO9Ga093249@aurora.sol.net> > I noted that I got wildly varying numbers on a laptop and an iPhone (there > is also an iPhone app) and the iPhone app doesn't ask for an address. Both > on the same wifi and connection, and the numbers were off by a lot. And I meant to include examples, but fingers committed the message before I could stop 'em. Sorry. PC/mLab: Download speed: 4150kbps Upload speed: 2364kpbs PC/Ookla: Download speed: 5044kbps Upload speed: 1120Kbps iPhone: Download speed: 1.75Mbps Upload speed: 0.23Mbps I've gotten strange stuff each time I've tried their tests. I particularly like the factor of 10 difference in upload speeds. ... 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 nanog-post at rsuc.gweep.net Fri Mar 12 08:27:50 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 12 Mar 2010 09:27:50 -0500 Subject: 10GBase-t switch In-Reply-To: <20100311213038.GA7593@moussaka.pmacct.net> References: <20100311060407.13AFB1CC0D@ptavv.es.net> <4B990321.10908@ipax.at> <017265BF3B9640499754DD48777C3D2067B738F2A9@MBX9.EXCHPROD.USA.NET> <4B995EA9.2050708@nipper.de> <20100311213038.GA7593@moussaka.pmacct.net> Message-ID: <20100312142750.GA53028@gweep.net> On Thu, Mar 11, 2010 at 09:30:38PM +0000, Paolo Lucente wrote: > On Thu, Mar 11, 2010 at 10:20:41PM +0100, Arnold Nipper wrote: > > On 11.03.2010 16:29 Dylan Ebner wrote > > > > > Do the Arista switches support netflow? From a management perspective > > > netflow can be vital. This is something we have been unhappy with on > > > our 3560 and 3750 cisco's. > > > > > > > They don't (yet). Given you buy enoughboxes, Arista may be willing to > > implement this feature. Would like to have this as well. > > And if you have to request a vendor of L2 devices to implement something > in this sense then definitely ask for sFlow. If 10GTX isn't a hard requirement, SPF+ & CX4 are supported in a similar price/perfromance point on the BNT G8124/G1000, with sFlow. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From sean at donelan.com Fri Mar 12 08:34:14 2010 From: sean at donelan.com (Sean Donelan) Date: Fri, 12 Mar 2010 09:34:14 -0500 (EST) Subject: FCC releases Internet speed test tool In-Reply-To: <201003121424.o2CEO9Ga093249@aurora.sol.net> References: <201003121424.o2CEO9Ga093249@aurora.sol.net> Message-ID: On Fri, 12 Mar 2010, Joe Greco wrote: > I've gotten strange stuff each time I've tried their tests. I > particularly like the factor of 10 difference in upload speeds. The FCC is probably doing this because US providers generally don't release actual bandwidth, speeds or latency numbers their consumer customers get. Advertised numbers often don't mean anything. If providers want to release better data, it might help the FCC understand the current environment. Some US providers have published data for their business customer connections and backbones. From jgreco at ns.sol.net Fri Mar 12 08:43:47 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 12 Mar 2010 08:43:47 -0600 (CST) Subject: FCC releases Internet speed test tool In-Reply-To: from "Sean Donelan" at Mar 12, 2010 09:34:14 AM Message-ID: <201003121443.o2CEhlGJ094475@aurora.sol.net> > On Fri, 12 Mar 2010, Joe Greco wrote: > > I've gotten strange stuff each time I've tried their tests. I > > particularly like the factor of 10 difference in upload speeds. > > The FCC is probably doing this because US providers generally don't > release actual bandwidth, speeds or latency numbers their consumer > customers get. I understand the point behind the test. > Advertised numbers often don't mean anything. If > providers want to release better data, it might help the FCC understand > the current environment. > > Some US providers have published data for their business customer > connections and backbones. I realize that a high level of participation could result in the FCC gaining a more complete understanding of broadband penetration, and specific areas where there are problems. However, I have some reservations as to whether or not the FCC will be able to get enough people to participate in this to be able to generate a meaningful dataset. Further, major inconsistencies such as what I just pointed out brings into question the validity of the test, and therefore the value. I am not that concerned about the difference between 4Mbps and 5Mbps, but when there's an order of magnitude difference involved... on the same connection... I would guess, hopefully correctly, that Speedtest.net, Akamai, and others already have a good handle on broadband speeds, and it seems to me that the FCC could get a much more thorough picture of per-ISP performance (which of course isn't street-level) simply by getting these guys to summarize their results. As such, the only real value I see the FCC tool offering is the potential for visibility into things such as DSL speed/distance limitations, but in order for that to be meaningful, you'd have to get a lot of people to run the test. Which brings us back to ... I'm not entirely sure that this is a useful strategy. ... 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 bclark at spectraaccess.com Fri Mar 12 08:45:38 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 12 Mar 2010 09:45:38 -0500 Subject: FCC releases Internet speed test tool In-Reply-To: <201003121424.o2CEO9Ga093249@aurora.sol.net> References: <201003121424.o2CEO9Ga093249@aurora.sol.net> Message-ID: <4B9A5392.3000003@spectraaccess.com> Joe Greco wrote: > > I've gotten strange stuff each time I've tried their tests. I > particularly like the factor of 10 difference in upload speeds. > > ... JG > Yeah...these test are algorithm based and rarely accurate! On our 100Mbps Internet connection (which I know handles 100Mbps) best I could get is 10Mbps down and 14Mbps up. Wish someone would come up with a much better mouse trap. The only test I've ever found to be fairly accurate is iperf or a simple FTP test. From dmburgess at linktechs.net Fri Mar 12 08:51:17 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Fri, 12 Mar 2010 08:51:17 -0600 Subject: Need advise for a linux firewall References: <4B9913BB.3030104@optonline.net> <1268324558.10083.32.camel@ub-g-d2><4B9943CA.7070405@optonline.net><5e382f341003111145p61e4bdf6xfa8b80b6d82e9ff1@mail.gmail.com> <69069bc21003111554q5adfd820h78458ab8bdf9c7a7@mail.gmail.com> Message-ID: <91522911795E174F97E7EF8B792A1031147DF5@ltiserver.LTI.local> Can't go wrong with RouterOS. The whole OS will boot on a 32meg drive if you needed it too. Contact us if you need hardware/software :) ----------------------------------------------------------- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Will Clayton [mailto:w.d.clayton at gmail.com] Sent: Thursday, March 11, 2010 5:54 PM To: Jim Miller Cc: Abdul Nazeer; nanog at nanog.org Subject: Re: Need advise for a linux firewall Microtik makes a pretty robust Linux based firewall appliance-on-a-usb-stick. It does a lot out of the box like BGP, VPN, MPLS,QoS and all kinds of other crazy things you wouldn't expect to fit on one gig of flash. It takes my HP about 10 seconds to load a full table. My vote is for PFSense though. PF is a lot of fun itself and I have seen awesome throughput with no load on very low end hardware. On Thu, Mar 11, 2010 at 1:45 PM, Jim Miller wrote: > On Thu, Mar 11, 2010 at 11:56 PM, Abdul Nazeer >wrote: > > > On 03/11/2010 11:22 AM, gordon b slater wrote: > > > On Thu, 2010-03-11 at 11:00 -0500, Abdul Nazeer wrote: > > > > > > > > >> iptables, but if anyone has any other suggestion, I'd love to hear it. > > >> > > > PFsense, (being freeBSD-based, comes under your "other" category) > > > It uses the OpenBSD-based pf firewall, with a web-based GUI for almost > > > everything (except maybe console resets). works for me in several > > > locations, some `heavy and high`. > > > > > Looks interesting. Will give it a shot, thanks! > > > > For a very long time I used the following setup with great success: > 1. Debian based linux for the firewall box. With Debian you can do a very > light setup. > 2. FWBuilder to builder for the GUI front end. It's been around for quite > a > long time now and has built in RCS for revision control. > 3. Quagga for OSPF routing.. We only had about .. 4-5 firewalls but made a > lot of internal routing changes and OSPF _really_ made things easy when we > made changes > 4. OpenVPN for after-hours access and off-site staff access. > > Anyway, just my $0.02 > > --Jim > From ljb at merit.edu Fri Mar 12 09:00:35 2010 From: ljb at merit.edu (Larry Blunk) Date: Fri, 12 Mar 2010 10:00:35 -0500 Subject: 10GBase-t switch In-Reply-To: <413ff53f1003101346u81d3034hee0e669a8867cf83@mail.gmail.com> References: <413ff53f1003101346u81d3034hee0e669a8867cf83@mail.gmail.com> Message-ID: <4B9A5713.9050400@merit.edu> Mirko Maffioli wrote: > I'm searching for a switch with at least one 10Gbase-T ethernet port > and some gigabit ethernet for lab test. > >From cisco web site i've seen for example a 3560 model with X2 module > and CX4 port but nothing with 10Gb-T. > > Unfortunately my budget couldn't arrive to nexus or cat6500.... > > Do you have some other vendor model i can check? > > Bye > Mirko > > I noticed that no one has actually quite answered this original question (on a budget, multiple GigE's, at least one 10GBase-T). There seem to be at least a couple possible options at this point -- The Dell PowerConnect 6224 lists a dual port 10GBase-T module option for $1349. Also, they seem to be releasing sFlow support shortly -- http://en.community.dell.com/forums/p/19304811/19635923.aspx The SMC 8824M has a single port 10GBase-T module option (SMC10BTMOD) for around $800 with up to 2 modules per switch. They apparently have a promo where you can get a 10GBase-T PCI-E card for free if you order one of these modules (SMC10BTMOD-BUND). -Larry From LarrySheldon at cox.net Fri Mar 12 09:07:06 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 12 Mar 2010 09:07:06 -0600 Subject: FCC releases Internet speed test tool In-Reply-To: <201003121443.o2CEhlGJ094475@aurora.sol.net> References: <201003121443.o2CEhlGJ094475@aurora.sol.net> Message-ID: <4B9A589A.5010206@cox.net> On 3/12/2010 08:43, Joe Greco wrote: > As such, the only real value I see the FCC tool offering is the potential > for visibility into things such as DSL speed/distance limitations, but in > order for that to be meaningful, you'd have to get a lot of people to run > the test. > > Which brings us back to ... I'm not entirely sure that this is a useful > strategy. Look at the legislation under which it was implemented. Look at the political agenda that appears to be obvious to me. Look at the history of governments collection, "analysis", and use of data. Now guess with me which findings have been pre-ordained and need only some data to be filtered, adjusted (see weather data and NOAA's and NASA's manipulation of it), and finally guess with me what regulation will be justified by and mandated based on the findings. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From fred at cisco.com Fri Mar 12 09:23:53 2010 From: fred at cisco.com (Fred Baker) Date: Fri, 12 Mar 2010 07:23:53 -0800 Subject: FCC releases Internet speed test tool In-Reply-To: References: <201003121424.o2CEO9Ga093249@aurora.sol.net> Message-ID: <6BD5928E-7129-48BE-84D1-FE190CA36A04@cisco.com> I could imagine that the FCC sees it as a data source. On Mar 12, 2010, at 6:34 AM, Sean Donelan wrote: > On Fri, 12 Mar 2010, Joe Greco wrote: >> I've gotten strange stuff each time I've tried their tests. I >> particularly like the factor of 10 difference in upload speeds. > > The FCC is probably doing this because US providers generally don't release actual bandwidth, speeds or latency numbers their consumer > customers get. Advertised numbers often don't mean anything. If > providers want to release better data, it might help the FCC understand > the current environment. > > Some US providers have published data for their business customer connections and backbones. > > http://www.ipinc.net/IPv4.GIF From CTR002 at SHSU.EDU Fri Mar 12 09:27:31 2010 From: CTR002 at SHSU.EDU (Ramsden, Colt) Date: Fri, 12 Mar 2010 09:27:31 -0600 Subject: unsubscribe In-Reply-To: References: Message-ID: unsubscribe -- Colt Ramsden Programmer Analyst II Sam Houston State University 936.294.4488 - ramsden at shsu.edu -----Original Message----- From: nanog-request at nanog.org [mailto:nanog-request at nanog.org] Sent: Friday, March 12, 2010 8:46 AM To: nanog at nanog.org Subject: NANOG Digest, Vol 26, Issue 61 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: IP4 Space (Tim Chown) 2. Re: YouTube AS36561 began announcing 1.0.0.0/8 (Patrick W. Gilmore) 3. FCC releases Internet speed test tool (Marshall Eubanks) 4. Re: FCC releases Internet speed test tool (Jared Mauch) 5. Re: FCC releases Internet speed test tool (Randy Bush) 6. Re: FCC releases Internet speed test tool (Alan Clegg) 7. Re: FCC releases Internet speed test tool (Joe Greco) 8. Re: FCC releases Internet speed test tool (Joe Greco) 9. Re: 10GBase-t switch (Joe Provo) 10. Re: FCC releases Internet speed test tool (Sean Donelan) 11. Re: FCC releases Internet speed test tool (Joe Greco) 12. Re: FCC releases Internet speed test tool (Bret Clark) ---------------------------------------------------------------------- Message: 1 Date: Fri, 12 Mar 2010 12:24:49 +0000 From: Tim Chown Subject: Re: IP4 Space To: NANOG list Message-ID: Content-Type: text/plain; charset=us-ascii On Fri, Mar 12, 2010 at 11:42:50AM +1100, Mark Andrews wrote: > > > Does it make sense/work to do this for internal operations even if our > > outside connections are IPv4 only (forget about tunneling). Even more > > mundane questions like how to deal with IPv4 only networked printers > > when everything else is IPv6? > > As for IPv4 only printers you can continue to run dual stack > internally forever if you want. Otherwise put them on their > own vlan and connect to them over NAT64 or run a proxy service. Our approach to v6 deployment has always been about enabling capability where it is available. The trick is then to have the right tools to manage and monitor it. The interesting thing about printers is that even quite low end network printers (like the HP Laserjet I have) have had IPv6 for quite a while. You can even configure DHCPv6 on the one I'm using. Just look for capabilities/features as you refresh equipment and it makes things that little easier. Tim ------------------------------ Message: 2 Date: Fri, 12 Mar 2010 07:34:10 -0500 From: "Patrick W. Gilmore" Subject: Re: YouTube AS36561 began announcing 1.0.0.0/8 To: NANOG list Message-ID: <6221C75D-A46C-457C-AC28-95D32ABA28D1 at ianai.net> Content-Type: text/plain; charset=us-ascii On Mar 12, 2010, at 1:52 AM, Nathan wrote: > I'm hoping to alleviate the "what's going on!?" type messages here this time. :) Oh, I understand what's going on exactly. YouTube is trying to balance their ratios. :) -- TTFN, patrick > Here's an except from the APNIC provided LOA I provided to a couple > networks, to carry a new announcement... > > "To whom it may concern, > > APNIC and YouTube are cooperating in a project to investigate the > properties of unwanted traffic that is being sent to specific > destinations in the address block of 1.0.0.0/8. This address block has > been recently allocated to APNIC from the IANA, and > APNIC and YouTube are wanting to undertake this investigation prior to > the commencement of ordinary allocations. > Accordingly, APNIC authorizes AS36351 to periodically advertise a > route for 1.0.0.0/8 from now until 21 March 2010, and > requests that AS36351's peers and upstreams accept this as a > legitimate routing advertisement." > > > In a continuation of last weeks experiments... we are now announcing > 1.0.0.0/8 instead of 1.1.1.0/24 and 1.2.3.0/24. > > Cheers > ,N (nathan at youtube.com - AS36561) > ------------------------------ Message: 3 Date: Fri, 12 Mar 2010 08:43:22 -0500 From: Marshall Eubanks Subject: FCC releases Internet speed test tool To: "nanog at nanog.org list" Message-ID: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63 at americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed This might be useful to some. Article : http://www.reuters.com/article/idUSTRE62B08720100312 site : http://www.broadband.gov/ It requires giving your address. Regards Marshall ------------------------------ Message: 4 Date: Fri, 12 Mar 2010 08:55:39 -0500 From: Jared Mauch Subject: Re: FCC releases Internet speed test tool To: Marshall Eubanks Cc: "nanog at nanog.org list" Message-ID: Content-Type: text/plain; charset=us-ascii If you have fios please don't use this, if you have relatives with dial, make them use it :) - Jared On Mar 12, 2010, at 8:43 AM, Marshall Eubanks wrote: > This might be useful to some. > > Article : > > http://www.reuters.com/article/idUSTRE62B08720100312 > > site : > > http://www.broadband.gov/ > > It requires giving your address. > > Regards > Marshall ------------------------------ Message: 5 Date: Fri, 12 Mar 2010 22:57:59 +0900 From: Randy Bush Subject: Re: FCC releases Internet speed test tool To: Marshall Eubanks Cc: "nanog at nanog.org list" Message-ID: Content-Type: text/plain; charset=US-ASCII > http://www.broadband.gov/ i suspect the bandwidth tests are a bit latency sensitive > It requires giving your address. did not really like a tokyo postal code randy ------------------------------ Message: 6 Date: Fri, 12 Mar 2010 09:08:20 -0500 From: Alan Clegg Subject: Re: FCC releases Internet speed test tool Cc: "nanog at nanog.org list" Message-ID: <4B9A4AD4.6000409 at clegg.com> Content-Type: text/plain; charset="iso-8859-1" Marshall Eubanks wrote: > http://www.broadband.gov/ ;; ANSWER SECTION: www.broadband.gov. 86400 IN A 4.21.126.148 www.broadband.gov. 86400 IN RRSIG A 7 3 86400 20100309192609 ( 20091209192609 46640 broadband.gov. [...] ) Expired signatures... zone won't validate. AlanC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature Url : http://mailman.nanog.org/mailman/nanog/attachments/20100312/a0da8a12/attachment-0001.pgp ------------------------------ Message: 7 Date: Fri, 12 Mar 2010 08:16:29 -0600 (CST) From: Joe Greco Subject: Re: FCC releases Internet speed test tool To: tme at americafree.tv (Marshall Eubanks) Cc: "nanog at nanog.org list" Message-ID: <201003121416.o2CEGTRv093042 at aurora.sol.net> Content-Type: text/plain; charset=us-ascii > This might be useful to some. > > Article : > > http://www.reuters.com/article/idUSTRE62B08720100312 > > site : > > http://www.broadband.gov/ > > It requires giving your address. Correction: it _requires_ Java. It _asks_ for your address. It seems like it'd work fine if you gave it your neighbor's address. :-) I noted that I got wildly varying numbers on a laptop and an iPhone (there is also an iPhone app) and the iPhone app doesn't ask for an address. Both on the same wifi, and the numbers were off by a lot. ... 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. ------------------------------ Message: 8 Date: Fri, 12 Mar 2010 08:24:09 -0600 (CST) From: Joe Greco Subject: Re: FCC releases Internet speed test tool To: jgreco at ns.sol.net (Joe Greco) Cc: "nanog at nanog.org list" Message-ID: <201003121424.o2CEO9Ga093249 at aurora.sol.net> Content-Type: text/plain; charset=us-ascii > I noted that I got wildly varying numbers on a laptop and an iPhone (there > is also an iPhone app) and the iPhone app doesn't ask for an address. Both > on the same wifi and connection, and the numbers were off by a lot. And I meant to include examples, but fingers committed the message before I could stop 'em. Sorry. PC/mLab: Download speed: 4150kbps Upload speed: 2364kpbs PC/Ookla: Download speed: 5044kbps Upload speed: 1120Kbps iPhone: Download speed: 1.75Mbps Upload speed: 0.23Mbps I've gotten strange stuff each time I've tried their tests. I particularly like the factor of 10 difference in upload speeds. ... 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. ------------------------------ Message: 9 Date: Fri, 12 Mar 2010 09:27:50 -0500 From: Joe Provo Subject: Re: 10GBase-t switch To: nanog at nanog.org Message-ID: <20100312142750.GA53028 at gweep.net> Content-Type: text/plain; charset=us-ascii On Thu, Mar 11, 2010 at 09:30:38PM +0000, Paolo Lucente wrote: > On Thu, Mar 11, 2010 at 10:20:41PM +0100, Arnold Nipper wrote: > > On 11.03.2010 16:29 Dylan Ebner wrote > > > > > Do the Arista switches support netflow? From a management perspective > > > netflow can be vital. This is something we have been unhappy with on > > > our 3560 and 3750 cisco's. > > > > > > > They don't (yet). Given you buy enoughboxes, Arista may be willing to > > implement this feature. Would like to have this as well. > > And if you have to request a vendor of L2 devices to implement something > in this sense then definitely ask for sFlow. If 10GTX isn't a hard requirement, SPF+ & CX4 are supported in a similar price/perfromance point on the BNT G8124/G1000, with sFlow. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE ------------------------------ Message: 10 Date: Fri, 12 Mar 2010 09:34:14 -0500 (EST) From: Sean Donelan Subject: Re: FCC releases Internet speed test tool To: "nanog at nanog.org list" Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 12 Mar 2010, Joe Greco wrote: > I've gotten strange stuff each time I've tried their tests. I > particularly like the factor of 10 difference in upload speeds. The FCC is probably doing this because US providers generally don't release actual bandwidth, speeds or latency numbers their consumer customers get. Advertised numbers often don't mean anything. If providers want to release better data, it might help the FCC understand the current environment. Some US providers have published data for their business customer connections and backbones. ------------------------------ Message: 11 Date: Fri, 12 Mar 2010 08:43:47 -0600 (CST) From: Joe Greco Subject: Re: FCC releases Internet speed test tool To: sean at donelan.com (Sean Donelan) Cc: "nanog at nanog.org list" Message-ID: <201003121443.o2CEhlGJ094475 at aurora.sol.net> Content-Type: text/plain; charset=us-ascii > On Fri, 12 Mar 2010, Joe Greco wrote: > > I've gotten strange stuff each time I've tried their tests. I > > particularly like the factor of 10 difference in upload speeds. > > The FCC is probably doing this because US providers generally don't > release actual bandwidth, speeds or latency numbers their consumer > customers get. I understand the point behind the test. > Advertised numbers often don't mean anything. If > providers want to release better data, it might help the FCC understand > the current environment. > > Some US providers have published data for their business customer > connections and backbones. I realize that a high level of participation could result in the FCC gaining a more complete understanding of broadband penetration, and specific areas where there are problems. However, I have some reservations as to whether or not the FCC will be able to get enough people to participate in this to be able to generate a meaningful dataset. Further, major inconsistencies such as what I just pointed out brings into question the validity of the test, and therefore the value. I am not that concerned about the difference between 4Mbps and 5Mbps, but when there's an order of magnitude difference involved... on the same connection... I would guess, hopefully correctly, that Speedtest.net, Akamai, and others already have a good handle on broadband speeds, and it seems to me that the FCC could get a much more thorough picture of per-ISP performance (which of course isn't street-level) simply by getting these guys to summarize their results. As such, the only real value I see the FCC tool offering is the potential for visibility into things such as DSL speed/distance limitations, but in order for that to be meaningful, you'd have to get a lot of people to run the test. Which brings us back to ... I'm not entirely sure that this is a useful strategy. ... 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. ------------------------------ Message: 12 Date: Fri, 12 Mar 2010 09:45:38 -0500 From: Bret Clark Subject: Re: FCC releases Internet speed test tool To: "nanog at nanog.org list" Message-ID: <4B9A5392.3000003 at spectraaccess.com> Content-Type: text/plain; charset=us-ascii; format=flowed Joe Greco wrote: > > I've gotten strange stuff each time I've tried their tests. I > particularly like the factor of 10 difference in upload speeds. > > ... JG > Yeah...these test are algorithm based and rarely accurate! On our 100Mbps Internet connection (which I know handles 100Mbps) best I could get is 10Mbps down and 14Mbps up. Wish someone would come up with a much better mouse trap. The only test I've ever found to be fairly accurate is iperf or a simple FTP test. ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 26, Issue 61 ************************************* From mathews at hawaii.edu Fri Mar 12 09:32:15 2010 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Fri, 12 Mar 2010 10:32:15 -0500 Subject: FCC releases Internet speed test tool In-Reply-To: <201003121416.o2CEGTRv093042@aurora.sol.net> References: <201003121416.o2CEGTRv093042@aurora.sol.net> Message-ID: <4B9A5E7F.1030004@hawaii.edu> Joe Greco wrote: > Correction: it _requires_ Java. It _asks_ for your address. It seems > like it'd work fine if you gave it your neighbor's address. :-) > > I noted that I got wildly varying numbers on a laptop and an iPhone (there > is also an iPhone app) and the iPhone app doesn't ask for an address. Both > on the same wifi, and the numbers were off by a lot. > > ... JG INSTEAD of using the FCC provided app, one 'could' always use OOKLA and M-LAB directly. The following links may prove to be more helpful to some. http://demo.ookla.com/linequality/ *and * http://npad.iupui.lax01.measurement-lab.org:8000/ (Choose the closest orig/term point to you from: http://www.measurementlab.net/measurement-lab-tools#npad ) Both sites present varying granularity.. It goes without saying that one should NOT send one's mother/grandmother to the NPAD site. Pete (Peter L?thberg) being the exception here..... O:-) Best, Robert. -- From morrowc.lists at gmail.com Fri Mar 12 09:44:37 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 12 Mar 2010 10:44:37 -0500 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <1268384007.1220.21.camel@petrie> References: <1268384007.1220.21.camel@petrie> Message-ID: <75cb24521003120744q2b75758ducf0d039469f68981@mail.gmail.com> On Fri, Mar 12, 2010 at 3:53 AM, William Pitcock wrote: > On Thu, 2010-03-11 at 22:52 -0800, Nathan wrote: >> Hello, >> >> I'm hoping to alleviate the "what's going on!?" type messages here this time. :) >> > > > Any IPs we can ping and get a response back from to verify everything is > ok? ?1.2.3.4 isn't pingable, for example. :( > we (nate/steve who're actually doing the work here, for geoff/george) could probably light up something, but give it 48 hrs? > William > > > From ras at e-gerbil.net Fri Mar 12 09:58:42 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 12 Mar 2010 09:58:42 -0600 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <6221C75D-A46C-457C-AC28-95D32ABA28D1@ianai.net> References: <6221C75D-A46C-457C-AC28-95D32ABA28D1@ianai.net> Message-ID: <20100312155842.GE75640@gerbil.cluepon.net> On Fri, Mar 12, 2010 at 07:34:10AM -0500, Patrick W. Gilmore wrote: > Oh, I understand what's going on exactly. YouTube is trying to > balance their ratios. :) That might explain why they're only announcing it behind Cogent. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From nathan at stonekitty.net Fri Mar 12 10:03:12 2010 From: nathan at stonekitty.net (Nathan) Date: Fri, 12 Mar 2010 08:03:12 -0800 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <1268384007.1220.21.camel@petrie> References: <1268384007.1220.21.camel@petrie> Message-ID: A trace-route reaches the Youtube border... so everything is ok. The routes are being ECMP'd to a set of capture hosts for the purpose of spreading load, aggregating more disk-space for packets, providing some form of redundancy for the experiment, etc. We're receiving about 175mbps of unsolicited noise. I'll leave the remaining details to be provided by the official report/article from Geoff and George. Its amazing how prolific 1.x traffic is. ,N On Fri, Mar 12, 2010 at 12:53 AM, William Pitcock wrote: > On Thu, 2010-03-11 at 22:52 -0800, Nathan wrote: >> Hello, >> >> I'm hoping to alleviate the "what's going on!?" type messages here this time. :) >> > > > Any IPs we can ping and get a response back from to verify everything is > ok? ?1.2.3.4 isn't pingable, for example. :( > > > William > > From nathan at stonekitty.net Fri Mar 12 10:04:54 2010 From: nathan at stonekitty.net (Nathan) Date: Fri, 12 Mar 2010 08:04:54 -0800 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <20100312155842.GE75640@gerbil.cluepon.net> References: <6221C75D-A46C-457C-AC28-95D32ABA28D1@ianai.net> <20100312155842.GE75640@gerbil.cluepon.net> Message-ID: We've never cared about ratios... its futile! Level3 is slow to update prefix lists this time. I simply picked a couple networks that respond to my emails. My laziness to call others is why the route isn't visible there. :) ,N On Fri, Mar 12, 2010 at 7:58 AM, Richard A Steenbergen wrote: > On Fri, Mar 12, 2010 at 07:34:10AM -0500, Patrick W. Gilmore wrote: >> Oh, I understand what's going on exactly. ?YouTube is trying to >> balance their ratios. :) > > That might explain why they're only announcing it behind Cogent. :) > > -- > Richard A Steenbergen ? ? ? http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > > From joel.esler at me.com Fri Mar 12 10:05:18 2010 From: joel.esler at me.com (Joel Esler) Date: Fri, 12 Mar 2010 11:05:18 -0500 Subject: unsubscribe In-Reply-To: References: Message-ID: <1771275D-AF8B-4545-AB80-734517794E95@me.com> Please review the link at the very bottom of every email for instructions on how to unsubscribe. -- Joel Esler Sent from my iPhone On Mar 12, 2010, at 10:27 AM, "Ramsden, Colt" wrote: > unsubscribe > > -- > Colt Ramsden > Programmer Analyst II > Sam Houston State University > 936.294.4488 - ramsden at shsu.edu > > > -----Original Message----- > From: nanog-request at nanog.org [mailto:nanog-request at nanog.org] > Sent: Friday, March 12, 2010 8:46 AM > To: nanog at nanog.org > Subject: NANOG Digest, Vol 26, Issue 61 > > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: IP4 Space (Tim Chown) > 2. Re: YouTube AS36561 began announcing 1.0.0.0/8 > (Patrick W. Gilmore) > 3. FCC releases Internet speed test tool (Marshall Eubanks) > 4. Re: FCC releases Internet speed test tool (Jared Mauch) > 5. Re: FCC releases Internet speed test tool (Randy Bush) > 6. Re: FCC releases Internet speed test tool (Alan Clegg) > 7. Re: FCC releases Internet speed test tool (Joe Greco) > 8. Re: FCC releases Internet speed test tool (Joe Greco) > 9. Re: 10GBase-t switch (Joe Provo) > 10. Re: FCC releases Internet speed test tool (Sean Donelan) > 11. Re: FCC releases Internet speed test tool (Joe Greco) > 12. Re: FCC releases Internet speed test tool (Bret Clark) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 12 Mar 2010 12:24:49 +0000 > From: Tim Chown > Subject: Re: IP4 Space > To: NANOG list > Message-ID: > login.ecs.soton.ac.uk|20100312122449.GK21233 at login.ecs.soton.ac.uk> > > Content-Type: text/plain; charset=us-ascii > > On Fri, Mar 12, 2010 at 11:42:50AM +1100, Mark Andrews wrote: >> >>> Does it make sense/work to do this for internal operations even if >>> our >>> outside connections are IPv4 only (forget about tunneling). Even >>> more >>> mundane questions like how to deal with IPv4 only networked printers >>> when everything else is IPv6? >> >> As for IPv4 only printers you can continue to run dual stack >> internally forever if you want. Otherwise put them on their >> own vlan and connect to them over NAT64 or run a proxy service. > > Our approach to v6 deployment has always been about enabling > capability > where it is available. The trick is then to have the right tools to > manage and monitor it. > > The interesting thing about printers is that even quite low end > network > printers (like the HP Laserjet I have) have had IPv6 for quite a > while. > You can even configure DHCPv6 on the one I'm using. > > Just look for capabilities/features as you refresh equipment and it > makes things that little easier. > > Tim > > > > ------------------------------ > > Message: 2 > Date: Fri, 12 Mar 2010 07:34:10 -0500 > From: "Patrick W. Gilmore" > Subject: Re: YouTube AS36561 began announcing 1.0.0.0/8 > To: NANOG list > Message-ID: <6221C75D-A46C-457C-AC28-95D32ABA28D1 at ianai.net> > Content-Type: text/plain; charset=us-ascii > > On Mar 12, 2010, at 1:52 AM, Nathan wrote: > >> I'm hoping to alleviate the "what's going on!?" type messages here >> this time. :) > > Oh, I understand what's going on exactly. YouTube is trying to > balance their ratios. :) > > -- > TTFN, > patrick > > >> Here's an except from the APNIC provided LOA I provided to a couple >> networks, to carry a new announcement... >> >> "To whom it may concern, >> >> APNIC and YouTube are cooperating in a project to investigate the >> properties of unwanted traffic that is being sent to specific >> destinations in the address block of 1.0.0.0/8. This address block >> has >> been recently allocated to APNIC from the IANA, and >> APNIC and YouTube are wanting to undertake this investigation prior >> to >> the commencement of ordinary allocations. >> Accordingly, APNIC authorizes AS36351 to periodically advertise a >> route for 1.0.0.0/8 from now until 21 March 2010, and >> requests that AS36351's peers and upstreams accept this as a >> legitimate routing advertisement." >> >> >> In a continuation of last weeks experiments... we are now announcing >> 1.0.0.0/8 instead of 1.1.1.0/24 and 1.2.3.0/24. >> >> Cheers >> ,N (nathan at youtube.com - AS36561) >> > > > > > ------------------------------ > > Message: 3 > Date: Fri, 12 Mar 2010 08:43:22 -0500 > From: Marshall Eubanks > Subject: FCC releases Internet speed test tool > To: "nanog at nanog.org list" > Message-ID: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63 at americafree.tv> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > This might be useful to some. > > Article : > > http://www.reuters.com/article/idUSTRE62B08720100312 > > site : > > http://www.broadband.gov/ > > It requires giving your address. > > Regards > Marshall > > > > ------------------------------ > > Message: 4 > Date: Fri, 12 Mar 2010 08:55:39 -0500 > From: Jared Mauch > Subject: Re: FCC releases Internet speed test tool > To: Marshall Eubanks > Cc: "nanog at nanog.org list" > Message-ID: > Content-Type: text/plain; charset=us-ascii > > If you have fios please don't use this, if you have relatives with > dial, make them use it :) > > - Jared > > On Mar 12, 2010, at 8:43 AM, Marshall Eubanks wrote: > >> This might be useful to some. >> >> Article : >> >> http://www.reuters.com/article/idUSTRE62B08720100312 >> >> site : >> >> http://www.broadband.gov/ >> >> It requires giving your address. >> >> Regards >> Marshall > > > > > ------------------------------ > > Message: 5 > Date: Fri, 12 Mar 2010 22:57:59 +0900 > From: Randy Bush > Subject: Re: FCC releases Internet speed test tool > To: Marshall Eubanks > Cc: "nanog at nanog.org list" > Message-ID: > Content-Type: text/plain; charset=US-ASCII > >> http://www.broadband.gov/ > > i suspect the bandwidth tests are a bit latency sensitive > >> It requires giving your address. > > did not really like a tokyo postal code > > randy > > > > ------------------------------ > > Message: 6 > Date: Fri, 12 Mar 2010 09:08:20 -0500 > From: Alan Clegg > Subject: Re: FCC releases Internet speed test tool > Cc: "nanog at nanog.org list" > Message-ID: <4B9A4AD4.6000409 at clegg.com> > Content-Type: text/plain; charset="iso-8859-1" > > Marshall Eubanks wrote: > >> http://www.broadband.gov/ > > ;; ANSWER SECTION: > www.broadband.gov. 86400 IN A 4.21.126.148 > www.broadband.gov. 86400 IN RRSIG A 7 3 86400 20100309192609 ( > 20091209192609 46640 broadband.gov. > [...] ) > > Expired signatures... zone won't validate. > > AlanC > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 261 bytes > Desc: OpenPGP digital signature > Url : http://mailman.nanog.org/mailman/nanog/attachments/20100312/a0da8a12/attachment-0001.pgp > > ------------------------------ > > Message: 7 > Date: Fri, 12 Mar 2010 08:16:29 -0600 (CST) > From: Joe Greco > Subject: Re: FCC releases Internet speed test tool > To: tme at americafree.tv (Marshall Eubanks) > Cc: "nanog at nanog.org list" > Message-ID: <201003121416.o2CEGTRv093042 at aurora.sol.net> > Content-Type: text/plain; charset=us-ascii > >> This might be useful to some. >> >> Article : >> >> http://www.reuters.com/article/idUSTRE62B08720100312 >> >> site : >> >> http://www.broadband.gov/ >> >> It requires giving your address. > > Correction: it _requires_ Java. It _asks_ for your address. It > seems > like it'd work fine if you gave it your neighbor's address. :-) > > I noted that I got wildly varying numbers on a laptop and an iPhone > (there > is also an iPhone app) and the iPhone app doesn't ask for an > address. Both > on the same wifi, and the numbers were off by a lot. > > ... 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. > > > > ------------------------------ > > Message: 8 > Date: Fri, 12 Mar 2010 08:24:09 -0600 (CST) > From: Joe Greco > Subject: Re: FCC releases Internet speed test tool > To: jgreco at ns.sol.net (Joe Greco) > Cc: "nanog at nanog.org list" > Message-ID: <201003121424.o2CEO9Ga093249 at aurora.sol.net> > Content-Type: text/plain; charset=us-ascii > >> I noted that I got wildly varying numbers on a laptop and an iPhone >> (there >> is also an iPhone app) and the iPhone app doesn't ask for an >> address. Both >> on the same wifi and connection, and the numbers were off by a lot. > > And I meant to include examples, but fingers committed the message > before I could stop 'em. Sorry. > > PC/mLab: > > Download speed: 4150kbps > Upload speed: 2364kpbs > > PC/Ookla: > > Download speed: 5044kbps > Upload speed: 1120Kbps > > iPhone: > > Download speed: 1.75Mbps > Upload speed: 0.23Mbps > > I've gotten strange stuff each time I've tried their tests. I > particularly like the factor of 10 difference in upload speeds. > > ... 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. > > > > ------------------------------ > > Message: 9 > Date: Fri, 12 Mar 2010 09:27:50 -0500 > From: Joe Provo > Subject: Re: 10GBase-t switch > To: nanog at nanog.org > Message-ID: <20100312142750.GA53028 at gweep.net> > Content-Type: text/plain; charset=us-ascii > > On Thu, Mar 11, 2010 at 09:30:38PM +0000, Paolo Lucente wrote: >> On Thu, Mar 11, 2010 at 10:20:41PM +0100, Arnold Nipper wrote: >>> On 11.03.2010 16:29 Dylan Ebner wrote >>> >>>> Do the Arista switches support netflow? From a management >>>> perspective >>>> netflow can be vital. This is something we have been unhappy with >>>> on >>>> our 3560 and 3750 cisco's. >>>> >>> >>> They don't (yet). Given you buy enoughboxes, Arista may be willing >>> to >>> implement this feature. Would like to have this as well. >> >> And if you have to request a vendor of L2 devices to implement >> something >> in this sense then definitely ask for sFlow. > > If 10GTX isn't a hard requirement, SPF+ & CX4 are supported in a > similar > price/perfromance point on the BNT G8124/G1000, with sFlow. > > -- > RSUC / GweepNet / Spunk / FnB / Usenix / SAGE > > > > ------------------------------ > > Message: 10 > Date: Fri, 12 Mar 2010 09:34:14 -0500 (EST) > From: Sean Donelan > Subject: Re: FCC releases Internet speed test tool > To: "nanog at nanog.org list" > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Fri, 12 Mar 2010, Joe Greco wrote: >> I've gotten strange stuff each time I've tried their tests. I >> particularly like the factor of 10 difference in upload speeds. > > The FCC is probably doing this because US providers generally don't > release actual bandwidth, speeds or latency numbers their consumer > customers get. Advertised numbers often don't mean anything. If > providers want to release better data, it might help the FCC > understand > the current environment. > > Some US providers have published data for their business customer > connections and backbones. > > > > > ------------------------------ > > Message: 11 > Date: Fri, 12 Mar 2010 08:43:47 -0600 (CST) > From: Joe Greco > Subject: Re: FCC releases Internet speed test tool > To: sean at donelan.com (Sean Donelan) > Cc: "nanog at nanog.org list" > Message-ID: <201003121443.o2CEhlGJ094475 at aurora.sol.net> > Content-Type: text/plain; charset=us-ascii > >> On Fri, 12 Mar 2010, Joe Greco wrote: >>> I've gotten strange stuff each time I've tried their tests. I >>> particularly like the factor of 10 difference in upload speeds. >> >> The FCC is probably doing this because US providers generally don't >> release actual bandwidth, speeds or latency numbers their consumer >> customers get. > > I understand the point behind the test. > >> Advertised numbers often don't mean anything. If >> providers want to release better data, it might help the FCC >> understand >> the current environment. >> >> Some US providers have published data for their business customer >> connections and backbones. > > I realize that a high level of participation could result in the FCC > gaining a more complete understanding of broadband penetration, and > specific areas where there are problems. > > However, I have some reservations as to whether or not the FCC will be > able to get enough people to participate in this to be able to > generate > a meaningful dataset. > > Further, major inconsistencies such as what I just pointed out brings > into question the validity of the test, and therefore the value. > I am not that concerned about the difference between 4Mbps and 5Mbps, > but when there's an order of magnitude difference involved... on the > same connection... > > I would guess, hopefully correctly, that Speedtest.net, Akamai, and > others already have a good handle on broadband speeds, and it seems to > me that the FCC could get a much more thorough picture of per-ISP > performance (which of course isn't street-level) simply by getting > these > guys to summarize their results. > > As such, the only real value I see the FCC tool offering is the > potential > for visibility into things such as DSL speed/distance limitations, > but in > order for that to be meaningful, you'd have to get a lot of people > to run > the test. > > Which brings us back to ... I'm not entirely sure that this is a > useful > strategy. > > ... 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. > > > > ------------------------------ > > Message: 12 > Date: Fri, 12 Mar 2010 09:45:38 -0500 > From: Bret Clark > Subject: Re: FCC releases Internet speed test tool > To: "nanog at nanog.org list" > Message-ID: <4B9A5392.3000003 at spectraaccess.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > Joe Greco wrote: >> >> I've gotten strange stuff each time I've tried their tests. I >> particularly like the factor of 10 difference in upload speeds. >> >> ... JG >> > Yeah...these test are algorithm based and rarely accurate! On our > 100Mbps Internet connection (which I know handles 100Mbps) best I > could > get is 10Mbps down and 14Mbps up. > Wish someone would come up with a much better mouse trap. The only > test > I've ever found to be fairly accurate is iperf or a simple FTP test. > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 26, Issue 61 > ************************************* > From scott at sberkman.net Fri Mar 12 10:26:17 2010 From: scott at sberkman.net (Scott Berkman) Date: Fri, 12 Mar 2010 11:26:17 -0500 Subject: FCC releases Internet speed test tool In-Reply-To: <4B9A5E7F.1030004@hawaii.edu> References: <201003121416.o2CEGTRv093042@aurora.sol.net> <4B9A5E7F.1030004@hawaii.edu> Message-ID: <00a301cac200$bebfcd70$3c3f6850$@net> So have other people noticed that the Ookla/Speedtest.net/Speakeasy Bandwidth test often comes up VERY short on upload bandwidth results for anything other than residential-grade asymmetrical services? We often get complaints from customers saying "I'm not getting the upload bandwidth I'm paying for", and when we ask what they are using to determine this, the answer is almost always either Speakeasy or Speedtest.net. We certainly don't depend on or recommend these sites to customers (we have our own internal tools and usually recommend FTP or iperf), but everyone who deems themselves semi-knowledgeable seems to find their way there anyway. Do these sites simply not have the downstream bandwidth to handle the upload tests? If that?s the case I'd really like to see the admins add a disclaimer of some form directly to the site. Thanks, -Scott -----Original Message----- From: Robert Mathews (OSIA) [mailto:mathews at hawaii.edu] Sent: Friday, March 12, 2010 10:32 AM To: North American Network Operators Group Subject: Re: FCC releases Internet speed test tool Joe Greco wrote: > Correction: it _requires_ Java. It _asks_ for your address. It seems > like it'd work fine if you gave it your neighbor's address. :-) > > I noted that I got wildly varying numbers on a laptop and an iPhone (there > is also an iPhone app) and the iPhone app doesn't ask for an address. Both > on the same wifi, and the numbers were off by a lot. > > ... JG INSTEAD of using the FCC provided app, one 'could' always use OOKLA and M-LAB directly. The following links may prove to be more helpful to some. http://demo.ookla.com/linequality/ *and * http://npad.iupui.lax01.measurement-lab.org:8000/ (Choose the closest orig/term point to you from: http://www.measurementlab.net/measurement-lab-tools#npad ) Both sites present varying granularity.. It goes without saying that one should NOT send one's mother/grandmother to the NPAD site. Pete (Peter L?thberg) being the exception here..... O:-) Best, Robert. -- From jnegro at billtrust.com Fri Mar 12 10:33:54 2010 From: jnegro at billtrust.com (Jeffrey Negro) Date: Fri, 12 Mar 2010 11:33:54 -0500 Subject: Comcast Metro Ethernet Message-ID: We are currently in talks with Comcast with regards to their metro ethernet products in New Jersey and Illinois, for internet bandwidth not L2/PTP. I'd like to hear opinions from others who have the service, in regards to uptime, support, and performance. Thank you in advance! -- Jeffrey Negro From jmamodio at gmail.com Fri Mar 12 10:35:35 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 12 Mar 2010 10:35:35 -0600 Subject: FCC releases Internet speed test tool In-Reply-To: <201003121424.o2CEO9Ga093249@aurora.sol.net> References: <201003121416.o2CEGTRv093042@aurora.sol.net> <201003121424.o2CEO9Ga093249@aurora.sol.net> Message-ID: <202705b1003120835m24ee88beo2bc42de7c2b89c5e@mail.gmail.com> There are obviously some variables, buffering or something out there since download speeds do not seem to be very consistent running the tools several times. I tested three times each with the two engines. >From SATX, TWC/RR: Ookla Download Speed 24408 28494 22662 Kbps Upload Speed 483 492 493 Kbps Latency 18 18 18 ms Jitter 2 2 2 ms MLAB Download Speed 16854 17630 15780 Kbps Upload Speed 487 493 493 Kbps Latency 18 17 17 ms Jitter 2 1 1 ms Regards Jorge From mathews at hawaii.edu Fri Mar 12 11:03:50 2010 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Fri, 12 Mar 2010 12:03:50 -0500 Subject: FCC releases Internet speed test tool In-Reply-To: <00a301cac200$bebfcd70$3c3f6850$@net> References: <201003121416.o2CEGTRv093042@aurora.sol.net> <4B9A5E7F.1030004@hawaii.edu> <00a301cac200$bebfcd70$3c3f6850$@net> Message-ID: <4B9A73F6.4080009@hawaii.edu> Scott Berkman wrote: > So have other people noticed that the Ookla/Speedtest.net/Speakeasy > Bandwidth test often comes up VERY short on upload bandwidth results for > anything other than residential-grade asymmetrical services? The question to consider are: are JAVA based "speed" testers reliable? What are the caveats? Nevertheless, they have - over time, become 'popular' among users, and your average 'cable guy,' to at least the first 2 tiers of service tech personnel at ISPs who are often relegated to diagnosing why "grandma's" Internet connection is slow.... Best, Robert. -- From akg1330 at gmail.com Fri Mar 12 11:06:22 2010 From: akg1330 at gmail.com (Andrew Gallo) Date: Fri, 12 Mar 2010 12:06:22 -0500 Subject: FCC releases Internet speed test tool In-Reply-To: <00a301cac200$bebfcd70$3c3f6850$@net> References: <201003121416.o2CEGTRv093042@aurora.sol.net> <4B9A5E7F.1030004@hawaii.edu> <00a301cac200$bebfcd70$3c3f6850$@net> Message-ID: <4B9A748E.2070008@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/12/2010 11:26 AM, Scott Berkman wrote: > So have other people noticed that the Ookla/Speedtest.net/Speakeasy > Bandwidth test often comes up VERY short on upload bandwidth results for > anything other than residential-grade asymmetrical services? > > We often get complaints from customers saying "I'm not getting the upload > bandwidth I'm paying for", and when we ask what they are using to determine > this, the answer is almost always either Speakeasy or Speedtest.net. > > We certainly don't depend on or recommend these sites to customers (we have > our own internal tools and usually recommend FTP or iperf), but everyone who > deems themselves semi-knowledgeable seems to find their way there anyway. > Do these sites simply not have the downstream bandwidth to handle the upload > tests? If that?s the case I'd really like to see the admins add a > disclaimer of some form directly to the site. > > Thanks, > > -Scott I'm seeing big disparity between upload and download speeds. I had the same thought as to the testing platform expecting asymmetrical speeds typical of a residential link. Why didn't they go with NDT? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuadI0ACgkQQr/gMVyFYyT5ywCfTjlYgTs9qV3AaXHsHX3wkm15 QJYAoJoSxNzDqrdX86MoLNB+gObbhZ9/ =qGyL -----END PGP SIGNATURE----- From jdfalk-lists at cybernothing.org Fri Mar 12 11:13:46 2010 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Fri, 12 Mar 2010 10:13:46 -0700 Subject: PL/SQL & CIDR? Message-ID: <3DDC8C81-5D30-4C54-8E8E-283003E1A539@cybernothing.org> Does anyone know of a library, sample code, etc. to help Oracle PL/SQL do CIDR math? -- J.D. Falk Return Path Inc From jmheralds at gmail.com Fri Mar 12 11:26:14 2010 From: jmheralds at gmail.com (James Heralds) Date: Fri, 12 Mar 2010 12:26:14 -0500 Subject: Call for papers: ISP-10, USA, July 2010 Message-ID: <739582dd1003120926m7d8b9fa0obe897f38a24a2fcd@mail.gmail.com> It would be highly appreciated if you could share this announcement with your colleagues, students and individuals whose research is in information security, cryptography, privacy, and related areas. Call for papers: ISP-10, USA, July 2010 The 2010 International Conference on Information Security and Privacy (ISP-10) (website: http://www.PromoteResearch.org) will be held during 12-14 of July 2010 in Orlando, FL, USA. ISP is an important event in the areas of information security, privacy, cryptography and related topics. The conference will be held at the same time and location where several other major international conferences will be taking place. The conference will be held as part of 2010 multi-conference (MULTICONF-10). MULTICONF-10 will be held during July 12-14, 2010 in Orlando, Florida, USA. The primary goal of MULTICONF is to promote research and developmental activities in computer science, information technology, control engineering, and related fields. Another goal is to promote the dissemination of research to a multidisciplinary audience and to facilitate communication among researchers, developers, practitioners in different fields. The following conferences are planned to be organized as part of MULTICONF-10. ? International Conference on Artificial Intelligence and Pattern Recognition (AIPR-10) ? International Conference on Automation, Robotics and Control Systems (ARCS-10) ? International Conference on Bioinformatics, Computational Biology, Genomics and Chemoinformatics (BCBGC-10) ? International Conference on Computer Communications and Networks (CCN-10) ? International Conference on Enterprise Information Systems and Web Technologies (EISWT-10) ? International Conference on High Performance Computing Systems (HPCS-10) ? International Conference on Information Security and Privacy (ISP-10) ? International Conference on Image and Video Processing and Computer Vision (IVPCV-10) ? International Conference on Software Engineering Theory and Practice (SETP-10) ? International Conference on Theoretical and Mathematical Foundations of Computer Science (TMFCS-10) MULTICONF-10 will be held at Imperial Swan Hotel and Suites. It is a full-service resort that puts you in the middle of the fun! Located 1/2 block south of the famed International Drive, the hotel is just minutes from great entertainment like Walt Disney World? Resort, Universal Studios and Sea World Orlando. Guests can enjoy free scheduled transportation to these theme parks, as well as spacious accommodations, outdoor pools and on-site dining ? all situated on 10 tropically landscaped acres. Here, guests can experience a full-service resort with discount hotel pricing in Orlando. We invite draft paper submissions. Please see the website http://www.PromoteResearch.org for more details. Sincerely James Heralds From charles at knownelement.com Fri Mar 12 11:27:08 2010 From: charles at knownelement.com (charles at knownelement.com) Date: Fri, 12 Mar 2010 17:27:08 +0000 Subject: FCC releases Internet speed test tool Message-ID: <1853956277-1268414907-cardhu_decombobulator_blackberry.rim.net-1123414082-@bda2625.bisx.prod.on.blackberry> Does it work with IPv6? ------Original Message------ From: Marshall Eubanks To: nanog at nanog.org list Subject: FCC releases Internet speed test tool Sent: Mar 12, 2010 5:43 AM This might be useful to some. Article : http://www.reuters.com/article/idUSTRE62B08720100312 site : http://www.broadband.gov/ It requires giving your address. Regards Marshall Sent via BlackBerry from T-Mobile From dwhite at olp.net Fri Mar 12 11:29:18 2010 From: dwhite at olp.net (Dan White) Date: Fri, 12 Mar 2010 11:29:18 -0600 Subject: FCC releases Internet speed test tool In-Reply-To: <00a301cac200$bebfcd70$3c3f6850$@net> References: <201003121416.o2CEGTRv093042@aurora.sol.net> <4B9A5E7F.1030004@hawaii.edu> <00a301cac200$bebfcd70$3c3f6850$@net> Message-ID: <20100312172918.GI4868@dan.olp.net> On 12/03/10?11:26?-0500, Scott Berkman wrote: >So have other people noticed that the Ookla/Speedtest.net/Speakeasy >Bandwidth test often comes up VERY short on upload bandwidth results for >anything other than residential-grade asymmetrical services? > >We often get complaints from customers saying "I'm not getting the upload >bandwidth I'm paying for", and when we ask what they are using to determine >this, the answer is almost always either Speakeasy or Speedtest.net. > >We certainly don't depend on or recommend these sites to customers (we have >our own internal tools and usually recommend FTP or iperf), but everyone who >deems themselves semi-knowledgeable seems to find their way there anyway. >Do these sites simply not have the downstream bandwidth to handle the upload >tests? If that?s the case I'd really like to see the admins add a >disclaimer of some form directly to the site. We decided to spend the money to install a local Ookla speed test site a couple of years ago and have been happy with the decision: 1) Local customers who run the speed test get much more accurate readings than with what we were previously using, which was either javascript based, or java based. The Ookla software we're running is flash based, which a very high number of our users already have installed. 2) It gets placed on the main speedtest.net map. When our customers go to speedtest.net to test their speeds, the default test location they get is our own site, and they get accurate results. 3) When customers from local competitors go to speedtest.net, they get defaulted to our test location, and get less than accurate readings (since they are not on our local network) and get artificially depressed results, which is a positive for us. On a side note, we've tried to sign up for Ookla's pingtest.net, but haven't gotten any responses from them about it. Has anyone else had any success signing up for it? -- Dan White From rsk at gsp.org Fri Mar 12 11:47:30 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 12 Mar 2010 12:47:30 -0500 Subject: Call for papers: ISP-10, USA, July 2010 In-Reply-To: <739582dd1003120926m7d8b9fa0obe897f38a24a2fcd@mail.gmail.com> References: <739582dd1003120926m7d8b9fa0obe897f38a24a2fcd@mail.gmail.com> Message-ID: <20100312174730.GA9051@gsp.org> On Fri, Mar 12, 2010 at 12:26:14PM -0500, James Heralds wrote: > It would be highly appreciated if you could share this announcement with > your colleagues, students and individuals whose research is in information > security, cryptography, privacy, and related areas. > > Call for papers: ISP-10, USA, July 2010 This is a scam "conference". The spammers behind it have been hitting Usenet newsgroups for some time and are now targeting [many] mailing lists. I'm looking into it along with a few other people and we will eventually be putting out something reasonably coherent and complete about it, but in the meantime, I recommend blacklisting this spammer's email address. ---Rsk From clapidus at gmail.com Fri Mar 12 12:04:58 2010 From: clapidus at gmail.com (Claudio Lapidus) Date: Fri, 12 Mar 2010 15:04:58 -0300 Subject: PL/SQL & CIDR? In-Reply-To: <3DDC8C81-5D30-4C54-8E8E-283003E1A539@cybernothing.org> References: <3DDC8C81-5D30-4C54-8E8E-283003E1A539@cybernothing.org> Message-ID: Not in Oracle, but PostgreSQL has a very robust implementation for CIDR, including not only datatypes but also a host of operators to deal with them. Being opensource, it always seemed plausible to me to port the functionality into Oracle, learning from their implementation. Never got to actual development, though. hth, cl. On Fri, Mar 12, 2010 at 2:13 PM, J.D. Falk wrote: > Does anyone know of a library, sample code, etc. to help Oracle PL/SQL do > CIDR math? > > -- > J.D. Falk > Return Path Inc > > > > > > From jsqnanog at quarterman.com Fri Mar 12 12:06:41 2010 From: jsqnanog at quarterman.com (John S. Quarterman) Date: Fri, 12 Mar 2010 13:06:41 -0500 Subject: FCC releases Internet speed test tool In-Reply-To: Your message of "Fri, 12 Mar 2010 12:06:22 EST." <4B9A748E.2070008@gmail.com> Message-ID: <1268417202.23057.2874@marut.quarterman.com> > On 3/12/2010 11:26 AM, Scott Berkman wrote: > So have other people noticed that the Ookla/Speedtest.net/Speakeasy > Bandwidth test often comes up VERY short on upload bandwidth results for > anything other than residential-grade asymmetrical services? As we heard in Austin, residential (or at least end-user) systems are the primary focus of the FCC's rule-making: http://riskman.typepad.com/peerflow/2010/02/nprm-diagram-2-scope-of-rules.html -jsq From dga at cs.cmu.edu Fri Mar 12 12:33:39 2010 From: dga at cs.cmu.edu (David Andersen) Date: Fri, 12 Mar 2010 13:33:39 -0500 Subject: Call for papers: ISP-10, USA, July 2010 In-Reply-To: <20100312174730.GA9051@gsp.org> References: <739582dd1003120926m7d8b9fa0obe897f38a24a2fcd@mail.gmail.com> <20100312174730.GA9051@gsp.org> Message-ID: <557D19C5-7F8B-43DC-8129-576F23F81FC7@cs.cmu.edu> On Mar 12, 2010, at 12:47 PM, Rich Kulawiec wrote: > On Fri, Mar 12, 2010 at 12:26:14PM -0500, James Heralds wrote: >> It would be highly appreciated if you could share this announcement with >> your colleagues, students and individuals whose research is in information >> security, cryptography, privacy, and related areas. >> >> Call for papers: ISP-10, USA, July 2010 > > This is a scam "conference". The spammers behind it have > been hitting Usenet newsgroups for some time and are now targeting > [many] mailing lists. I'm looking into it along with a few other > people and we will eventually be putting out something reasonably > coherent and complete about it, but in the meantime, I recommend > blacklisting this spammer's email address. Another option, if you have 3 minutes of spare time, why not send them a submission? A very special submission. One you might even enjoy reading yourself: "SCIgen - An Automatic CS Paper Generator" http://pdos.csail.mit.edu/scigen/ Of course, you could also send them a different paper (title has words you might not want displayed in large fonts on a monitor in public): http://www.scs.stanford.edu/~dm/home/papers/remove.pdf -Dave, who dislikes spam conferences as much as the next guy. From jsqnanog at quarterman.com Fri Mar 12 12:34:49 2010 From: jsqnanog at quarterman.com (John S. Quarterman) Date: Fri, 12 Mar 2010 13:34:49 -0500 Subject: FCC releases Internet speed test tool In-Reply-To: Your message of "Fri, 12 Mar 2010 13:06:41 EST." <1268417202.23057.2874@marut.quarterman.com> Message-ID: <1268418889.802182.3230@marut.quarterman.com> Anybody who wants to do it better, here's your chance: https://www.fbo.gov/utils/view?id=cb712eb3ef384ebe25bfbf6b0a5dfa16 -jsq From pkranz at unwiredltd.com Fri Mar 12 12:36:39 2010 From: pkranz at unwiredltd.com (Peter Kranz) Date: Fri, 12 Mar 2010 10:36:39 -0800 Subject: FCC releases Internet speed test tool In-Reply-To: <20100312172918.GI4868@dan.olp.net> References: <201003121416.o2CEGTRv093042@aurora.sol.net> <4B9A5E7F.1030004@hawaii.edu> <00a301cac200$bebfcd70$3c3f6850$@net> <20100312172918.GI4868@dan.olp.net> Message-ID: <083e01cac212$f49cff50$ddd6fdf0$@unwiredltd.com> There is definitely something very broken in the gov't version of the speedtest.net application. It seems very BW constrained. I can get great results to a variety of ookla sites via test points across the US, but the government one is always horrible. We host both a pingtest and speedtest.net site, and provided you give it enough BW, it's reasonably accurate for connections up to around 50 Mbps.. Peter Kranz From surfer at mauigateway.com Fri Mar 12 12:57:51 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 12 Mar 2010 10:57:51 -0800 Subject: FCC releases Internet speed test tool Message-ID: <20100312105751.2C06AC65@resin16.mta.everyone.net> --- tme at americafree.tv wrote: From: Marshall Eubanks This might be useful to some. Article : http://www.reuters.com/article/idUSTRE62B08720100312 site :http://www.broadband.gov/ It requires giving your address. ----------------------------------------------- Nah, no real address needed. Just use 123 elm street abbeville alabama 36310. That's the first zip code I found on a site... ;-) At least they're using NDT: Host: ndt.iupui.donar.measurement-lab.org:7123 scott From cscora at apnic.net Fri Mar 12 12:54:36 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Mar 2010 04:54:36 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201003121854.o2CIsasF016235@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 13 Mar, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 313752 Prefixes after maximum aggregation: 145168 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 153109 Total ASes present in the Internet Routing Table: 33516 Prefixes per ASN: 9.36 Origin-only ASes present in the Internet Routing Table: 29092 Origin ASes announcing only one prefix: 14197 Transit ASes present in the Internet Routing Table: 4424 Transit-only ASes present in the Internet Routing Table: 100 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 22 Max AS path prepend of ASN (32374) 19 Prefixes from unregistered ASNs in the Routing Table: 947 Unregistered ASNs in the Routing Table: 151 Number of 32-bit ASNs allocated by the RIRs: 466 Prefixes from 32-bit ASNs in the Routing Table: 476 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 212 Number of addresses announced to Internet: 2215388000 Equivalent to 132 /8s, 12 /16s and 35 /24s Percentage of available address space announced: 59.8 Percentage of allocated address space announced: 66.4 Percentage of available address space allocated: 90.0 Percentage of address space in use by end-sites: 81.6 Total number of prefixes smaller than registry allocations: 150584 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 75349 Total APNIC prefixes after maximum aggregation: 26071 APNIC Deaggregation factor: 2.89 Prefixes being announced from the APNIC address blocks: 72017 Unique aggregates announced from the APNIC address blocks: 31871 APNIC Region origin ASes present in the Internet Routing Table: 3977 APNIC Prefixes per ASN: 18.11 APNIC Region origin ASes announcing only one prefix: 1085 APNIC Region transit ASes present in the Internet Routing Table: 618 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 515850304 Equivalent to 30 /8s, 191 /16s and 64 /24s Percentage of available APNIC address space announced: 80.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 131163 Total ARIN prefixes after maximum aggregation: 68106 ARIN Deaggregation factor: 1.93 Prefixes being announced from the ARIN address blocks: 104904 Unique aggregates announced from the ARIN address blocks: 40002 ARIN Region origin ASes present in the Internet Routing Table: 13569 ARIN Prefixes per ASN: 7.73 ARIN Region origin ASes announcing only one prefix: 5254 ARIN Region transit ASes present in the Internet Routing Table: 1347 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 724169376 Equivalent to 43 /8s, 41 /16s and 242 /24s Percentage of available ARIN address space announced: 61.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 72102 Total RIPE prefixes after maximum aggregation: 42129 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 65259 Unique aggregates announced from the RIPE address blocks: 43052 RIPE Region origin ASes present in the Internet Routing Table: 14192 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 7351 RIPE Region transit ASes present in the Internet Routing Table: 2126 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 417961856 Equivalent to 24 /8s, 233 /16s and 151 /24s Percentage of available RIPE address space announced: 77.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 27820 Total LACNIC prefixes after maximum aggregation: 6653 LACNIC Deaggregation factor: 4.18 Prefixes being announced from the LACNIC address blocks: 26166 Unique aggregates announced from the LACNIC address blocks: 13562 LACNIC Region origin ASes present in the Internet Routing Table: 1252 LACNIC Prefixes per ASN: 20.90 LACNIC Region origin ASes announcing only one prefix: 410 LACNIC Region transit ASes present in the Internet Routing Table: 212 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 71505152 Equivalent to 4 /8s, 67 /16s and 21 /24s Percentage of available LACNIC address space announced: 71.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6608 Total AfriNIC prefixes after maximum aggregation: 1792 AfriNIC Deaggregation factor: 3.69 Prefixes being announced from the AfriNIC address blocks: 4946 Unique aggregates announced from the AfriNIC address blocks: 1432 AfriNIC Region origin ASes present in the Internet Routing Table: 349 AfriNIC Prefixes per ASN: 14.17 AfriNIC Region origin ASes announcing only one prefix: 97 AfriNIC Region transit ASes present in the Internet Routing Table: 77 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 14953216 Equivalent to 0 /8s, 228 /16s and 43 /24s Percentage of available AfriNIC address space announced: 44.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1831 8533 469 Korea Telecom (KIX) 17488 1300 133 134 Hathway IP Over Cable Interne 4755 1284 287 136 TATA Communications formerly 18101 1052 221 41 Reliance Infocom Ltd Internet 4134 1018 19605 397 CHINANET-BACKBONE 9583 1000 75 500 Sify Limited 7545 964 199 99 TPG Internet Pty Ltd 17974 951 282 18 PT TELEKOMUNIKASI INDONESIA 24560 841 300 166 Bharti Airtel Ltd., Telemedia 9829 840 683 24 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4058 3842 311 bellsouth.net, inc. 4323 3788 1084 396 Time Warner Telecom 1785 1795 698 129 PaeTec Communications, Inc. 7018 1559 5756 1003 AT&T WorldNet Services 20115 1534 1494 666 Charter Communications 2386 1324 617 933 AT&T Data Communications Serv 3356 1222 10949 424 Level 3 Communications, LLC 11492 1151 222 14 Cable One 6478 1146 244 180 AT&T Worldnet Services 22773 1129 2604 70 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 587 40 5 United Telecom of Georgia 30890 451 101 205 Evolva Telecom 3292 450 1900 392 TDC Tele Danmark 702 421 1870 333 UUNET - Commercial IP service 8551 396 353 37 Bezeq International 8866 392 117 18 Bulgarian Telecommunication C 3320 363 7072 317 Deutsche Telekom AG 3301 355 1413 316 TeliaNet Sweden 3215 347 3206 103 France Telecom Transpac 12479 330 576 5 Uni2 Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1580 2893 236 UniNet S.A. de C.V. 10620 1011 227 154 TVCABLE BOGOTA 28573 909 715 86 NET Servicos de Comunicao S.A 7303 679 359 99 Telecom Argentina Stet-France 22047 533 310 15 VTR PUNTO NET S.A. 6503 498 167 193 AVANTEL, S.A. 7738 477 922 30 Telecomunicacoes da Bahia S.A 11830 474 308 56 Instituto Costarricense de El 18881 452 268 11 Global Village Telecom 3816 449 194 69 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 913 445 10 TEDATA 24863 709 144 41 LINKdotNET AS number 36992 573 131 167 Etisalat MISR 3741 274 853 233 The Internet Solution 33776 224 14 8 Starcomms Nigeria Limited 2018 211 215 121 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 171 19 9 Ci Telecom Autonomous system 24835 136 78 11 RAYA Telecom - Egypt 29975 133 506 14 Vodacom Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4058 3842 311 bellsouth.net, inc. 4323 3788 1084 396 Time Warner Telecom 4766 1831 8533 469 Korea Telecom (KIX) 1785 1795 698 129 PaeTec Communications, Inc. 8151 1580 2893 236 UniNet S.A. de C.V. 7018 1559 5756 1003 AT&T WorldNet Services 20115 1534 1494 666 Charter Communications 2386 1324 617 933 AT&T Data Communications Serv 17488 1300 133 134 Hathway IP Over Cable Interne 4755 1284 287 136 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3788 3392 Time Warner Telecom 1785 1795 1666 PaeTec Communications, Inc. 4766 1831 1362 Korea Telecom (KIX) 8151 1580 1344 UniNet S.A. de C.V. 17488 1300 1166 Hathway IP Over Cable Interne 4755 1284 1148 TATA Communications formerly 11492 1151 1137 Cable One 22773 1129 1059 Cox Communications, Inc. 18566 1059 1049 Covad Communications 18101 1052 1011 Reliance Infocom Ltd Internet Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.77.236.0/22 23456 32-bit ASN transition 41.190.64.0/22 28683 Office des Postes et telecomm 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.216.32.0/19 28683 Office des Postes et telecomm 41.220.144.0/20 36918 ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 36918 ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 36938 Amsco Telecommunications Nige Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:66 /12:188 /13:389 /14:666 /15:1232 /16:10973 /17:5173 /18:8739 /19:18132 /20:22044 /21:22254 /22:28672 /23:28359 /24:163874 /25:931 /26:1162 /27:589 /28:223 /29:14 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2626 4058 bellsouth.net, inc. 4323 2352 3788 Time Warner Telecom 4766 1450 1831 Korea Telecom (KIX) 1785 1258 1795 PaeTec Communications, Inc. 11492 1061 1151 Cable One 17488 1054 1300 Hathway IP Over Cable Interne 18566 1040 1059 Covad Communications 7018 943 1559 AT&T WorldNet Services 18101 918 1052 Reliance Infocom Ltd Internet 10620 917 1011 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:12 8:244 12:1981 13:10 15:22 16:3 17:8 20:39 24:1360 27:1 32:48 38:648 40:100 41:1977 44:3 46:1 47:26 52:6 55:2 56:2 57:23 58:644 59:637 60:401 61:1095 62:1073 63:1979 64:3831 65:2358 66:4152 67:1802 68:1047 69:2843 70:694 71:241 72:1871 73:2 74:2137 75:244 76:316 77:826 78:568 79:411 80:992 81:767 82:452 83:451 84:653 85:1020 86:385 87:679 88:422 89:1533 90:77 91:2708 92:435 93:1134 94:1387 95:542 96:229 97:305 98:503 99:27 109:417 110:284 111:455 112:239 113:246 114:369 115:597 116:1034 117:635 118:392 119:935 120:149 121:844 122:1381 123:852 124:1072 125:1287 128:208 129:205 130:139 131:486 132:219 133:17 134:195 135:45 136:227 137:170 138:241 139:93 140:475 141:137 142:379 143:349 144:396 145:48 146:413 147:168 148:581 149:216 150:151 151:168 152:257 153:167 154:2 155:279 156:181 157:324 158:97 159:357 160:307 161:178 162:270 163:165 164:311 165:493 166:507 167:392 168:788 169:163 170:699 171:46 172:1 173:550 174:540 175:61 178:5 180:359 182:29 183:230 184:16 186:312 187:218 188:1136 189:698 190:3562 192:5720 193:4537 194:3360 195:2796 196:1173 198:3550 199:3377 200:5286 201:1484 202:8021 203:8329 204:4077 205:2168 206:2513 207:3040 208:3919 209:3451 210:2516 211:1193 212:1695 213:1694 214:267 215:61 216:4482 217:1507 218:472 219:423 220:1071 221:380 222:308 End of report From tony at lava.net Fri Mar 12 13:06:18 2010 From: tony at lava.net (Antonio Querubin) Date: Fri, 12 Mar 2010 09:06:18 -1000 (HST) Subject: FCC releases Internet speed test tool In-Reply-To: <1853956277-1268414907-cardhu_decombobulator_blackberry.rim.net-1123414082-@bda2625.bisx.prod.on.blackberry> References: <1853956277-1268414907-cardhu_decombobulator_blackberry.rim.net-1123414082-@bda2625.bisx.prod.on.blackberry> Message-ID: On Fri, 12 Mar 2010, charles at knownelement.com wrote: > Does it work with IPv6? Not by default as it seems the content server is IPv4 enabled only. I suppose the Ookla-based tool would work over IPv6 also if the content server was setup for IPv6. Speedtest.net's tool works over IPv6 if the content server is IPv6 enabled. Broadbandreports.com's tool reportedly works over IPv6 if you enable Java to use IPv6 and the content server is IPv6 enabled. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From smb at cs.columbia.edu Fri Mar 12 13:22:03 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 12 Mar 2010 14:22:03 -0500 Subject: FCC releases Internet speed test tool In-Reply-To: <20100312105751.2C06AC65@resin16.mta.everyone.net> References: <20100312105751.2C06AC65@resin16.mta.everyone.net> Message-ID: <2D526345-50E1-4028-8BD8-763DF80CD9CF@cs.columbia.edu> On Mar 12, 2010, at 1:57 PM, Scott Weeks wrote: > > > --- tme at americafree.tv wrote: > From: Marshall Eubanks > > This might be useful to some. Article : > http://www.reuters.com/article/idUSTRE62B08720100312 > > site :http://www.broadband.gov/ > > It requires giving your address. > ----------------------------------------------- > > > Nah, no real address needed. Just use 123 elm street abbeville alabama > 36310. That's the first zip code I found on a site... ;-) What they really need is something more or less like an accurate zip code, I suspect. They want to find out what real "broadband" speeds are in different parts of the country. Putting in a fake address renders your data useless. One can ask why they aren't using IP geolocation; I suspect it's because it's not accurate enough. Your address? They may be interested in how many cable-feet you are from a CO, for DSL linkes. Now -- under the Privacy Act, if they're collecting addresses I believe they had to do a Privacy Impact Assessment. Since I can't imagine why it would be classified, it should be publicly available. I don't see it, but I don't have time today to look for it. --Steve Bellovin, http://www.cs.columbia.edu/~smb From w.d.clayton at gmail.com Fri Mar 12 13:22:48 2010 From: w.d.clayton at gmail.com (Will Clayton) Date: Fri, 12 Mar 2010 13:22:48 -0600 Subject: Comcast Metro Ethernet In-Reply-To: References: Message-ID: <69069bc21003121122h67755ba1m9a8528a958f45c1a@mail.gmail.com> Comcasts Metro-E products are pretty stable. The topology of those networks is fault tolerant with geographically diverse entry to the fabric for a given premises are usually available. The non-PtP connections you are referring to would be called Direct Internet Access, or DIA, but might have another name depending on the market. I worked on some of the Metro-E early on in Houston and can say these networks are composed of very high end hardware with only the most stable firmware loaded, and taken care of by some of the most capable people in the industry. The networks are monitored in real time for outages, and getting very straightforward RFOs and ETAs never seems to be a problem. There you go! On Fri, Mar 12, 2010 at 10:33 AM, Jeffrey Negro wrote: > We are currently in talks with Comcast with regards to their metro > ethernet products in New Jersey and Illinois, for internet bandwidth > not L2/PTP. I'd like to hear opinions from others who have the > service, in regards to uptime, support, and performance. Thank you in > advance! > > -- > Jeffrey Negro > > From tony at lava.net Fri Mar 12 13:23:52 2010 From: tony at lava.net (Antonio Querubin) Date: Fri, 12 Mar 2010 09:23:52 -1000 (HST) Subject: FCC releases Internet speed test tool In-Reply-To: <1268418889.802182.3230@marut.quarterman.com> References: <1268418889.802182.3230@marut.quarterman.com> Message-ID: On Fri, 12 Mar 2010, John S. Quarterman wrote: > Anybody who wants to do it better, here's your chance: > > https://www.fbo.gov/utils/view?id=cb712eb3ef384ebe25bfbf6b0a5dfa16 Seems they'd be better off just gathering data from existing speedtest networks. But speed isn't the only issue they should be looking at. If the government really wants to make significant, long-term improvements to the national network infrastructure, it also needs to be encouraging deployment of multicast and IPv6 to the end-user. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From nanog at konadogs.net Fri Mar 12 13:24:40 2010 From: nanog at konadogs.net (Nate Itkin) Date: Fri, 12 Mar 2010 09:24:40 -1000 Subject: FCC releases Internet speed test tool In-Reply-To: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> References: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> Message-ID: <20100312192440.GF14414@l1.konadogs.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, Mar 12, 2010 at 08:43:22AM -0500, Marshall Eubanks wrote: > [ ... ] > http://www.broadband.gov/ If you can't get there, check DNSSEC first.... Lame server or bad signature: Mar 12 08:57:57 mx1 named[18363]: no valid KEY resolving 'www.broadband.gov/A/IN': 192.104.54.4#53 I'll send e-mail to dns-admin-at-fcc.gov, but that's probably a black hole. If anyone has a contact at fcc.gov, please let them know. Nate Itkin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJLmpS5AAoJEDCWEYiadXeZqOsH/j8zsyQJHprWW4B2Zy5cdomb mrMbfgIO6uCYPS6CFTEzmFYY9ggTnBTl6UR3E5X73riBlp+mocM+VP0l9J3LB90Y uzVjItZEpnXjZ1ZfuneLXH9MisU5LXRfWMgTNU/vW1UtTW9pNGqp41eQp7/7Ojg7 r9c7pXwhga1UEpkORV/4fbDUXy8liI5CPaybF9YkePcUFhUAPLC1PqibgUPcQ4Ob L3H3jq6c2XP/bK4c7k/tJ39JO02EsaR7JrOriHFrRqN/NfAbuhnLiJpgnEWBHmOL 9ilqWeVs0AVimIgM7fdUelooWUt2NGzOtuHP1UcdyB4ADFazwJI9N09IaVvn7l4= =5r1z -----END PGP SIGNATURE----- From surfer at mauigateway.com Fri Mar 12 13:34:52 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 12 Mar 2010 11:34:52 -0800 Subject: FCC releases Internet speed test tool Message-ID: <20100312113452.2BE8FD6D@resin05.mta.everyone.net> --- smb at cs.columbia.edu wrote: From: Steven Bellovin On Mar 12, 2010, at 1:57 PM, Scott Weeks wrote: > It requires giving your address. > ----------------------------------------------- > > Nah, no real address needed. Just use 123 elm street abbeville alabama > 36310. That's the first zip code I found on a site... ;-) Putting in a fake address renders your data useless. Now -- under the Privacy Act, if they're collecting addresses I believe they had to do a Privacy Impact Assessment. --------------------------------------------- I don't like giving my address out to anyone that asks for it. I just wanted to sniff the traffic and see what was going on. I wasn't too concerned with being a valid data point. Cmon, I believe you know some security stuff and why I might chose to do that... ;-) scott ps. there's a helluva delay going on on the list today... From LarrySheldon at cox.net Fri Mar 12 13:43:11 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 12 Mar 2010 13:43:11 -0600 Subject: FCC releases Internet speed test tool In-Reply-To: <2D526345-50E1-4028-8BD8-763DF80CD9CF@cs.columbia.edu> References: <20100312105751.2C06AC65@resin16.mta.everyone.net> <2D526345-50E1-4028-8BD8-763DF80CD9CF@cs.columbia.edu> Message-ID: <4B9A994F.9020202@cox.net> On 3/12/2010 13:22, Steven Bellovin wrote: > > On Mar 12, 2010, at 1:57 PM, Scott Weeks wrote: > >> >> >> --- tme at americafree.tv wrote: From: Marshall Eubanks >> >> >> This might be useful to some. Article : >> http://www.reuters.com/article/idUSTRE62B08720100312 >> >> site :http://www.broadband.gov/ >> >> It requires giving your address. >> ----------------------------------------------- >> >> >> Nah, no real address needed. Just use 123 elm street abbeville >> alabama 36310. That's the first zip code I found on a site... >> ;-) > > What they really need is something more or less like an accurate zip > code, I suspect. They want to find out what real "broadband" speeds > are in different parts of the country. Putting in a fake address > renders your data useless. One can ask why they aren't using IP > geolocation; I suspect it's because it's not accurate enough. Your > address? They may be interested in how many cable-feet you are from > a CO, for DSL linkes. > > Now -- under the Privacy Act, if they're collecting addresses I > believe they had to do a Privacy Impact Assessment. Since I can't > imagine why it would be classified, it should be publicly available. > I don't see it, but I don't have time today to look for it. They are supposed to pay their income taxes too. Color me paranoid if you like, but I worry that if you play their game and DON'T answer the questions accurately and honestly, you have set yourself up for a bad ride for lying to an Official Government Agency. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From nikky at mnet.bg Fri Mar 12 13:51:34 2010 From: nikky at mnet.bg (Nickola Kolev) Date: Fri, 12 Mar 2010 21:51:34 +0200 Subject: MOCA Message-ID: <20100312215134.390ae53f.nikky@mnet.bg> Hello list, Does anyone have any recommendations as to whether MOCA upgrade path of coaxial DOCSIS last-mile is worth? >From my experience, nobody from the vendors listed in the MOCA Aliance cerified vendors has a real interest in contacting back. That's why I think that maybe that technolody hasnt hit (yet?) any real deployments. HCNA/HPNA is a no-go because of 20-40MHz being used by DOCSIS modems. Do I have any other options? Of course, any replies can hit me off-list, if not appropriate. -- Best regards, Nickola From tony at lava.net Fri Mar 12 14:03:46 2010 From: tony at lava.net (Antonio Querubin) Date: Fri, 12 Mar 2010 10:03:46 -1000 (HST) Subject: FCC releases Internet speed test tool In-Reply-To: <1268418889.802182.3230@marut.quarterman.com> References: <1268418889.802182.3230@marut.quarterman.com> Message-ID: On Fri, 12 Mar 2010, John S. Quarterman wrote: > Anybody who wants to do it better, here's your chance: > > https://www.fbo.gov/utils/view?id=cb712eb3ef384ebe25bfbf6b0a5dfa16 Hmm, although it lists a number of FAR clauses but it seems none of them reference the new requirements for IPv6: http://edocket.access.gpo.gov/2009/E9-28931.htm Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From mike.hertrick at neovera.com Fri Mar 12 14:27:33 2010 From: mike.hertrick at neovera.com (Michael Hertrick) Date: Fri, 12 Mar 2010 15:27:33 -0500 Subject: CIS Router Audit Tool - Project Underway to Update Config Rules Message-ID: <4B9AA3B5.2050503@neovera.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I've recently begun updating the config rules for the CIS Router Audit Tool (RAT) distribution. For those who have never heard of RAT, it is a perl-based utility written by George M. Jones to audit router configurations. It can be used to audit virtually any text file by writing custom rules. Until now, the CIS RAT distribution did not support any Cisco Firewall configs beyond v6.x. I've added a new cisco-firewall config type that supports the latest Cisco PIX/ASA/FWSM configurations. The new rules are based on the CIS Benchmark for Cisco Firewall Devices v2.0 (NOV2007). They've only been tested on my own PIX/ASA/FWSM configurations. If anyone is interested in helping test and improve these rules before they're included in an official distribution, you can join the CIS Community Project - CIS Router Audit Tool at: http://cisecurity.org/en-us/?route=community.projects You can either checkout the latest from SVN or download one of the archives attached to the latest discusson "REQUESTED ACTION: Verify that RAT is able to consume your Cisco PIX, ASA, and FWSM configurations." Please post your results, comments, and questions to the CIS Router Audit Tool Community Project Discussions page along with pertinent information such as device model, OS version, and the rule names/numbers that were tested. Also include any other information that could be useful such as whether the firewall is in multi-context or transparent mode. For anyone wondering about Cisco IOS, soon we will also begin updating the cisco-ios config rules to better support newer IOS versions and bring the rules up to the latest CIS benchmark. I'd like to see other config types added, too, like JunOS for example. Essentially all it takes to write a RAT config-type for CIS is a benchmark, some patience, and the ability to write regular-expressions. If you're up for it, let me know. Regards, Michael Hertrick Neovera, Inc. - -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - - against proprietary attachments -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuao7UACgkQcJVdtfpkLb+tVQCeLV6MWJAARiF7FG6NS1TnJ8lN aPQAn2KDSfJuDytYcgU24ZLnx8lY2WSk =S2BB -----END PGP SIGNATURE----- From fred at cisco.com Fri Mar 12 15:10:26 2010 From: fred at cisco.com (Fred Baker) Date: Fri, 12 Mar 2010 13:10:26 -0800 Subject: FCC releases Internet speed test tool In-Reply-To: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> References: <9085B96B-EF03-4BC9-86C7-BC096D5E3A63@americafree.tv> Message-ID: <79E60DFC-4638-4DB9-9A56-F7B243B03062@cisco.com> On Mar 12, 2010, at 5:43 AM, Marshall Eubanks wrote: > http://www.broadband.gov/ I'm listening to all this and thinking through the questions the FCC might be asking. I'm also trying to do a somewhat-controlled test, which I'll give you the first several samples of. See attached. I picked up your note at ~7:10 PST this morning and set up some timed commands to remind myself to try this out once an hour at a few minutes before my various meetings start. I'm testing speakeasy against speedtest against the two broadband.gov engines, plus pingtest just for fun. I am of course at work today, woking from home. For the record, I am a Cox Business subscriber, and my contract is 2 MBPS down and 384 KBPS up. That implies I'm not going see tens of MBPS, and I would be surprised if the numbers were significantly different than advertised as I am by definition paying more money for less service. Some of the tests will run in parallel with my daily workload, and I'll try to keep that straight. What may impinge is mail downloads, which happen under the hood and aren't necessarily visible at the time I initiate a test. An observation on the various comments that "going to a test service operated somewhere other than my POP is a dumb idea": it depends on what you're measuring. If you're measuring, as I imagine those commentators are, what bit rate is available on the link between the residential subscriber and the ISP and therefore whether the contract is being met, the point is well taken. If the point is "what is a reasonable expectation of bandwidth when accessing various things on the Internet", the ISP's internal connectivity, connectivity to its upstream, and to its peers is also relevant - and from an FCC Net Neutrality perspective pretty important. A fairly common report several years ago was that on DSL networks one might get a high rate through the very last mile but often got mere tens of KBPS through the back end network, and DSL marketing made the same comment about Cable Modem networks. When I buy a certain rate from an ISP, the point is not to talk with the ISP at that rate; the point is to be able to do what I do, such as running a VPN across and to/from , or access content on the web. Another observation: when a subscriber buys a bit rate, the bit rate includes IP headers, link layer overhead, etc. If I use FTP to test my rate, it is measuring the rate at which TCP can deliver user data, which is to say that it omits the TCP, IP, and link layer overheads, which are on the order of 3-4% of the bandwidth. If I were running one of these tests over a circuit switch link such as a T-1, it would not measure that it was delivering 1.544 MBPS plus or minus 75 ppm; it would measure somewhat less considering both physical layer overheads (2/193 gets lost out of a T-1 frame) and TCP/IP overheads. What I have seen so far this morning is that speakeasy, speedtest, and the two broadband.gov sites come up with about the same numbers, modulo obvious issues of being different tests at slightly different times. The one difference there is with broadband.gov/MLAB: it seems to measure my upload rate at about half of contract rate the first time I test it, and then measure something approximating the contract if I repeat the test. No idea what that really means - if it randomly was high and low I could argue that it is a capacity-at-tester or "did POP download email?" issue, but since it always the first test that is low it suggests something relevant to the sequence. From ax1986 at web.de Fri Mar 12 15:20:35 2010 From: ax1986 at web.de (Axel Morawietz) Date: Fri, 12 Mar 2010 22:20:35 +0100 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: References: <1268384007.1220.21.camel@petrie> Message-ID: <4B9AB023.2070903@web.de> Am 12.03.2010 17:03, schrieb Nathan: > [...] Its > amazing how prolific 1.x traffic is. one reason might also be, that at least T-Mobile Germany uses 1.2.3.* for their proxies that deliver the content to mobile phones. And I'm not sure what they are doing when they are going to receive this route from external. ;) From kloch at kl.net Fri Mar 12 15:34:32 2010 From: kloch at kl.net (Kevin Loch) Date: Fri, 12 Mar 2010 16:34:32 -0500 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <4B9AB023.2070903@web.de> References: <1268384007.1220.21.camel@petrie> <4B9AB023.2070903@web.de> Message-ID: <4B9AB368.8030601@kl.net> Axel Morawietz wrote: > Am 12.03.2010 17:03, schrieb Nathan: >> [...] Its >> amazing how prolific 1.x traffic is. > > one reason might also be, that at least T-Mobile Germany uses 1.2.3.* > for their proxies that deliver the content to mobile phones. > And I'm not sure what they are doing when they are going to receive this > route from external. ;) If 1.0.0.0/8 has been widely used as de-facto rfc1918 for many years, perhaps it is time to update rfc1918 to reflect this? - Kevin From sparctacus at gmail.com Fri Mar 12 15:40:14 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Fri, 12 Mar 2010 13:40:14 -0800 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <4B9AB368.8030601@kl.net> References: <1268384007.1220.21.camel@petrie> <4B9AB023.2070903@web.de> <4B9AB368.8030601@kl.net> Message-ID: <53d706301003121340qca49cf6p439148b9251de8d1@mail.gmail.com> On Fri, Mar 12, 2010 at 1:34 PM, Kevin Loch wrote: > Axel Morawietz wrote: >> >> Am 12.03.2010 17:03, schrieb Nathan: >>> >>> [...] Its >>> amazing how prolific 1.x traffic is. >> >> one reason might also be, that at least T-Mobile Germany uses 1.2.3.* >> for their proxies that deliver the content to mobile phones. >> And I'm not sure what they are doing when they are going to receive this >> route from external. ;) > > If 1.0.0.0/8 has been widely used as de-facto rfc1918 for many years, > perhaps it is time to update rfc1918 to reflect this? Cisco has an interesting write-up on this: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_10-3/103_awkward.html From leo.vegoda at icann.org Fri Mar 12 15:44:54 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 12 Mar 2010 13:44:54 -0800 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <4B9AB368.8030601@kl.net> References: <1268384007.1220.21.camel@petrie> <4B9AB023.2070903@web.de> <4B9AB368.8030601@kl.net> Message-ID: <2E01065A-3A47-443E-86E0-39DB85FDBA56@icann.org> On 12 Mar 2010, at 1:34, Kevin Loch wrote: > Axel Morawietz wrote: >> Am 12.03.2010 17:03, schrieb Nathan: >>> [...] Its >>> amazing how prolific 1.x traffic is. >> >> one reason might also be, that at least T-Mobile Germany uses 1.2.3.* >> for their proxies that deliver the content to mobile phones. >> And I'm not sure what they are doing when they are going to receive this >> route from external. ;) > > If 1.0.0.0/8 has been widely used as de-facto rfc1918 for many years, > perhaps it is time to update rfc1918 to reflect this? Marla and I have drafted a document examining the issues associated with designating additional private address space: http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-issues-03 Please let us know if you have suggestions for improvements to the document. Leo From jgreco at ns.sol.net Fri Mar 12 15:45:22 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 12 Mar 2010 15:45:22 -0600 (CST) Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <4B9AB368.8030601@kl.net> from "Kevin Loch" at Mar 12, 2010 04:34:32 PM Message-ID: <201003122145.o2CLjM9K015540@aurora.sol.net> > Axel Morawietz wrote: > > Am 12.03.2010 17:03, schrieb Nathan: > >> [...] Its > >> amazing how prolific 1.x traffic is. > > > > one reason might also be, that at least T-Mobile Germany uses 1.2.3.* > > for their proxies that deliver the content to mobile phones. > > And I'm not sure what they are doing when they are going to receive this > > route from external. ;) > > If 1.0.0.0/8 has been widely used as de-facto rfc1918 for many years, > perhaps it is time to update rfc1918 to reflect this? There's no way it's as widely used, and generally speaking, it appears that those who have used it have done so out of ignorance and(/or?) stupidity, sometimes blindly following documentation without comprehending, etc. It isn't clear that the Internet should give up a large chunk of address space because some businesses made poor business choices. After all, we already allocated a bunch of private space for them to use. ... 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 nathan at stonekitty.net Fri Mar 12 15:46:11 2010 From: nathan at stonekitty.net (Nathan) Date: Fri, 12 Mar 2010 13:46:11 -0800 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <4B9AB368.8030601@kl.net> References: <1268384007.1220.21.camel@petrie> <4B9AB023.2070903@web.de> <4B9AB368.8030601@kl.net> Message-ID: There are sizable chunks that are fairly quiet (un-interesting numbers, luck of the draw, etc). Given that its mostly mis-configurations, laziness, ignorance, or poor planning... I suspect the worst ranges will need to be sacrificed, and the remaining 80-90% of the space used for legitimate allocations. Unfortunately, anyone who accepts allocations in 1.x will need to be aware that they will have a slightly lower quality address-space. Accepting 1.1.1.0/24, for example, will land you with a continuous 50mbps of junk... seemingly forever... and a respectable chance that some percentage of the net will never reach you, due to their own misconfigurations. ,N On Fri, Mar 12, 2010 at 1:34 PM, Kevin Loch wrote: > Axel Morawietz wrote: >> >> Am 12.03.2010 17:03, schrieb Nathan: >>> >>> [...] Its >>> amazing how prolific 1.x traffic is. >> >> one reason might also be, that at least T-Mobile Germany uses 1.2.3.* >> for their proxies that deliver the content to mobile phones. >> And I'm not sure what they are doing when they are going to receive this >> route from external. ;) > > If 1.0.0.0/8 has been widely used as de-facto rfc1918 for many years, > perhaps it is time to update rfc1918 to reflect this? > > - Kevin > > > From jgreco at ns.sol.net Fri Mar 12 15:53:23 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 12 Mar 2010 15:53:23 -0600 (CST) Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: from "Nathan" at Mar 12, 2010 01:46:11 PM Message-ID: <201003122153.o2CLrNgn015793@aurora.sol.net> > There are sizable chunks that are fairly quiet (un-interesting > numbers, luck of the draw, etc). Given that its mostly > mis-configurations, laziness, ignorance, or poor planning... I suspect > the worst ranges will need to be sacrificed, and the remaining 80-90% > of the space used for legitimate allocations. Unfortunately, anyone > who accepts allocations in 1.x will need to be aware that they will > have a slightly lower quality address-space. Accepting 1.1.1.0/24, > for example, will land you with a continuous 50mbps of junk... > seemingly forever... and a respectable chance that some percentage of > the net will never reach you, due to their own misconfigurations. Practical solution: Move YouTube to 1.1.1.1, Google to 1.1.1.2, Yahoo! to 1.1.1.3, Facebook to 1.1.1.4, etc. Maybe someone at YouTube was actually testing that strategy ;-) ... 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 cidr-report at potaroo.net Fri Mar 12 16:00:01 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Mar 2010 22:00:01 GMT Subject: BGP Update Report Message-ID: <201003122200.o2CM01hH098295@wattle.apnic.net> BGP Update Report Interval: 04-Mar-10 -to- 11-Mar-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30890 35760 3.2% 80.4 -- EVOLVA Evolva Telecom s.r.l. 2 - AS45985 21116 1.9% 5279.0 -- DAEWOOSEC Daewoo Securities Co., Ltd. 3 - AS31055 18402 1.6% 4600.5 -- CONSULTIX-AS Consultix GmbH 4 - AS9829 18400 1.6% 37.3 -- BSNL-NIB National Internet Backbone 5 - AS8346 16928 1.5% 2821.3 -- SONATEL-AS Autonomous System 6 - AS10620 16905 1.5% 16.7 -- Telmex Colombia S.A. 7 - AS17974 15853 1.4% 20.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS35805 12051 1.1% 21.0 -- UTG-AS United Telecom AS 9 - AS23950 10843 1.0% 1084.3 -- GENID-AS-ID Generasi Indonesia Digital PT. 10 - AS7738 10815 0.9% 22.7 -- Telecomunicacoes da Bahia S.A. 11 - AS8452 9604 0.8% 18.1 -- TEDATA TEDATA 12 - AS16569 8154 0.7% 8154.0 -- ASN-CITY-OF-CALGARY - City of Calgary 13 - AS36992 7292 0.6% 12.6 -- ETISALAT-MISR 14 - AS4657 7285 0.6% 27.4 -- STARHUBINTERNET-AS StarHub Internet Exchange 15 - AS26025 7147 0.6% 7147.0 -- COC - City of Calgary 16 - AS12479 7059 0.6% 21.3 -- UNI2-AS Uni2 - Lince telecomunicaciones 17 - AS5800 6890 0.6% 33.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS33475 6684 0.6% 26.7 -- RSN-1 - RockSolid Network, Inc. 19 - AS25438 6616 0.6% 89.4 -- ASN-ICCNET International Computer Company ICC 20 - AS14420 6559 0.6% 16.3 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16569 8154 0.7% 8154.0 -- ASN-CITY-OF-CALGARY - City of Calgary 2 - AS26025 7147 0.6% 7147.0 -- COC - City of Calgary 3 - AS45985 21116 1.9% 5279.0 -- DAEWOOSEC Daewoo Securities Co., Ltd. 4 - AS31055 18402 1.6% 4600.5 -- CONSULTIX-AS Consultix GmbH 5 - AS8346 16928 1.5% 2821.3 -- SONATEL-AS Autonomous System 6 - AS27097 5602 0.5% 1400.5 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 7 - AS10052 1391 0.1% 1391.0 -- KNU-AS Kyungpook National Univ. 8 - AS23950 10843 1.0% 1084.3 -- GENID-AS-ID Generasi Indonesia Digital PT. 9 - AS5691 2431 0.2% 810.3 -- MITRE-AS-5 - The MITRE Corporation 10 - AS5554 663 0.1% 663.0 -- INTEGRA Integra Information Co. Ltd 11 - AS29661 650 0.1% 650.0 -- INTI-AS INTI Autonomous System 12 - AS5311 602 0.1% 602.0 -- DNIC-ASBLK-05120-05376 - DoD Network Information Center 13 - AS34875 2340 0.2% 585.0 -- YANFES OJSC "Uralsviazinform" 14 - AS45960 582 0.1% 582.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 15 - AS22395 579 0.1% 579.0 -- GHCO-INTERNAP - Goldenberg Hehmeyer 16 - AS28255 567 0.1% 567.0 -- 17 - AS1619 443 0.0% 443.0 -- PLANET-DATA - Planet Data Solutions, Inc. 18 - AS10445 2498 0.2% 416.3 -- HTG - Huntleigh Telcom 19 - AS28052 395 0.0% 395.0 -- Arte Radiotelevisivo Argentino 20 - AS30620 389 0.0% 389.0 -- CO-DATACENTER - APPLIED SYSTEMS, INC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 62.168.199.0/24 18307 1.5% AS31055 -- CONSULTIX-AS Consultix GmbH 2 - 208.98.230.0/24 8154 0.7% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - 208.98.231.0/24 7147 0.6% AS26025 -- COC - City of Calgary 4 - 210.92.10.0/24 5842 0.5% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 5 - 123.140.107.0/24 5842 0.5% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 6 - 210.92.4.0/24 5842 0.5% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 7 - 208.154.200.0/24 5690 0.5% AS8346 -- SONATEL-AS Autonomous System 8 - 208.154.199.0/24 5620 0.5% AS8346 -- SONATEL-AS Autonomous System 9 - 208.144.230.0/24 5605 0.5% AS8346 -- SONATEL-AS Autonomous System 10 - 41.235.80.0/24 5536 0.5% AS8452 -- TEDATA TEDATA 11 - 214.15.217.0/24 5458 0.5% AS27097 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 12 - 202.51.30.0/24 5367 0.4% AS23950 -- GENID-AS-ID Generasi Indonesia Digital PT. 13 - 202.51.16.0/20 5296 0.4% AS23950 -- GENID-AS-ID Generasi Indonesia Digital PT. 14 - 210.92.6.0/24 3616 0.3% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. AS9532 -- SECURITIES-AS Daewoo Securities Co., Ltd. 15 - 199.114.154.0/24 2837 0.2% AS1733 -- CENTAF-SWA - 754th Electronic Systems Group 16 - 85.60.192.0/23 2785 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 17 - 192.12.120.0/24 2429 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 18 - 212.220.14.0/24 2214 0.2% AS34875 -- YANFES OJSC "Uralsviazinform" 19 - 85.204.64.0/23 2029 0.2% AS6746 -- ASTRAL UPC Romania Srl, Romania 20 - 206.184.16.0/24 1870 0.1% AS174 -- COGENT Cogent/PSI Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 12 16:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Mar 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201003122200.o2CM0052098289@wattle.apnic.net> This report has been generated at Fri Mar 12 21:11:28 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 05-03-10 315456 194667 06-03-10 315707 194826 07-03-10 315664 194770 08-03-10 315807 194822 09-03-10 315764 194512 10-03-10 315915 194538 11-03-10 316167 194494 12-03-10 316317 194783 AS Summary 33834 Number of ASes in routing system 14424 Number of ASes announcing only one prefix 4394 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 93176320 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'). --- 12Mar10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 316321 194718 121603 38.4% All ASes AS6389 4058 316 3742 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4394 1841 2553 58.1% TWTC - tw telecom holdings, inc. AS4766 1831 483 1348 73.6% KIXS-AS-KR Korea Telecom AS1785 1795 660 1135 63.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1284 213 1071 83.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1129 75 1054 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1059 33 1026 96.9% COVAD - Covad Communications Co. AS17488 1300 362 938 72.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1575 664 911 57.8% Uninet S.A. de C.V. AS10620 1011 168 843 83.4% Telmex Colombia S.A. AS19262 1081 245 836 77.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18101 1052 250 802 76.2% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS7545 991 246 745 75.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS6478 1146 435 711 62.0% ATT-INTERNET3 - AT&T WorldNet Services AS4804 678 72 606 89.4% MPX-AS Microplex PTY LTD AS5668 803 197 606 75.5% AS-5668 - CenturyTel Internet Holdings, Inc. AS4808 837 234 603 72.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 679 107 572 84.2% Telecom Argentina S.A. AS28573 910 343 567 62.3% NET Servicos de Comunicao S.A. AS8452 913 347 566 62.0% TEDATA TEDATA AS4134 1018 458 560 55.0% CHINANET-BACKBONE No.31,Jin-rong Street AS7018 1566 1008 558 35.6% ATT-INTERNET4 - AT&T WorldNet Services AS24560 840 292 548 65.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1224 679 545 44.5% LEVEL3 Level 3 Communications AS17908 768 230 538 70.1% TCISL Tata Communications AS11492 1151 646 505 43.9% CABLEONE - CABLE ONE, INC. AS4780 633 140 493 77.9% SEEDNET Digital United Inc. AS17676 575 87 488 84.9% GIGAINFRA Softbank BB Corp. AS9443 555 75 480 86.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS22047 533 60 473 88.7% VTR BANDA ANCHA S.A. Total 37389 10966 26423 70.7% Top 30 total Possible Bogus Routes 1.0.0.0/8 AS36561 YOUTUBE - YouTube, Inc. 2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.77.236.0/22 AS5.8 41.190.64.0/22 AS28683 BENINTELECOM 41.202.96.0/19 AS29571 CITelecom-AS 41.220.144.0/20 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.24.0/22 AS25747 VSC-SATELLITE-CO - VSC Satellite Co. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 50.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.193.160.0/19 AS22351 INTELSAT Intelsat Global BGP Routing Policy 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales TelesatS.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 80.250.32.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.34.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering AS 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 178.21.96.0/21 AS3302 INFRACOM-NETWORK-APPLICATION-AS Infracom Network Application S.p.A. 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.29.40.0/22 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 196.32.96.0/20 AS33787 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.254.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.216.4.0/22 AS23889 MAURITIUS-TELECOM-AS-AP 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.77.138.0/23 AS24487 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.184.0/23 AS24487 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.20.115.0/24 AS10223 UECOMM-AU Uecomm Ltd 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.124.96.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.100.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.104.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.160.130.0/23 AS24487 203.160.140.0/24 AS45560 203.160.141.0/24 AS10026 ANC Asia Netcom Corporation 203.160.142.0/24 AS45560 203.160.143.0/24 AS10026 ANC Asia Netcom Corporation 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/24 AS31997 209.87.223.0/24 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.29.208.0/23 AS33774 DJAWEB 217.29.212.0/23 AS33774 DJAWEB Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From gfortaine at live.com Fri Mar 12 17:05:43 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Sat, 13 Mar 2010 00:05:43 +0100 Subject: OBESEUS - A new type of DDOS protector Message-ID: Misters, Let me introduce myself : Guillaume FORTAINE, Engineer in Computer Science. I am currently working on High-Speed Network Security Solutions. DDoS is considered as "The Mother of All Cyber Threats" [1] therefore I have intensively studied this topic. By the way, I have read with interest the NANOG mails [2] [3] [4] and the Linkedin groups [5] [6] on this subject. Being an FPGA engineer, I approached this concern from an algorithmic point of view and that's why I would greatly appreciate to have your comments on this project, if possible, please : "OBESEUS - A new type of DDOS protector" [7] http://www.loud-fat-bloke.co.uk/obeseus2.pdf For a better overview of the background of the project, please see the following document : "INQUIRY INTO EU POLICY ON PROTECTING EUROPE FROM LARGE SCALE CYBER-ATTACKS" http://www.parliament.uk/documents/upload/F012Interoute121109.pdf I look forward to your answer, Best Regards, [1] http://events.linkedin.com/Webcast-DDoS-Mother-All-Cyber-Threats/pub/171074 [2] http://mailman.nanog.org/pipermail/nanog/2009-November/014963.html [3] http://mailman.nanog.org/pipermail/nanog/2010-January/016675.html [4] http://mailman.nanog.org/pipermail/nanog/2010-January/017604.html [5] http://www.linkedin.com/groups?home=&gid=2040519 [6] http://www.linkedin.com/groups?home=&gid=2632190 [7] http://www.loud-fat-bloke.co.uk/obeseus.html Guillaume FORTAINE Tel : +33(0)631092519 From bfeeny at mac.com Fri Mar 12 17:06:02 2010 From: bfeeny at mac.com (Brian Feeny) Date: Fri, 12 Mar 2010 18:06:02 -0500 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <4B9AB368.8030601@kl.net> References: <1268384007.1220.21.camel@petrie> <4B9AB023.2070903@web.de> <4B9AB368.8030601@kl.net> Message-ID: On Mar 12, 2010, at 4:34 PM, Kevin Loch wrote: > Axel Morawietz wrote: >> Am 12.03.2010 17:03, schrieb Nathan: >>> [...] Its >>> amazing how prolific 1.x traffic is. >> one reason might also be, that at least T-Mobile Germany uses 1.2.3.* >> for their proxies that deliver the content to mobile phones. >> And I'm not sure what they are doing when they are going to receive this >> route from external. ;) > > If 1.0.0.0/8 has been widely used as de-facto rfc1918 for many years, perhaps it is time to update rfc1918 to reflect this? > Only by people who don't know how to read RFC's and are probably responsible for screwing a bunch of other stuff up as well :) Brian > - Kevin > > From drais at icantclick.org Fri Mar 12 17:13:32 2010 From: drais at icantclick.org (david raistrick) Date: Fri, 12 Mar 2010 18:13:32 -0500 (EST) Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <201003122145.o2CLjM9K015540@aurora.sol.net> References: <201003122145.o2CLjM9K015540@aurora.sol.net> Message-ID: On Fri, 12 Mar 2010, Joe Greco wrote: >> If 1.0.0.0/8 has been widely used as de-facto rfc1918 for many years, >> perhaps it is time to update rfc1918 to reflect this? I seem to recall that the WIANA project "decided" to use 1.0.0.0/8 for the "internal" network within their meshAP project... http://www.wiana.org/faq.php random data point from memory. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From jgreco at ns.sol.net Fri Mar 12 19:06:43 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 12 Mar 2010 19:06:43 -0600 (CST) Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: from "david raistrick" at Mar 12, 2010 06:13:32 PM Message-ID: <201003130106.o2D16hmn023046@aurora.sol.net> > On Fri, 12 Mar 2010, Joe Greco wrote: > [something I didn't write] > > >> If 1.0.0.0/8 has been widely used as de-facto rfc1918 for many years, > >> perhaps it is time to update rfc1918 to reflect this? > > I seem to recall that the WIANA project "decided" to use 1.0.0.0/8 for > the "internal" network within their meshAP project... > > http://www.wiana.org/faq.php > > random data point from memory. So: I "decided" to use 5/8 for our internal networks because I felt that it stretched my fingers too much to go all the way over to "1" and then over to the other end of the top row to "0." 5 seemed a happier and easier choice. No, but really, what was your point again? IANA should go around making new Class A reservations or delegations to squatters? If so, I really *do* need to get busy and renumbering so I have a claim on 5/8.... :-) ... 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 sethm at rollernet.us Fri Mar 12 20:06:59 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 12 Mar 2010 18:06:59 -0800 Subject: PL/SQL & CIDR? In-Reply-To: <3DDC8C81-5D30-4C54-8E8E-283003E1A539@cybernothing.org> References: <3DDC8C81-5D30-4C54-8E8E-283003E1A539@cybernothing.org> Message-ID: <4B9AF343.4040704@rollernet.us> On 3/12/2010 09:13, J.D. Falk wrote: > Does anyone know of a library, sample code, etc. to help Oracle PL/SQL do CIDR math? > Not exactly sample code, but: I do that with MySQL by storing the IP as its integer value and using simple comparisons to see if that stored value is within the range of values that a given CIDR mask represents. Works great for IPv4 and IPv6 addresses. ~Seth From matthew at matthew.at Fri Mar 12 20:34:17 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 12 Mar 2010 18:34:17 -0800 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <201003130106.o2D16hmn023046@aurora.sol.net> References: <201003130106.o2D16hmn023046@aurora.sol.net> Message-ID: <4B9AF9A9.5040201@matthew.at> Joe Greco wrote: > > So: > > I "decided" to use 5/8 for our internal networks because I felt that it > stretched my fingers too much to go all the way over to "1" and then over > to the other end of the top row to "0." 5 seemed a happier and easier > choice. > > The Hamachi P2P VPN client beat you to it... they decided to use 5.0.0.0/8 several years ago. http://en.wikipedia.org/wiki/Hamachi Matthew Kaufman From matthew at matthew.at Fri Mar 12 20:36:08 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 12 Mar 2010 18:36:08 -0800 Subject: PL/SQL & CIDR? In-Reply-To: <4B9AF343.4040704@rollernet.us> References: <3DDC8C81-5D30-4C54-8E8E-283003E1A539@cybernothing.org> <4B9AF343.4040704@rollernet.us> Message-ID: <4B9AFA18.5090701@matthew.at> Seth Mattinen wrote: > On 3/12/2010 09:13, J.D. Falk wrote: > >> Does anyone know of a library, sample code, etc. to help Oracle PL/SQL do CIDR math? >> >> > > > Not exactly sample code, but: I do that with MySQL by storing the IP as > its integer value and using simple comparisons to see if that stored > value is within the range of values that a given CIDR mask represents. > Works great for IPv4 and IPv6 addresses. > > ~Seth > > I do it in MySQL by storing the IP as an integer and the mask as an integer and using bitwise operators in the SELECT. Just something to think about... Matthew Kaufman From dga at cs.cmu.edu Fri Mar 12 20:46:53 2010 From: dga at cs.cmu.edu (David Andersen) Date: Fri, 12 Mar 2010 21:46:53 -0500 Subject: PL/SQL & CIDR? In-Reply-To: <4B9AFA18.5090701@matthew.at> References: <3DDC8C81-5D30-4C54-8E8E-283003E1A539@cybernothing.org> <4B9AF343.4040704@rollernet.us> <4B9AFA18.5090701@matthew.at> Message-ID: On Mar 12, 2010, at 9:36 PM, Matthew Kaufman wrote: > Seth Mattinen wrote: >> On 3/12/2010 09:13, J.D. Falk wrote: >> >>> Does anyone know of a library, sample code, etc. to help Oracle PL/SQL do CIDR math? >>> >>> >> >> >> Not exactly sample code, but: I do that with MySQL by storing the IP as >> its integer value and using simple comparisons to see if that stored >> value is within the range of values that a given CIDR mask represents. >> Works great for IPv4 and IPv6 addresses. >> >> ~Seth >> >> > I do it in MySQL by storing the IP as an integer and the mask as an integer and using bitwise operators in the SELECT. > > Just something to think about... To expand upon this, we do this in pure SQL as Matthew suggested by generating the sql automatically. e.g., to find all routes in a BGP table that equal or contain a particular prefix: SELECT * from table WHERE (prefix = x AND mask=32) OR (prefix = x & 0xfffffffe AND mask=31) OR ... (we store BGP entries as prefix, mask). You can write a user defined function to do this for you in many languages. We chose that expansion because it worked well with the indexes defined on prefix/mask. You can also express it as CIDR math as bitwise operators, though we've found that doing so tends to destroy any indexing you've created: SELECT mask, prefix from t1 WHERE (search_prefix & ((!0) << (32 - t1.mask)) = t1.prefix) ... I can probably cough up a few more examples from our codebase if you want them. -Dave From sean at donelan.com Fri Mar 12 21:20:07 2010 From: sean at donelan.com (Sean Donelan) Date: Fri, 12 Mar 2010 22:20:07 -0500 (EST) Subject: FCC releases Internet speed test tool In-Reply-To: <2D526345-50E1-4028-8BD8-763DF80CD9CF@cs.columbia.edu> References: <20100312105751.2C06AC65@resin16.mta.everyone.net> <2D526345-50E1-4028-8BD8-763DF80CD9CF@cs.columbia.edu> Message-ID: On Fri, 12 Mar 2010, Steven Bellovin wrote: > What they really need is something more or less like an accurate zip >code, I suspect. They want to find out what real "broadband" speeds are >in different parts of the country. Putting in a fake address renders >your data useless. The FCC used to collect the data by zip code; but a few years ago Congress told the FCC that measuring broadband availability by zip code wasn't good enough. ZIP code boundaries tend to vary in size, and cross political jurisdictions. Cable system and Central Office wire areas also tend to vary in size and cross political jurisdictions, so things won't match up exactly. Now I believe FCC tries to collect broadband data by census tract. The problem is most people don't know what census tract they are in. So they are probably trying to figure out the census tract based on the postal address entered. The Federal Register notice was published at http://edocket.access.gpo.gov/2009/E9-31009.htm From cscora at apnic.net Fri Mar 12 12:54:36 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Mar 2010 04:54:36 +1000 (EST) Subject: [afnog] Weekly Routing Table Report Message-ID: <201003121854.o2CIsasF016235@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 13 Mar, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 313752 Prefixes after maximum aggregation: 145168 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 153109 Total ASes present in the Internet Routing Table: 33516 Prefixes per ASN: 9.36 Origin-only ASes present in the Internet Routing Table: 29092 Origin ASes announcing only one prefix: 14197 Transit ASes present in the Internet Routing Table: 4424 Transit-only ASes present in the Internet Routing Table: 100 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 22 Max AS path prepend of ASN (32374) 19 Prefixes from unregistered ASNs in the Routing Table: 947 Unregistered ASNs in the Routing Table: 151 Number of 32-bit ASNs allocated by the RIRs: 466 Prefixes from 32-bit ASNs in the Routing Table: 476 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 212 Number of addresses announced to Internet: 2215388000 Equivalent to 132 /8s, 12 /16s and 35 /24s Percentage of available address space announced: 59.8 Percentage of allocated address space announced: 66.4 Percentage of available address space allocated: 90.0 Percentage of address space in use by end-sites: 81.6 Total number of prefixes smaller than registry allocations: 150584 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 75349 Total APNIC prefixes after maximum aggregation: 26071 APNIC Deaggregation factor: 2.89 Prefixes being announced from the APNIC address blocks: 72017 Unique aggregates announced from the APNIC address blocks: 31871 APNIC Region origin ASes present in the Internet Routing Table: 3977 APNIC Prefixes per ASN: 18.11 APNIC Region origin ASes announcing only one prefix: 1085 APNIC Region transit ASes present in the Internet Routing Table: 618 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 515850304 Equivalent to 30 /8s, 191 /16s and 64 /24s Percentage of available APNIC address space announced: 80.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 131163 Total ARIN prefixes after maximum aggregation: 68106 ARIN Deaggregation factor: 1.93 Prefixes being announced from the ARIN address blocks: 104904 Unique aggregates announced from the ARIN address blocks: 40002 ARIN Region origin ASes present in the Internet Routing Table: 13569 ARIN Prefixes per ASN: 7.73 ARIN Region origin ASes announcing only one prefix: 5254 ARIN Region transit ASes present in the Internet Routing Table: 1347 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 724169376 Equivalent to 43 /8s, 41 /16s and 242 /24s Percentage of available ARIN address space announced: 61.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 72102 Total RIPE prefixes after maximum aggregation: 42129 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 65259 Unique aggregates announced from the RIPE address blocks: 43052 RIPE Region origin ASes present in the Internet Routing Table: 14192 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 7351 RIPE Region transit ASes present in the Internet Routing Table: 2126 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 417961856 Equivalent to 24 /8s, 233 /16s and 151 /24s Percentage of available RIPE address space announced: 77.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 27820 Total LACNIC prefixes after maximum aggregation: 6653 LACNIC Deaggregation factor: 4.18 Prefixes being announced from the LACNIC address blocks: 26166 Unique aggregates announced from the LACNIC address blocks: 13562 LACNIC Region origin ASes present in the Internet Routing Table: 1252 LACNIC Prefixes per ASN: 20.90 LACNIC Region origin ASes announcing only one prefix: 410 LACNIC Region transit ASes present in the Internet Routing Table: 212 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 71505152 Equivalent to 4 /8s, 67 /16s and 21 /24s Percentage of available LACNIC address space announced: 71.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6608 Total AfriNIC prefixes after maximum aggregation: 1792 AfriNIC Deaggregation factor: 3.69 Prefixes being announced from the AfriNIC address blocks: 4946 Unique aggregates announced from the AfriNIC address blocks: 1432 AfriNIC Region origin ASes present in the Internet Routing Table: 349 AfriNIC Prefixes per ASN: 14.17 AfriNIC Region origin ASes announcing only one prefix: 97 AfriNIC Region transit ASes present in the Internet Routing Table: 77 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC addresses announced to Internet: 14953216 Equivalent to 0 /8s, 228 /16s and 43 /24s Percentage of available AfriNIC address space announced: 44.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1831 8533 469 Korea Telecom (KIX) 17488 1300 133 134 Hathway IP Over Cable Interne 4755 1284 287 136 TATA Communications formerly 18101 1052 221 41 Reliance Infocom Ltd Internet 4134 1018 19605 397 CHINANET-BACKBONE 9583 1000 75 500 Sify Limited 7545 964 199 99 TPG Internet Pty Ltd 17974 951 282 18 PT TELEKOMUNIKASI INDONESIA 24560 841 300 166 Bharti Airtel Ltd., Telemedia 9829 840 683 24 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4058 3842 311 bellsouth.net, inc. 4323 3788 1084 396 Time Warner Telecom 1785 1795 698 129 PaeTec Communications, Inc. 7018 1559 5756 1003 AT&T WorldNet Services 20115 1534 1494 666 Charter Communications 2386 1324 617 933 AT&T Data Communications Serv 3356 1222 10949 424 Level 3 Communications, LLC 11492 1151 222 14 Cable One 6478 1146 244 180 AT&T Worldnet Services 22773 1129 2604 70 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 587 40 5 United Telecom of Georgia 30890 451 101 205 Evolva Telecom 3292 450 1900 392 TDC Tele Danmark 702 421 1870 333 UUNET - Commercial IP service 8551 396 353 37 Bezeq International 8866 392 117 18 Bulgarian Telecommunication C 3320 363 7072 317 Deutsche Telekom AG 3301 355 1413 316 TeliaNet Sweden 3215 347 3206 103 France Telecom Transpac 12479 330 576 5 Uni2 Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1580 2893 236 UniNet S.A. de C.V. 10620 1011 227 154 TVCABLE BOGOTA 28573 909 715 86 NET Servicos de Comunicao S.A 7303 679 359 99 Telecom Argentina Stet-France 22047 533 310 15 VTR PUNTO NET S.A. 6503 498 167 193 AVANTEL, S.A. 7738 477 922 30 Telecomunicacoes da Bahia S.A 11830 474 308 56 Instituto Costarricense de El 18881 452 268 11 Global Village Telecom 3816 449 194 69 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 913 445 10 TEDATA 24863 709 144 41 LINKdotNET AS number 36992 573 131 167 Etisalat MISR 3741 274 853 233 The Internet Solution 33776 224 14 8 Starcomms Nigeria Limited 2018 211 215 121 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 171 19 9 Ci Telecom Autonomous system 24835 136 78 11 RAYA Telecom - Egypt 29975 133 506 14 Vodacom Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4058 3842 311 bellsouth.net, inc. 4323 3788 1084 396 Time Warner Telecom 4766 1831 8533 469 Korea Telecom (KIX) 1785 1795 698 129 PaeTec Communications, Inc. 8151 1580 2893 236 UniNet S.A. de C.V. 7018 1559 5756 1003 AT&T WorldNet Services 20115 1534 1494 666 Charter Communications 2386 1324 617 933 AT&T Data Communications Serv 17488 1300 133 134 Hathway IP Over Cable Interne 4755 1284 287 136 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3788 3392 Time Warner Telecom 1785 1795 1666 PaeTec Communications, Inc. 4766 1831 1362 Korea Telecom (KIX) 8151 1580 1344 UniNet S.A. de C.V. 17488 1300 1166 Hathway IP Over Cable Interne 4755 1284 1148 TATA Communications formerly 11492 1151 1137 Cable One 22773 1129 1059 Cox Communications, Inc. 18566 1059 1049 Covad Communications 18101 1052 1011 Reliance Infocom Ltd Internet Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.77.236.0/22 23456 32-bit ASN transition 41.190.64.0/22 28683 Office des Postes et telecomm 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.216.32.0/19 28683 Office des Postes et telecomm 41.220.144.0/20 36918 ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 36918 ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 36938 Amsco Telecommunications Nige Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:66 /12:188 /13:389 /14:666 /15:1232 /16:10973 /17:5173 /18:8739 /19:18132 /20:22044 /21:22254 /22:28672 /23:28359 /24:163874 /25:931 /26:1162 /27:589 /28:223 /29:14 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2626 4058 bellsouth.net, inc. 4323 2352 3788 Time Warner Telecom 4766 1450 1831 Korea Telecom (KIX) 1785 1258 1795 PaeTec Communications, Inc. 11492 1061 1151 Cable One 17488 1054 1300 Hathway IP Over Cable Interne 18566 1040 1059 Covad Communications 7018 943 1559 AT&T WorldNet Services 18101 918 1052 Reliance Infocom Ltd Internet 10620 917 1011 TVCABLE BOGOTA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:12 8:244 12:1981 13:10 15:22 16:3 17:8 20:39 24:1360 27:1 32:48 38:648 40:100 41:1977 44:3 46:1 47:26 52:6 55:2 56:2 57:23 58:644 59:637 60:401 61:1095 62:1073 63:1979 64:3831 65:2358 66:4152 67:1802 68:1047 69:2843 70:694 71:241 72:1871 73:2 74:2137 75:244 76:316 77:826 78:568 79:411 80:992 81:767 82:452 83:451 84:653 85:1020 86:385 87:679 88:422 89:1533 90:77 91:2708 92:435 93:1134 94:1387 95:542 96:229 97:305 98:503 99:27 109:417 110:284 111:455 112:239 113:246 114:369 115:597 116:1034 117:635 118:392 119:935 120:149 121:844 122:1381 123:852 124:1072 125:1287 128:208 129:205 130:139 131:486 132:219 133:17 134:195 135:45 136:227 137:170 138:241 139:93 140:475 141:137 142:379 143:349 144:396 145:48 146:413 147:168 148:581 149:216 150:151 151:168 152:257 153:167 154:2 155:279 156:181 157:324 158:97 159:357 160:307 161:178 162:270 163:165 164:311 165:493 166:507 167:392 168:788 169:163 170:699 171:46 172:1 173:550 174:540 175:61 178:5 180:359 182:29 183:230 184:16 186:312 187:218 188:1136 189:698 190:3562 192:5720 193:4537 194:3360 195:2796 196:1173 198:3550 199:3377 200:5286 201:1484 202:8021 203:8329 204:4077 205:2168 206:2513 207:3040 208:3919 209:3451 210:2516 211:1193 212:1695 213:1694 214:267 215:61 216:4482 217:1507 218:472 219:423 220:1071 221:380 222:308 End of report _______________________________________________ afnog mailing list http://afnog.org/mailman/listinfo/afnog From mark at streamservice.nl Sat Mar 13 07:52:15 2010 From: mark at streamservice.nl (Mark Scholten) Date: Sat, 13 Mar 2010 14:52:15 +0100 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <201003122153.o2CLrNgn015793@aurora.sol.net> References: from "Nathan" at Mar 12, 2010 01:46:11 PM <201003122153.o2CLrNgn015793@aurora.sol.net> Message-ID: <003d01cac2b4$63cfe030$2b6fa090$@nl> > -----Original Message----- > From: Joe Greco [mailto:jgreco at ns.sol.net] > Sent: Friday, March 12, 2010 10:53 PM > To: Nathan > Cc: nanog at nanog.org > Subject: Re: YouTube AS36561 began announcing 1.0.0.0/8 > > > There are sizable chunks that are fairly quiet (un-interesting > > numbers, luck of the draw, etc). Given that its mostly > > mis-configurations, laziness, ignorance, or poor planning... I > suspect > > the worst ranges will need to be sacrificed, and the remaining 80-90% > > of the space used for legitimate allocations. Unfortunately, anyone > > who accepts allocations in 1.x will need to be aware that they will > > have a slightly lower quality address-space. Accepting 1.1.1.0/24, > > for example, will land you with a continuous 50mbps of junk... > > seemingly forever... and a respectable chance that some percentage of > > the net will never reach you, due to their own misconfigurations. > > Practical solution: > > Move YouTube to 1.1.1.1, Google to 1.1.1.2, Yahoo! to 1.1.1.3, Facebook > to 1.1.1.4, etc. > It is probably the best way to get 1.x free if it is used by big websites. However I don't think that they will change it (to only use these IPs). I think they have an interest somewhere to not change it... > Maybe someone at YouTube was actually testing that strategy ;-) I have something else where I would be happy to accept 1.1.1.0/24 for some time, just to try to get them change settings. If someone want information about it, feel free to contact me off list. Regards, Mark From pstewart at nexicomgroup.net Sat Mar 13 09:47:28 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Sat, 13 Mar 2010 10:47:28 -0500 Subject: Network Naming Conventions Message-ID: Hi Folks... With many changes going on this year in our network, I figured it's a good time to revisit our naming conventions used in our networks. Today, we use the following example: Core1-rtr-to-ge1-1-1-vl20.nexicom.net Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc etc.... Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with. But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices etc? Finally, we have a fair amount of gear (that we own) at customer premises that act as either a managed device or a demarcation point .... how to you name those today? Open ended questions obviously - looking for many ideas. ;) Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From james at freedomnet.co.nz Sat Mar 13 10:06:42 2010 From: james at freedomnet.co.nz (James Jones) Date: Sat, 13 Mar 2010 11:06:42 -0500 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <4B9BB812.3090501@freedomnet.co.nz> On my last network I named all the routers after simpsons characters. On 3/13/10 10:47 AM, Paul Stewart wrote: > Hi Folks... > > > > With many changes going on this year in our network, I figured it's a > good time to revisit our naming conventions used in our networks. > > > > Today, we use the following example: > > > > Core1-rtr-to-ge1-1-1-vl20.nexicom.net > > > > Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc > etc.... > > > > Going forward, I'd like to examine a better method to identify the > devices.... does anyone have published standards on what they use or > that of other networks and maybe even why they chose those methods? The > core of the network is fairly easy for us to look at different changes > where you have interfaces, subinterfaces, locations etc. to deal with. > > > > But what do folks do for "aggregation devices" such as dial-up shelves, > BAS devices etc? > > > > Finally, we have a fair amount of gear (that we own) at customer > premises that act as either a managed device or a demarcation point .... > how to you name those today? > > > > Open ended questions obviously - looking for many ideas. > > > > ;) > > > > Paul > > > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > From mysidia at gmail.com Sat Mar 13 10:28:40 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 13 Mar 2010 10:28:40 -0600 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <003d01cac2b4$63cfe030$2b6fa090$@nl> References: <201003122153.o2CLrNgn015793@aurora.sol.net> <003d01cac2b4$63cfe030$2b6fa090$@nl> Message-ID: <6eb799ab1003130828p45c1c751sae499fc37d3987da@mail.gmail.com> On Sat, Mar 13, 2010 at 7:52 AM, Mark Scholten wrote: .. > It is probably the best way to get 1.x free if it is used by big websites. > However I don't think that they will change it (to only use these IPs). I > think they have an interest somewhere to not change it... If they added a basic javascript-based 1.0.0.0/8 HTTP connectivity test to www.youtube.com , and alerted users whose networks definitely had issues, there might be some interesting results, due to the site's popularity. Alert as in 20 seconds interstitial message before a video the user tried to play starts ... something like "Your network seems to have some connectivity problems to the Youtube.com IP address 1.2.3.4 and 1.2.3.5, your video will start in XX seconds. Please contact your network administrator." It would be a decent strategy. But yes, I guess there's no real reason for Youtube etc to do something like that, other than being charitable, or someone paying them to do it (as in advertising fee), plus a week's use of some 1.0.0.0/8 addresses is probably not a long enough time for that. Depending on how many (or few) issues there are with the /8, the RIR should want something like this. If end user networks have broken connectivity to the IP space, most of them might otherwise never notice, causing harm and pain to 1.0.0.0/8 web/e-mail address assignees setting up web and e-mail facilities with those addresses that their prospective contacts/visitors never notice, since user's attempt at initial contact simply failed, they never met to do business (e.g. They assumed it was an old site that closed down, broken link, etc)... -- -J From virendra.rode at gmail.com Sat Mar 13 10:21:16 2010 From: virendra.rode at gmail.com (virendra rode) Date: Sat, 13 Mar 2010 08:21:16 -0800 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <4B9BBB7C.8030800@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul, If my memory serves me correct, Richard presented traceroute presto at nanog47 that covered location identifiers. HTH, regards, /virendra Paul Stewart wrote: > Hi Folks... > > > > With many changes going on this year in our network, I figured it's a > good time to revisit our naming conventions used in our networks. > > > > Today, we use the following example: > > > > Core1-rtr-to-ge1-1-1-vl20.nexicom.net > > > > Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc > etc.... > > > > Going forward, I'd like to examine a better method to identify the > devices.... does anyone have published standards on what they use or > that of other networks and maybe even why they chose those methods? The > core of the network is fairly easy for us to look at different changes > where you have interfaces, subinterfaces, locations etc. to deal with. > > > > But what do folks do for "aggregation devices" such as dial-up shelves, > BAS devices etc? > > > > Finally, we have a fair amount of gear (that we own) at customer > premises that act as either a managed device or a demarcation point .... > how to you name those today? > > > > Open ended questions obviously - looking for many ideas. > > > > ;) > > > > Paul > > > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLm7t7pbZvCIJx1bcRAin3AJ4r69FiLr+qC6KpVn3pfPnuEWRQCgCeMeRU BbhE1ExSlGBTGU/rWk+3pj4= =TeNX -----END PGP SIGNATURE----- From jwbensley at gmail.com Sat Mar 13 11:26:30 2010 From: jwbensley at gmail.com (James Bensley) Date: Sat, 13 Mar 2010 17:26:30 +0000 Subject: Network Naming Conventions In-Reply-To: <4B9BBB7C.8030800@gmail.com> References: <4B9BBB7C.8030800@gmail.com> Message-ID: <3c857e1c1003130926p18606f89y935690619ed510e1@mail.gmail.com> On 13 March 2010 16:06, James Jones wrote: > On my last network I named all the routers after simpsons characters. We use ancient Greek gods. -- Regards, James ;) From tim2.sanderson at gmail.com Sat Mar 13 12:12:53 2010 From: tim2.sanderson at gmail.com (Tim Sanderson) Date: Sat, 13 Mar 2010 13:12:53 -0500 Subject: Network Naming Conventions In-Reply-To: <3c857e1c1003130926p18606f89y935690619ed510e1@mail.gmail.com> References: <4B9BBB7C.8030800@gmail.com> <3c857e1c1003130926p18606f89y935690619ed510e1@mail.gmail.com> Message-ID: <4b9bd5a7.5644f10a.2c73.ffffa41d@mx.google.com> ...Types of coffee and donuts Tim -----Original Message----- From: James Bensley [mailto:jwbensley at gmail.com] Sent: Saturday, March 13, 2010 12:27 PM To: NANOG list Subject: Re: Network Naming Conventions On 13 March 2010 16:06, James Jones wrote: > On my last network I named all the routers after simpsons characters. We use ancient Greek gods. -- Regards, James ;) From aaron at wholesaleinternet.net Sat Mar 13 12:24:43 2010 From: aaron at wholesaleinternet.net (aaron at wholesaleinternet.net) Date: Sat, 13 Mar 2010 18:24:43 +0000 Subject: Network Naming Conventions Message-ID: <67412742-1268504683-cardhu_decombobulator_blackberry.rim.net-129742905-@bda075.bisx.prod.on.blackberry> STD's ------Original Message------ From: Tim Sanderson To: NANOG list Subject: RE: Network Naming Conventions Sent: Mar 13, 2010 12:12 PM ...Types of coffee and donuts Tim -----Original Message----- From: James Bensley [mailto:jwbensley at gmail.com] Sent: Saturday, March 13, 2010 12:27 PM To: NANOG list Subject: Re: Network Naming Conventions On 13 March 2010 16:06, James Jones wrote: > On my last network I named all the routers after simpsons characters. We use ancient Greek gods. -- Regards, James ;) Sent from my Verizon Wireless BlackBerry From LarrySheldon at cox.net Sat Mar 13 12:26:08 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 13 Mar 2010 12:26:08 -0600 Subject: Network Naming Conventions In-Reply-To: <4B9BBB7C.8030800@gmail.com> References: <4B9BBB7C.8030800@gmail.com> Message-ID: <4B9BD8C0.80703@cox.net> For end-point hosts ("servers") I prefer terse topical names for single-function machines ("Finance", "Purchasing") and some predictable pattern that ties somehow to the organization for multipurpose machines ("Bluejay", "Parrot"). For network equipment at end points I prefer a string that starts with the machine's function, ends it an interface identifier, with location info in the middle. ("rtr-oma-hosp-3rd-peds", "rtr-oma-hosp-3rd-surg"). For network out in the middle I would do the same except expand the location data a bit and change the I/F infor to a hardware descriptive. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From erik_list at caneris.com Sat Mar 13 12:27:02 2010 From: erik_list at caneris.com (Erik L) Date: Sat, 13 Mar 2010 13:27:02 -0500 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: Hey Paul, > Core1-rtr-to-ge1-1-1-vl20.nexicom.net > > Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc > etc.... > That's disturbingly similar to ours :) tflns2-ge0-1-vl1.caneris.com TF = Toronto/Front LNS #2 = LNS #2 ge0-1 = interface vl1 = VLAN 1 > > Going forward, I'd like to examine a better method to identify the > devices.... does anyone have published standards on what they use or > that of other networks and maybe even why they chose those > methods? > One of my colleagues has written an overview and pros/cons of the most common naming conventions (purpose, geographic, purpose+geographic, and "themes") at http://www.watson-wilson.ca/blog/name-conv.html. He's a systems guy, so it's not written in the context of net ops, but some of the ideas are common. > But what do folks do for "aggregation devices" such as > dial-up shelves, > BAS devices etc? > See my example at the top. > > Finally, we have a fair amount of gear (that we own) at customer > premises that act as either a managed device or a demarcation > point .... > how to you name those today? > Currently similarly to this: MANAGED-DSL-1xxxx, where the 1xxxx is the account number. At the time it was decided to use this for no other reason than when a box/link goes down, it's trivial to find the customer/contacts in the OSS since the device name in the monitoring alert already has an account number embedded in it. Silly reason perhaps, but it's simple and it works. > > Open ended questions obviously - looking for many ideas. > There are many ways of doing it and many factors to consider, I'll just throw some food for thought: -Purpose / device type -Geography -Hierarchical naming -Scalability of the naming system -DNS -Humans - who's using the names and how? Reading/writing - how/frequency? What information do you want to convey (for obvious reason, this may vary greatly depending both on the target and the device)? -Systems - what else is using your names or may be using your names in future? OSS/provisioning/monitoring/graphs for interfaces - automated? Limitations on character set and length of name, e.g. DNS, stupid switches with absurdly short max lengths of port description fields, etc. A regexp can come in handy to define this (and perhaps your entire naming scheme) precisely. In a heterogeneous environment, you have all sorts of stuff where you may have two or more names to refer to the same thing. -Prefixes/suffixes -Mergers and acquisitions - what happens when you have to merge your network with someone else's? Though I can see the value of prefixing, I don't like naming conventions which prefix everything with an abbreviation of the company for two reasons: -Typing extra keystrokes repeatedly every day for no reason isn't fun -Sorting/lists don't work nicely, especially when you would otherwise use a key to go down to the first letter of a name -Traceroutes: I recall reading the slides from a NANOG presentation (unfortunately I don't recall the author's name and don't have a link now) which discussed naming devices in a traceroute-friendly way (friendly as in meaningful to those outside the org as well); you might want to find this. -Finally, look at how others do it - there are plenty of examples Erik ________________________________________ From: Paul Stewart [pstewart at nexicomgroup.net] Sent: Saturday, March 13, 2010 10:47 AM To: NANOG list Subject: Network Naming Conventions Hi Folks... With many changes going on this year in our network, I figured it's a good time to revisit our naming conventions used in our networks. Today, we use the following example: Core1-rtr-to-ge1-1-1-vl20.nexicom.net Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc etc.... Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with. But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices etc? Finally, we have a fair amount of gear (that we own) at customer premises that act as either a managed device or a demarcation point .... how to you name those today? Open ended questions obviously - looking for many ideas. ;) Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From wmaton at ryouko.imsb.nrc.ca Sat Mar 13 12:29:41 2010 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Sat, 13 Mar 2010 13:29:41 -0500 (EST) Subject: Network Naming Conventions In-Reply-To: <67412742-1268504683-cardhu_decombobulator_blackberry.rim.net-129742905-@bda075.bisx.prod.on.blackberry> References: <67412742-1268504683-cardhu_decombobulator_blackberry.rim.net-129742905-@bda075.bisx.prod.on.blackberry> Message-ID: Singers: tenchi% ping elvis elvis is alive tenchi% On Sat, 13 Mar 2010, aaron at wholesaleinternet.net wrote: > STD's > > > > ------Original Message------ > From: Tim Sanderson > To: NANOG list > Subject: RE: Network Naming Conventions > Sent: Mar 13, 2010 12:12 PM > > ...Types of coffee and donuts > > Tim > > -----Original Message----- > From: James Bensley [mailto:jwbensley at gmail.com] > Sent: Saturday, March 13, 2010 12:27 PM > To: NANOG list > Subject: Re: Network Naming Conventions > > On 13 March 2010 16:06, James Jones wrote: >> On my last network I named all the routers after simpsons characters. > > We use ancient Greek gods. > > -- > Regards, > James ;) > > > > > > Sent from my Verizon Wireless BlackBerry > wfms From dredd at megacity.org Sat Mar 13 12:41:16 2010 From: dredd at megacity.org (Derek J. Balling) Date: Sat, 13 Mar 2010 13:41:16 -0500 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <201003122145.o2CLjM9K015540@aurora.sol.net> References: <201003122145.o2CLjM9K015540@aurora.sol.net> Message-ID: <7E2EC743-90B5-4B2A-9197-51D19B96F313@megacity.org> On Mar 12, 2010, at 4:45 PM, Joe Greco wrote: > There's no way it's as widely used, and generally speaking, it appears > that those who have used it have done so out of ignorance and(/or?) > stupidity, sometimes blindly following documentation without > comprehending, etc. I don't know about that. Before we abandoned our prior managed-hosting facility for stuff we managed ourselves, ALL of the servers they were managing were using 1.0.0.0/8 for their "internal" address schemes. And this is a pretty decent sized company (Terremark) who I would have thought would have had a clue on it. That said, I agree "people who didn't listen to RFC1918 deserve every bit of pain that they've got coming to them", but I bet there's more morons out there than you're giving the universe credit for. D From bmanning at vacation.karoshi.com Sat Mar 13 12:49:59 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 13 Mar 2010 18:49:59 +0000 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <20100313184959.GF12034@vacation.karoshi.com.> islands rivers/creeks types of swords fruit minerals fermented things 3char strings punctuation marks twins ... --bill On Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote: > Hi Folks... > > > > With many changes going on this year in our network, I figured it's a > good time to revisit our naming conventions used in our networks. > > > > Today, we use the following example: > > > > Core1-rtr-to-ge1-1-1-vl20.nexicom.net > > > > Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc > etc.... > > > > Going forward, I'd like to examine a better method to identify the > devices.... does anyone have published standards on what they use or > that of other networks and maybe even why they chose those methods? The > core of the network is fairly easy for us to look at different changes > where you have interfaces, subinterfaces, locations etc. to deal with. > > > > But what do folks do for "aggregation devices" such as dial-up shelves, > BAS devices etc? > > > > Finally, we have a fair amount of gear (that we own) at customer > premises that act as either a managed device or a demarcation point .... > how to you name those today? > > > > Open ended questions obviously - looking for many ideas. > > > > ;) > > > > Paul > > > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From ck at sandcastl.es Sat Mar 13 12:53:46 2010 From: ck at sandcastl.es (ck) Date: Sat, 13 Mar 2010 10:53:46 -0800 Subject: Network Naming Conventions In-Reply-To: <4B9BBB7C.8030800@gmail.com> References: <4B9BBB7C.8030800@gmail.com> Message-ID: <8c308e8b1003131053j7096e79cgc80eaf370c1c8939@mail.gmail.com> i believe in keeping host names as short as possible, so to start, i wouldn't put the location in the hostname, but putting the loc/pop code in dns (eg: sjc1.nexicom, tor1.nexicom, iad1.nexicom, etc), same goes for rtr, you really dont need that, imo personally, i prefer the shortest possible name cr - core router csw - core switch br/tr/pr - border/transit/peer router and prepending the interface id eg: cr1.tor1.nexciom.net ge-1-1-1.cr1.tor1.nexicom.net of if your want to have full role name ge-1-1-1.core1.tor1.nexicom.net te-1-0-0.border1.tor1.nexciom.net -ck On Sat, Mar 13, 2010 at 8:21 AM, virendra rode wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul, > > If my memory serves me correct, Richard presented traceroute presto at > nanog47 that covered location identifiers. > > HTH, > > > regards, > /virendra > > > Paul Stewart wrote: > > Hi Folks... > > > > > > > > With many changes going on this year in our network, I figured it's a > > good time to revisit our naming conventions used in our networks. > > > > > > > > Today, we use the following example: > > > > > > > > Core1-rtr-to-ge1-1-1-vl20.nexicom.net > > > > > > > > Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc > > etc.... > > > > > > > > Going forward, I'd like to examine a better method to identify the > > devices.... does anyone have published standards on what they use or > > that of other networks and maybe even why they chose those methods? The > > core of the network is fairly easy for us to look at different changes > > where you have interfaces, subinterfaces, locations etc. to deal with. > > > > > > > > But what do folks do for "aggregation devices" such as dial-up shelves, > > BAS devices etc? > > > > > > > > Finally, we have a fair amount of gear (that we own) at customer > > premises that act as either a managed device or a demarcation point .... > > how to you name those today? > > > > > > > > Open ended questions obviously - looking for many ideas. > > > > > > > > ;) > > > > > > > > Paul > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------------- > > > > "The information transmitted is intended only for the person or entity to > which it is addressed and contains confidential and/or privileged material. > If you received this in error, please contact the sender immediately and > then destroy this transmission, including all attachments, without copying, > distributing or disclosing same. Thank you." > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFLm7t7pbZvCIJx1bcRAin3AJ4r69FiLr+qC6KpVn3pfPnuEWRQCgCeMeRU > BbhE1ExSlGBTGU/rWk+3pj4= > =TeNX > -----END PGP SIGNATURE----- > > From joelja at bogus.com Fri Mar 12 18:27:59 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 12 Mar 2010 16:27:59 -0800 Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <4B9AB023.2070903@web.de> References: <1268384007.1220.21.camel@petrie> <4B9AB023.2070903@web.de> Message-ID: <4B9ADC0F.6050202@bogus.com> On 03/12/2010 01:20 PM, Axel Morawietz wrote: > Am 12.03.2010 17:03, schrieb Nathan: >> [...] Its >> amazing how prolific 1.x traffic is. > > one reason might also be, that at least T-Mobile Germany uses 1.2.3.* > for their proxies that deliver the content to mobile phones. > And I'm not sure what they are doing when they are going to receive this > route from external. ;) The same that they're going to do for all the other unassigned /8s they're squatting on internally renumber, or blackhole them. every day I check my phone and as long as I'm in the bay area it's in 14/8. From ravi at cow.org Sat Mar 13 13:01:08 2010 From: ravi at cow.org (Ravi Pina) Date: Sat, 13 Mar 2010 14:01:08 -0500 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <20100313190107.GF69741@neu.cow.org> Heh. Host naming discussions is like religion and politics at parties. It only leads to someone going home crying, red wine spilled all over their new dress, and a black eye. Not in that order. -r On Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote: > Hi Folks... > > > > With many changes going on this year in our network, I figured it's a > good time to revisit our naming conventions used in our networks. > > > > Today, we use the following example: > > > > Core1-rtr-to-ge1-1-1-vl20.nexicom.net > > > > Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc > etc.... > > > > Going forward, I'd like to examine a better method to identify the > devices.... does anyone have published standards on what they use or > that of other networks and maybe even why they chose those methods? The > core of the network is fairly easy for us to look at different changes > where you have interfaces, subinterfaces, locations etc. to deal with. > > > > But what do folks do for "aggregation devices" such as dial-up shelves, > BAS devices etc? > > > > Finally, we have a fair amount of gear (that we own) at customer > premises that act as either a managed device or a demarcation point .... > how to you name those today? > > > > Open ended questions obviously - looking for many ideas. > > > > ;) > > > > Paul > > > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From streiner at cluebyfour.org Sat Mar 13 13:12:13 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 13 Mar 2010 14:12:13 -0500 (EST) Subject: Network Naming Conventions In-Reply-To: References: Message-ID: On Sat, 13 Mar 2010, Paul Stewart wrote: > With many changes going on this year in our network, I figured it's a > good time to revisit our naming conventions used in our networks. > > Today, we use the following example: > > Core1-rtr-to-ge1-1-1-vl20.nexicom.net > > Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc > etc.... > > Finally, we have a fair amount of gear (that we own) at customer > premises that act as either a managed device or a demarcation point .... > how to you name those today? You'll likely get lots of different answers to this, and there really isn't a right or wrong solution. It's up to you to determine what works best in your environment. In the last two places I've worked, where I had some level of control over the naming conventions, they ended up looking something like this for network devices (not all that different from yours): interface_name.device_name.location_id.domain example: te2-1.core01.pitbpa.yourisp.com If the interface has sub-interfaces like an 802.1q trunk with separate layer 3 interfaces, you could extend the interface name to reflect that, such as using te2-1-100 for TenGig2/1.100. Secondary networks could have something like "s02, s03, s04..." appended to the end of the interface name. The one deviation to this example is for the primary loopback address on the box, in which case I omit the interface name, so the example above becomes core01.pitbpa.yourisp.com. SNMP traps, auth requests, syslog messages, etc, are sourced from the primary loopback. The same format could be extended to RAS, broadband aggregators, etc pretty easily. It also has the benefit of being pretty hierarchical and consistent. This is helpful if you have network management systems or other back-office processes that need to be able to parse the name and pull out useful information. Keeping the format consistent makes the parsing logic less of a pain to write and update. One other thing you'll want to think about is if you want your interface names to follow $vendor's naming format rigidly, or if you want to use your own format that's relatively close. Specifically I'm thinking about the Cisco vs. Juniper way of doing things (TenGigabitEthernet2/1 vs xe-2/1). Most other vendors I've seen do something relatively Cisco-like. For customer premise routers, what I did in the past was something like: interface_name.customer_router_id.cust.domain example: fa0-0.widgets-inc-01.cust.yourisp.com If you don't want to reveal that the router is at or for "Widgets, Inc." you could always replace that with something like a customer ID number or something else that doesn't mean anyhting to the outside world, as long as you have a way through your back-office systems/NMS to associate that name with your customer "Widgets, Inc." That's my 2 cents. jms From jgreco at ns.sol.net Sat Mar 13 13:15:38 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 13 Mar 2010 13:15:38 -0600 (CST) Subject: YouTube AS36561 began announcing 1.0.0.0/8 In-Reply-To: <7E2EC743-90B5-4B2A-9197-51D19B96F313@megacity.org> from "Derek J. Balling" at Mar 13, 2010 01:41:16 PM Message-ID: <201003131915.o2DJFcoB017592@aurora.sol.net> > On Mar 12, 2010, at 4:45 PM, Joe Greco wrote: > > There's no way it's as widely used, and generally speaking, it appears > > that those who have used it have done so out of ignorance and(/or?) > > stupidity, sometimes blindly following documentation without > > comprehending, etc. > > I don't know about that. Before we abandoned our prior managed-hosting facility for stuff we managed ourselves, ALL of the servers they were managing were using 1.0.0.0/8 for their "internal" address schemes. And this is a pretty decent sized company (Terremark) who I would have thought would have had a clue on it. > > That said, I agree "people who didn't listen to RFC1918 deserve every bit of pain that they've got coming to them", but I bet there's more morons out there than you're giving the universe credit for. > Given the sheer number of 10-net deployments that are out there, I have a hard time envisioning that there are even two orders of magnitude less 1-net deployments. ... 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 Bryan at bryanfields.net Sat Mar 13 13:47:42 2010 From: Bryan at bryanfields.net (Bryan Fields) Date: Sat, 13 Mar 2010 14:47:42 -0500 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <4B9BEBDE.8000703@bryanfields.net> On 3/13/2010 10:47, Paul Stewart wrote: > Hi Folks... > > > > With many changes going on this year in our network, I figured it's a > good time to revisit our naming conventions used in our networks. I favor using CLLI code (well fake ones) TAMQFLTART1 is in the city of tampa (TAMQ) in FLorida at building TA, and RT1 is the first router there. This is nice as we know the location of the router, and building it's in from the host name. The host name is always 11 characters long, making it easy to filter/work with in logs. Now I alias the name in DNS so we can type "telnet tampa" and it will just be a CNAME pointing to TAMQFLTART1.keekles.org which is the loopback address. Interfaces are in DNS as well, and I make use of TXT records to store info on the hosts (mostly a contact number and a url to an internal wiki.) Below is an exerpt from a network policy I wrote about this: All network elements shall be named following CLLI code format. In most cases they will not be registered CLLI codes in CLONES. The format of a CLLI code is as follows CCCCSSTTEEE, i.e LTRKARHQR01 C ? city location S ? State postal code T ? Street or differentiator E ? Equipment Identifier In the event the equipment is being installed at a site with a registered CLLI site code (first 8 characters) this shall be used as the prefix. If not a company unique code will be used for the site CLLI. The equipment shall be identified using the following codes: RT[0-9] ? router number n, with n starting at 0. If more than 10 routers at a site, the code will change to RU[0-9], then RV[0-9], and so on. SW[0-9] ? Switch starting at 0 following the same progression as the router. P[00-99] ? Servers at a location M[00-99] ? Mux at a location R[00-99] ? Radios TS[00-99] ? terminal server (serial or other) VP[0-9] ? VPN router or security appliance FW[0-9] ? Firewall or packet filter I also tend to add funny names as CNAMES that are not published. Got to have some as the network designer after all ;-) -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From randy at psg.com Sat Mar 13 13:58:11 2010 From: randy at psg.com (Randy Bush) Date: Sun, 14 Mar 2010 04:58:11 +0900 Subject: Network Naming Conventions In-Reply-To: <4B9BB812.3090501@freedomnet.co.nz> References: <4B9BB812.3090501@freedomnet.co.nz> Message-ID: > On my last network I named all the routers after simpsons characters. scaled well? From erik_list at caneris.com Sat Mar 13 14:08:14 2010 From: erik_list at caneris.com (Erik L) Date: Sat, 13 Mar 2010 15:08:14 -0500 Subject: Network Naming Conventions In-Reply-To: References: <4B9BB812.3090501@freedomnet.co.nz>, Message-ID: > > On my last network I named all the routers after simpsons > characters. > > scaled well? > He wrote "last" instead of "current"...make your own conclusions ;) From r.engehausen at gmail.com Sat Mar 13 14:32:39 2010 From: r.engehausen at gmail.com (Roy) Date: Sat, 13 Mar 2010 12:32:39 -0800 Subject: Network Naming Conventions In-Reply-To: <4b9bd5a7.5644f10a.2c73.ffffa41d@mx.google.com> References: <4B9BBB7C.8030800@gmail.com> <3c857e1c1003130926p18606f89y935690619ed510e1@mail.gmail.com> <4b9bd5a7.5644f10a.2c73.ffffa41d@mx.google.com> Message-ID: <4B9BF667.80708@gmail.com> On 3/13/2010 10:12 AM, Tim Sanderson wrote: > ...Types of coffee and donuts > > Tim > > -----Original Message----- > From: James Bensley [mailto:jwbensley at gmail.com] > Sent: Saturday, March 13, 2010 12:27 PM > To: NANOG list > Subject: Re: Network Naming Conventions > > On 13 March 2010 16:06, James Jones wrote: > >> On my last network I named all the routers after simpsons characters. >> > We use ancient Greek gods. > > At various times: trees (redwood, spruce, ash) animals indigenous to the area (coyote, eagle, hawk, falcon) wines (pinot, chianiti) area keywords (shaky was a router in an earthquake prone area) colors (red, blue, green) places in star wars (dantooine) I found the wines and star wars stuff too hard to remember how to spell :-) From bzs at world.std.com Sat Mar 13 14:41:56 2010 From: bzs at world.std.com (Barry Shein) Date: Sat, 13 Mar 2010 15:41:56 -0500 Subject: Network Naming Conventions In-Reply-To: <67412742-1268504683-cardhu_decombobulator_blackberry.rim.net-129742905-@bda075.bisx.prod.on.blackberry> References: <67412742-1268504683-cardhu_decombobulator_blackberry.rim.net-129742905-@bda075.bisx.prod.on.blackberry> Message-ID: <19355.63636.823165.122378@world.std.com> On March 13, 2010 at 18:24 aaron at wholesaleinternet.net (aaron at wholesaleinternet.net) wrote: > STD's hmm, since we actually are STD.COM that could be a useful idea... -b From bzs at world.std.com Sat Mar 13 14:49:37 2010 From: bzs at world.std.com (Barry Shein) Date: Sat, 13 Mar 2010 15:49:37 -0500 Subject: Network Naming Conventions In-Reply-To: <8c308e8b1003131053j7096e79cgc80eaf370c1c8939@mail.gmail.com> References: <4B9BBB7C.8030800@gmail.com> <8c308e8b1003131053j7096e79cgc80eaf370c1c8939@mail.gmail.com> Message-ID: <19355.64097.165847.286469@world.std.com> On March 13, 2010 at 10:53 ck at sandcastl.es (ck) wrote: > i believe in keeping host names as short as possible, so to start, i At BU we brought down about 1/3 of the internet (no joke!) around 1985 when our very first host table entries to SRI-NIC contained single letter hosts (like a.bu.edu) and names starting with a digit (I remember 3b.bu.edu) which put the HOSTS table to /etc/hosts converter into an infinite loop filling up BSD root disks which back then would invariably hang/crash the OS (No space in /tmp No space in /tmp No space in /tmp No space in /tmp....) I think there's a write-up by me in an old RISKS digest from the time and it was quite a flap on the TCP-IP list ("BU Joins The Internet!") Completely inadvertent but it was probably as disruptive, relatively, as the Morris worm. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From pstewart at nexicomgroup.net Sat Mar 13 14:57:43 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Sat, 13 Mar 2010 15:57:43 -0500 Subject: Network Naming Conventions In-Reply-To: <19355.64097.165847.286469@world.std.com> References: <4B9BBB7C.8030800@gmail.com><8c308e8b1003131053j7096e79cgc80eaf370c1c8939@mail.gmail.com> <19355.64097.165847.286469@world.std.com> Message-ID: Just wanted to say thanks to everyone who responded - game me more to think about than I thought was possible ;) Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From pstewart at nexicomgroup.net Sat Mar 13 15:01:11 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Sat, 13 Mar 2010 16:01:11 -0500 Subject: Network Naming Conventions In-Reply-To: <20100313190107.GF69741@neu.cow.org> References: <20100313190107.GF69741@neu.cow.org> Message-ID: Yeah, just learning that... got a *tonne* of offline replies. Planets won't work well, simpson characters we'll run out very quickly.... umm.. forgot the rest. We were looking for something that makes sense to the function of the box itself and scales up (as per some other folks point).... Some of the suggestions around kinda what we have today but with some changes are what'll we'll debate internally. Take care, Paul -----Original Message----- From: Ravi Pina [mailto:ravi at cow.org] Sent: March-13-10 2:01 PM To: Paul Stewart Cc: NANOG list Subject: Re: Network Naming Conventions Heh. Host naming discussions is like religion and politics at parties. It only leads to someone going home crying, red wine spilled all over their new dress, and a black eye. Not in that order. -r On Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote: > Hi Folks... > > > > With many changes going on this year in our network, I figured it's a > good time to revisit our naming conventions used in our networks. > > > > Today, we use the following example: > > > > Core1-rtr-to-ge1-1-1-vl20.nexicom.net > > > > Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc > etc.... > > > > Going forward, I'd like to examine a better method to identify the > devices.... does anyone have published standards on what they use or > that of other networks and maybe even why they chose those methods? The > core of the network is fairly easy for us to look at different changes > where you have interfaces, subinterfaces, locations etc. to deal with. > > > > But what do folks do for "aggregation devices" such as dial-up shelves, > BAS devices etc? > > > > Finally, we have a fair amount of gear (that we own) at customer > premises that act as either a managed device or a demarcation point .... > how to you name those today? > > > > Open ended questions obviously - looking for many ideas. > > > > ;) > > > > Paul > > > > > > > > > ------------------------------------------------------------------------ ---- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From ravi at cow.org Sat Mar 13 15:33:01 2010 From: ravi at cow.org (Ravi Pina) Date: Sat, 13 Mar 2010 16:33:01 -0500 Subject: Network Naming Conventions In-Reply-To: References: <4B9BB812.3090501@freedomnet.co.nz> Message-ID: <20100313213301.GH69741@neu.cow.org> On Sun, Mar 14, 2010 at 04:58:11AM +0900, Randy Bush wrote: > > On my last network I named all the routers after simpsons characters. > > scaled well? Don't forget there were 5 Snowballs... From bicknell at ufp.org Sat Mar 13 19:40:52 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 13 Mar 2010 17:40:52 -0800 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <20100314014052.GA38842@ussenterprise.ufp.org> In a message written on Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote: > Open ended questions obviously - looking for many ideas. I think a key question to ask yourself is who needs to be able to interpret your names? Depending on your business, customers, engineers, etc you may have a good reason to use obscure names, for instance not making it easy for people to know the speed of interfaces, where your routers are located, how many routers you have, what brand routers you use, and so on. In other cases, you would like as much of that as possible to be something that someone can guess. For instance, many ISPs use city names or airport codes. This can help your customers decide if the latency numbers are reasonable or not. Lots of ISPs also include interface information, often so an engineer can log in and do a "show int xyz" based on a traceroute with no intermediate steps to look up which interface the IP is on and such. Lastly, "traceroute www..com" for a pile of web sites will give you all sorts of schemes in no time. There is no "right answer" in the generic, but there is a right answer for you. -- 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 adriankok2000 at yahoo.com.hk Sat Mar 13 20:01:29 2010 From: adriankok2000 at yahoo.com.hk (adrian kok) Date: Sat, 13 Mar 2010 18:01:29 -0800 (PST) Subject: security questions Message-ID: <415574.15182.qm@web33304.mail.mud.yahoo.com> Hi I have questions about security I am using mozila to access gmail as https://mail.google.com/mail Why mozilla prompts me the alert box? "You have requested an encrypted page that contains some unencrypted information. Information that you see or enter on this page could easily be read by a third party." 1/ Can network software help to check? if yes. which software and how? 2/ How mozilla knows I have data not encrypted? 3/ ls https secured? If not. why it is PCI? Thank you Send instant messages to your online friends http://uk.messenger.yahoo.com From larry-lists at maxqe.com Sat Mar 13 20:14:26 2010 From: larry-lists at maxqe.com (Larry Brower) Date: Sat, 13 Mar 2010 20:14:26 -0600 Subject: security questions In-Reply-To: <415574.15182.qm@web33304.mail.mud.yahoo.com> References: <415574.15182.qm@web33304.mail.mud.yahoo.com> Message-ID: <4B9C4682.1050500@maxqe.com> adrian kok wrote: > Hi > > I have questions about security > > I am using mozila to access gmail as https://mail.google.com/mail > > Why mozilla prompts me the alert box? > > "You have requested an encrypted page that contains some unencrypted information. Information that you see or enter on this page could easily be read by a third party." > > 1/ Can network software help to check? if yes. which software and how? > > 2/ How mozilla knows I have data not encrypted? > > 3/ ls https secured? If not. why it is PCI? > > Thank you > > Send instant messages to your online friends http://uk.messenger.yahoo.com > This message is saying that Google is including things using http:// in the site. This is common with Images. The login is still secure, just they just are not using SSL for some things. [ ~ ] >> lynx --dump mail.google.com/mail|grep http\:\/\/ http://gmail.com/app. [1]Learn more 1. http://www.google.com/mobile/landing/mail.html#utm_source=gmailhpp 2. http://mail.google.com/support/bin/answer.py?answer=46346&fpUrl=https%3A%2F%2Fwww.google.com%2Faccounts%2FForgotPasswd%3FfpOnly%3D1%26continue%3Dhttp%253A%252F%252Fmail.google.com%252Fmail%252F%253Fui%253Dhtml%2526zy%253Dl%26service%3Dmail%26ltmpl%3Ddefault&fuUrl=https%3A%2F%2Fwww.google.com%2Faccounts%2FForgotPasswd%3FfuOnly%3D1%26continue%3Dhttp%253A%252F%252Fmail.google.com%252Fmail%252F%253Fui%253Dhtml%2526zy%253Dl%26service%3Dmail%26ltmpl%3Ddefault&hl=en 3. http://mail.google.com/mail/signup 4. http://mail.google.com/mail/help/intl/en/about.html 5. http://mail.google.com/mail/help/intl/en/about_whatsnew.html 6. http://www.google.com/apps/intl/en/business/gmail.html#utm_medium=et&utm_source=gmail-signin-en&utm_campaign=crossnav 7. http://gmailblog.blogspot.com/?utm_source=en-gmftr&utm_medium=et&utm_content=gmftr 8. http://mail.google.com/mail/help/intl/en/terms.html 9. http://mail.google.com/support/ From brandon.kim at brandontek.com Sat Mar 13 20:08:56 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sat, 13 Mar 2010 22:08:56 -0400 Subject: security questions In-Reply-To: <4B9C4682.1050500@maxqe.com> References: <415574.15182.qm@web33304.mail.mud.yahoo.com>, <4B9C4682.1050500@maxqe.com> Message-ID: Yup, what Larry said.....I wouldn't be too concerned about it. But some managers may make a big deal... Some sites use images located at a different webserver that isn't HTTPS, and sometimes there are hidden iframes that bring you info from non-secure sites. But the actual login is posted to an HTTPS server. Hope that helps. Brandon Follow me: twitter.com/brandontek > Date: Sat, 13 Mar 2010 20:14:26 -0600 > From: larry-lists at maxqe.com > To: adriankok2000 at yahoo.com.hk > Subject: Re: security questions > CC: nanog at nanog.org > > adrian kok wrote: > > Hi > > > > I have questions about security > > > > I am using mozila to access gmail as https://mail.google.com/mail > > > > Why mozilla prompts me the alert box? > > > > "You have requested an encrypted page that contains some unencrypted information. Information that you see or enter on this page could easily be read by a third party." > > > > 1/ Can network software help to check? if yes. which software and how? > > > > 2/ How mozilla knows I have data not encrypted? > > > > 3/ ls https secured? If not. why it is PCI? > > > > Thank you > > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > > > > > This message is saying that Google is including things using http:// > in the site. This is common with Images. The login is still secure, > just they just are not using SSL for some things. > > > > [ ~ ] >> lynx --dump mail.google.com/mail|grep http\:\/\/ > http://gmail.com/app. [1]Learn more > 1. http://www.google.com/mobile/landing/mail.html#utm_source=gmailhpp > 2. > http://mail.google.com/support/bin/answer.py?answer=46346&fpUrl=https%3A%2F%2Fwww.google.com%2Faccounts%2FForgotPasswd%3FfpOnly%3D1%26continue%3Dhttp%253A%252F%252Fmail.google.com%252Fmail%252F%253Fui%253Dhtml%2526zy%253Dl%26service%3Dmail%26ltmpl%3Ddefault&fuUrl=https%3A%2F%2Fwww.google.com%2Faccounts%2FForgotPasswd%3FfuOnly%3D1%26continue%3Dhttp%253A%252F%252Fmail.google.com%252Fmail%252F%253Fui%253Dhtml%2526zy%253Dl%26service%3Dmail%26ltmpl%3Ddefault&hl=en > 3. http://mail.google.com/mail/signup > 4. http://mail.google.com/mail/help/intl/en/about.html > 5. http://mail.google.com/mail/help/intl/en/about_whatsnew.html > 6. > http://www.google.com/apps/intl/en/business/gmail.html#utm_medium=et&utm_source=gmail-signin-en&utm_campaign=crossnav > 7. > http://gmailblog.blogspot.com/?utm_source=en-gmftr&utm_medium=et&utm_content=gmftr > 8. http://mail.google.com/mail/help/intl/en/terms.html > 9. http://mail.google.com/support/ > From nanog at shreddedmail.com Sat Mar 13 23:49:18 2010 From: nanog at shreddedmail.com (Rick Ernst) Date: Sat, 13 Mar 2010 21:49:18 -0800 Subject: IPv6, multihoming, and customer allocations Message-ID: A couple of different incantations searching the archive didn't enlighten me, and I find it hard to believe this hasn't been discussed. Apologies and a request for pointers if I'm rehashing an old question. As a small/regional ISP, we got our /32 assigned and it's time to start moving forward (customers are asking for it). New hardware, updated IOS, etc. are in the pipe. Discussions are beginning with our upstream providers for peering. Now, what do we do? A /48 seems to be the standard end-user/multi-homed customer allocation and is the minimum allocation size from ARIN. A /32 provides 65K /48s so, in theory, we could give each of our customers a /48 and still have room for growth. A /48 also appears to be generally accepted as the the longest prefix allowed through filters (although /49 through /54 are also discussed). Most customers, however, won't be multi-homed. Partly from an IPv4 scarcity perspective, and partly from general efficiency and thrift, it seems awfully silly to hand out /48s to somebody that may have a handful of servers or a couple of home machines, especially with special addressing like link-local if the hosts are not expected to be internet reachable (back-end servervs, etc). Based on the above, I'm looking to establish some initial policies to save grief in the future: - /52 allocations to end-users (residential, soho, etc.) - /48 allocations to those that request it - If you are going to multi-home, get your own space This is obviously a very broad brush and takes an insanely large addressing model and makes it even larger (assigning /52s instead of /48s) but, to me at least, it seems reasonable for a first-pass. For context/scope, we currently have the equivalent of a bit more than the equivalent of a /16 (IPv4) in use. Thanks, From tony at lava.net Sun Mar 14 00:06:56 2010 From: tony at lava.net (Antonio Querubin) Date: Sat, 13 Mar 2010 20:06:56 -1000 (HST) Subject: IPv6, multihoming, and customer allocations In-Reply-To: References: Message-ID: On Sat, 13 Mar 2010, Rick Ernst wrote: > A /48 seems to be the standard end-user/multi-homed customer allocation and > is the minimum allocation size from ARIN. A /32 provides 65K /48s so, in > theory, we could give each of our customers a /48 and still have room for > growth. A /48 also appears to be generally accepted as the the longest > prefix allowed through filters (although /49 through /54 are also > discussed). Most customers, however, won't be multi-homed. https://www.arin.net/policy/nrpm.html#six541 Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From owen at delong.com Sun Mar 14 01:49:58 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 13 Mar 2010 23:49:58 -0800 Subject: IPv6, multihoming, and customer allocations In-Reply-To: References: Message-ID: <36DA228F-9617-41FB-86C4-D057EE133211@delong.com> On Mar 13, 2010, at 9:49 PM, Rick Ernst wrote: > A couple of different incantations searching the archive didn't > enlighten > me, and I find it hard to believe this hasn't been discussed. > Apologies and > a request for pointers if I'm rehashing an old question. > Don't have the pointers handy, but, it has been discussed as well as the meta-discussion of the general lack of BCP and documentation available. One good source for some information is http://www.getipv6.info > As a small/regional ISP, we got our /32 assigned and it's time to > start > moving forward (customers are asking for it). New hardware, updated > IOS, > etc. are in the pipe. Discussions are beginning with our upstream > providers > for peering. Now, what do we do? > Glad to hear customers are asking for it. That's a good sign. I think the next step is to start planning your address utilization. Some ISPs are giving all customers a /48. Some are giving small (residential, SOHO, and small business) a /56 by default and a /48 on request. A /48 is given to each site of medium-to-large businesses, more with proper justification. > A /48 seems to be the standard end-user/multi-homed customer > allocation and > is the minimum allocation size from ARIN. A /32 provides 65K /48s > so, in > theory, we could give each of our customers a /48 and still have > room for > growth. A /48 also appears to be generally accepted as the the > longest > prefix allowed through filters (although /49 through /54 are also > discussed). Most customers, however, won't be multi-homed. > Generally, that's pretty accurate. Over time, I suspect the proportion of multihomed customers will increase. > Partly from an IPv4 scarcity perspective, and partly from general > efficiency > and thrift, it seems awfully silly to hand out /48s to somebody that > may > have a handful of servers or a couple of home machines, especially > with > special addressing like link-local if the hosts are not expected to be > internet reachable (back-end servervs, etc). > It isn't. Repeat after me... IPv6 addressing is vast and was designed to allow sparse allocations. It is not necessary to conserve every singe address. > Based on the above, I'm looking to establish some initial policies > to save > grief in the future: > - /52 allocations to end-users (residential, soho, etc.) /52 works, too, although most people who are doing less than /48 are going to /56, with /48 as the fallback if /56 is not enough. > - /48 allocations to those that request it Good plan. > - If you are going to multi-home, get your own space > Not necessarily. There are still many multihoming scenarios that do not meet the ARIN criteria for provider-independent address assignment. As much as I would like to change the ARIN criteria, for now, the community seems to feel that there is concern about overflowing the capabilities of backbone routers if we did this. > This is obviously a very broad brush and takes an insanely large > addressing > model and makes it even larger (assigning /52s instead of /48s) but, > to me > at least, it seems reasonable for a first-pass. > ARIN will accept you assigning anything up to a /48 to any end user. Anything over a /48 requires a justification. > For context/scope, we currently have the equivalent of a bit more > than the > equivalent of a /16 (IPv4) in use. > Then your /32 may very likely be enough for you for IPv6. Something to consider, if you have multiple POPs or locations, you may want to enable aggregation of those locations on nibble boundaries. Doing so means that you could do 16 POPs with a /36 each, or, 256 POPs with a /40 each. Each of the 16 /36 POPs would support roughly 4,000 customers. If you go to /40s, then, you only get 200 customers per POP. Hope this helps, Owen From bit.gossip at chello.nl Sun Mar 14 01:39:11 2010 From: bit.gossip at chello.nl (Bit Gossip) Date: Sun, 14 Mar 2010 08:39:11 +0100 Subject: 4bytes ASn and RFC1745 Message-ID: <1268552351.4687.6.camel@localhost> experts, what are the consequences of 4bytes ASn (RFC4893) for RFC1745 - BGP4/IDRP for IP---OSPF Interaction? In particular with regards to storing the AutonomousSystem in the lowest 16 bits of the External Route Tag (=32 bits)? Thanks, bit From nanog at daork.net Sun Mar 14 05:04:43 2010 From: nanog at daork.net (Nathan Ward) Date: Sun, 14 Mar 2010 23:04:43 +1300 Subject: 4bytes ASn and RFC1745 In-Reply-To: <1268552351.4687.6.camel@localhost> References: <1268552351.4687.6.camel@localhost> Message-ID: <5B6CB526-74F8-4742-B882-B0B5E273B4DC@daork.net> On 14/03/2010, at 8:39 PM, Bit Gossip wrote: > experts, > what are the consequences of 4bytes ASn (RFC4893) for RFC1745 - > BGP4/IDRP for IP---OSPF Interaction? > > In particular with regards to storing the AutonomousSystem in the lowest > 16 bits of the External Route Tag (=32 bits)? > Thanks, > bit Little practical consequences I expect. This is taken from RFC3167, section 1, in 2001: During a review of internet standards relating to BGP, it became apparent that BGP/IDRP OSPF interaction, as described in RFC 1745, has never been deployed in the public internet, and would require significant implementation complexity. Since this mechanism has never been in use in the public internet, it is proposed to reclassify it to Historic. -- Nathan Ward From jeff-kell at utc.edu Sun Mar 14 13:16:53 2010 From: jeff-kell at utc.edu (Jeff Kell) Date: Sun, 14 Mar 2010 14:16:53 -0400 Subject: Inside plant 10G fiber specs? Message-ID: <4B9D2815.6070000@utc.edu> I am working up network specs for a new building, and trying to accomodate a 10G distribution from the start. The safe bet of running singlemode everywhere doesn't quite fit due to cost of the optics and the need for multimode for some other (non-network) devices anyway. We have a legacy 62.5u/MM campus, inside and out. The 100M to 1G transition led to some outside plant singlemode additions due to length restrictions on MM (even with conditioned LH optics), but the inside plant gig was fine with multimode (typically SH optics). 10G appears to break the inside 62.5u/MM fit, with the addition that there is no option of "LH over MM" for the little extra push beyond the SH limit that worked with 1G optics. Cisco's references give 10G SH over 62.5u/MM at 26m or 33m, depending on the "modal bandwidth" of the fiber. At those distances it is of little benefit except some limited vertical risers. 10G over 50u/MM looks better, depending on the "modal bandwidth" of the fiber (66m, 82m, 300m). So, a couple of questions... (1) Do you have a good vendor specification (or sample cables) for multistrand 50u/MM suitable for the 2000Mhz/km (300m) advertised reach? (2) Inter-operability issues with legacy equipment where we have always used 62.5? We have at least two alarm half-duplex loops over 62.5 that will have to "mate" with devices in this building... if I can avoid running both types MM that would be great. (3) Any other considerations or words of advice would be welcomed. Thanks in advance. Jeff From cra at WPI.EDU Sun Mar 14 14:17:43 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 14 Mar 2010 15:17:43 -0400 Subject: Inside plant 10G fiber specs? In-Reply-To: <4B9D2815.6070000@utc.edu> References: <4B9D2815.6070000@utc.edu> Message-ID: <20100314191743.GA28316@angus.ind.WPI.EDU> On Sun, Mar 14, 2010 at 02:16:53PM -0400, Jeff Kell wrote: > I am working up network specs for a new building, and trying to > accomodate a 10G distribution from the start. The safe bet of running > singlemode everywhere doesn't quite fit due to cost of the optics and > the need for multimode for some other (non-network) devices anyway. Pull a hybrid MM/SM cable. For the life expectancy of most fiber installs, you'll want the SM to run 10G now, and 40G, 100G, ?? in the future over the same infrastructure. SM optics aren't really that much more expensive anymore. From sethm at rollernet.us Sun Mar 14 14:22:16 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 14 Mar 2010 12:22:16 -0700 Subject: Inside plant 10G fiber specs? In-Reply-To: <4B9D2815.6070000@utc.edu> References: <4B9D2815.6070000@utc.edu> Message-ID: <4B9D3768.8070605@rollernet.us> On 3/14/10 11:16 AM, Jeff Kell wrote: > 10G over 50u/MM looks better, depending on the "modal bandwidth" of the > fiber (66m, 82m, 300m). Yep, that last one would be the "laser optimized" variant. You won't be excluding 1G optics by using laser optimized fiber, but you need it to get the same reach on 10G. ~Seth From drew.weaver at thenap.com Sun Mar 14 14:58:53 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Sun, 14 Mar 2010 15:58:53 -0400 Subject: Avaya CNA/RouteScience masters Message-ID: Howdy, this might be slightly off-topic here, but. I know they likely only sold 50 or so of these units but I was wondering if anyone still uses them that has any technical prowess with these units. I've run into a recurring technical snag and obviously since they are EOS (and Avaya seems to have cleared the support staff) I can't really get 'official support' for it. So if anyone who has touched one of these recently or still uses them can hit me off-list I would be grateful, I am also looking to purchase used CNA 336s for spares if anyone has any that are currently being used as a coffee table. Have a nice weekend. -Drew From nanog at veggiechinese.net Sun Mar 14 17:34:03 2010 From: nanog at veggiechinese.net (William Yardley) Date: Sun, 14 Mar 2010 15:34:03 -0700 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <20100314223403.GK18483@mitch.veggiechinese.net> On Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote: > Going forward, I'd like to examine a better method to identify the > devices.... does anyone have published standards on what they use or > that of other networks and maybe even why they chose those methods? Looked through the thread figuring someone else would have mentioned this one, but (unless I missed it), they didn't. So sorry if you've seen this already, but I think this presentation is a really good take on the subject. http://www.nanog.org/meetings/nanog31/abstracts.php?pt=NjExJm5hbm9nMzE=&nm=nanog31 From rubensk at gmail.com Sun Mar 14 18:43:17 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 14 Mar 2010 20:43:17 -0300 Subject: Network Naming Conventions In-Reply-To: References: <20100313190107.GF69741@neu.cow.org> Message-ID: <6bb5f5b11003141643h8d00e33hb051fa05592c4694@mail.gmail.com> On Sat, Mar 13, 2010 at 6:01 PM, Paul Stewart wrote: > Yeah, just learning that... got a *tonne* of offline replies. > > Planets won't work well, simpson characters we'll run out very > quickly.... umm.. forgot the rest. ?We were looking for something that > makes sense to the function of the box itself and scales up (as per some > other folks point).... With 726 episodes in 30 TV seasons and 11 feature films, it's very difficult to run out of Star Trek characters. Not main characters, though. Rubens From TWright at internode.com.au Sun Mar 14 18:47:46 2010 From: TWright at internode.com.au (Tom Wright) Date: Mon, 15 Mar 2010 10:17:46 +1030 Subject: Network Naming Conventions In-Reply-To: <8c308e8b1003131053j7096e79cgc80eaf370c1c8939@mail.gmail.com> References: <4B9BBB7C.8030800@gmail.com> <8c308e8b1003131053j7096e79cgc80eaf370c1c8939@mail.gmail.com> Message-ID: I agree - this convention is easy to type/understand/automate. Makes it easy to AXFR and see which devices are in a pop. We throw a bit of Perl at our device configs to create RR's for each device (imagine doing it manually... blergh). KISS :) -- Tom On 14/03/2010, at 5:23 AM, ck wrote: i believe in keeping host names as short as possible, so to start, i wouldn't put the location in the hostname, but putting the loc/pop code in dns (eg: sjc1.nexicom, tor1.nexicom, iad1.nexicom, etc), same goes for rtr, you really dont need that, imo personally, i prefer the shortest possible name cr - core router csw - core switch br/tr/pr - border/transit/peer router and prepending the interface id eg: cr1.tor1.nexciom.net ge-1-1-1.cr1.tor1.nexicom.net of if your want to have full role name ge-1-1-1.core1.tor1.nexicom.net te-1-0-0.border1.tor1.nexciom.net -ck On Sat, Mar 13, 2010 at 8:21 AM, virendra rode wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul, If my memory serves me correct, Richard presented traceroute presto at nanog47 that covered location identifiers. HTH, regards, /virendra Paul Stewart wrote: Hi Folks... With many changes going on this year in our network, I figured it's a good time to revisit our naming conventions used in our networks. Today, we use the following example: Core1-rtr-to-ge1-1-1-vl20.nexicom.net Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc etc.... Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with. But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices etc? Finally, we have a fair amount of gear (that we own) at customer premises that act as either a managed device or a demarcation point .... how to you name those today? Open ended questions obviously - looking for many ideas. ;) Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLm7t7pbZvCIJx1bcRAin3AJ4r69FiLr+qC6KpVn3pfPnuEWRQCgCeMeRU BbhE1ExSlGBTGU/rWk+3pj4= =TeNX -----END PGP SIGNATURE----- -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net From frank at fttx.org Sun Mar 14 20:05:51 2010 From: frank at fttx.org (Frank A. Coluccio) Date: Sun, 14 Mar 2010 18:05:51 -0700 Subject: Inside plant 10G fiber specs? Message-ID: <20100314180551.5423F2D4@resin18.mta.everyone.net> The massive deployments of FTTH around the globe (now tens of millions of end points per quarter) have been responsible for driving price points for singlemode optics down considerably, and it's only going to get a lot cheaper over time before bottoming out. Plan to the trajectory, not the history. OM3 & OM4 MMF will provide considerably greater reach than their forebears, but if you're looking to centralize servers and avoid myriad intermediate TRs and LAN rooms due to distance constrains along the way (cascading bottlenecks), then give singlemode a closer look. You may also want to give IEEE 10GE PON (ratified last year) some consideration, or the ITU emerging variant of 10GPON for your desktop and lab areas, fwiw. BR, Frank --- jeff-kell at utc.edu wrote: From: Jeff Kell To: nanog at nanog.org Subject: Inside plant 10G fiber specs? Date: Sun, 14 Mar 2010 14:16:53 -0400 I am working up network specs for a new building, and trying to accomodate a 10G distribution from the start. The safe bet of running singlemode everywhere doesn't quite fit due to cost of the optics and the need for multimode for some other (non-network) devices anyway. We have a legacy 62.5u/MM campus, inside and out. The 100M to 1G transition led to some outside plant singlemode additions due to length restrictions on MM (even with conditioned LH optics), but the inside plant gig was fine with multimode (typically SH optics). 10G appears to break the inside 62.5u/MM fit, with the addition that there is no option of "LH over MM" for the little extra push beyond the SH limit that worked with 1G optics. Cisco's references give 10G SH over 62.5u/MM at 26m or 33m, depending on the "modal bandwidth" of the fiber. At those distances it is of little benefit except some limited vertical risers. 10G over 50u/MM looks better, depending on the "modal bandwidth" of the fiber (66m, 82m, 300m). So, a couple of questions... (1) Do you have a good vendor specification (or sample cables) for multistrand 50u/MM suitable for the 2000Mhz/km (300m) advertised reach? (2) Inter-operability issues with legacy equipment where we have always used 62.5? We have at least two alarm half-duplex loops over 62.5 that will have to "mate" with devices in this building... if I can avoid running both types MM that would be great. (3) Any other considerations or words of advice would be welcomed. Thanks in advance. Jeff From jgreco at ns.sol.net Sun Mar 14 22:11:20 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 14 Mar 2010 21:11:20 -0600 (CST) Subject: Network Naming Conventions In-Reply-To: <6bb5f5b11003141643h8d00e33hb051fa05592c4694@mail.gmail.com> from "Rubens Kuhl" at Mar 14, 2010 08:43:17 PM Message-ID: <201003150311.o2F3BKtL017964@aurora.sol.net> > On Sat, Mar 13, 2010 at 6:01 PM, Paul Stewart wrote: > > Yeah, just learning that... got a *tonne* of offline replies. > > > > Planets won't work well, simpson characters we'll run out very > > quickly.... umm.. forgot the rest. ?We were looking for something that > > makes sense to the function of the box itself and scales up (as per some > > other folks point).... > > With 726 episodes in 30 TV seasons and 11 feature films, it's very > difficult to run out of Star Trek characters. Not main characters, > though. Not to mention all the books, etc. Really, it's not hard to find precompiled lists of this sort of stuff. One could start at someplace like http://starwars.wikia.com/wiki/Coruscant for Star WARS (not Trek) stuff and probably scale up to a very large size with all the names, places, planets, etc. In the old days (pre-Web), it was actually a lot harder to come up with a comprehensive naming scheme. ... 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 gfortaine at live.com Sun Mar 14 22:30:08 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Mon, 15 Mar 2010 04:30:08 +0100 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: Message-ID: Misters, No comments ? http://docs.google.com/viewer?url=http://www.loud-fat-bloke.co.uk/obeseus2.pdf http://docs.google.com/viewer?url=http://www.parliament.uk/documents/upload/F012Interoute121109.pdf http://barometer.interoute.com/barom_main.php I look forward to your answer, Best Regards, Guillaume FORTAINE On 03/13/2010 12:05 AM, Guillaume FORTAINE wrote: > Misters, > > Let me introduce myself : Guillaume FORTAINE, Engineer in Computer > Science. I am currently working on High-Speed Network Security > Solutions. > > DDoS is considered as "The Mother of All Cyber Threats" [1] therefore > I have intensively studied this topic. > > By the way, I have read with interest the NANOG mails [2] [3] [4] and > the Linkedin groups [5] [6] on this subject. > > Being an FPGA engineer, I approached this concern from an algorithmic > point of view and that's why I would greatly appreciate to have your > comments on this project, if possible, please : > > "OBESEUS - A new type of DDOS protector" [7] > > http://www.loud-fat-bloke.co.uk/obeseus2.pdf > > > For a better overview of the background of the project, please see the > following document : > > "INQUIRY INTO EU POLICY ON PROTECTING EUROPE FROM LARGE SCALE > CYBER-ATTACKS" > > http://www.parliament.uk/documents/upload/F012Interoute121109.pdf > > I look forward to your answer, > > Best Regards, > > [1] > http://events.linkedin.com/Webcast-DDoS-Mother-All-Cyber-Threats/pub/171074 > > [2] http://mailman.nanog.org/pipermail/nanog/2009-November/014963.html > [3] http://mailman.nanog.org/pipermail/nanog/2010-January/016675.html > [4] http://mailman.nanog.org/pipermail/nanog/2010-January/017604.html > [5] http://www.linkedin.com/groups?home=&gid=2040519 > [6] http://www.linkedin.com/groups?home=&gid=2632190 > [7] http://www.loud-fat-bloke.co.uk/obeseus.html > > > Guillaume FORTAINE > Tel : +33(0)631092519 > > > From Valdis.Kletnieks at vt.edu Mon Mar 15 00:24:50 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 15 Mar 2010 01:24:50 -0400 Subject: security questions In-Reply-To: Your message of "Sat, 13 Mar 2010 22:08:56 -0400." References: <415574.15182.qm@web33304.mail.mud.yahoo.com> <4B9C4682.1050500@maxqe.com> Message-ID: <5195.1268630690@localhost> On Sat, 13 Mar 2010 22:08:56 -0400, Brandon Kim said: > Some sites use images located at a different webserver that isn't HTTPS, > and sometimes there are hidden iframes that bring you info from non-secure > sites. But the actual login is posted to an HTTPS server. Well... that's almost, but not quite, correct. The warning is because you may see a padlock displayed because the *outside* frames are https:// but there are iframes/CSS/images/whatever that have been fetched via other means - which creates 2 risks: 1) Those elements fetched via http:// traveled in the clear, and were thus visible to a sniffer. And yes, there's web designers stupid enough to do captcha graphics and bank records and similar via http://, causing an information leakage problem going from the site towards the user 2) Given the joys of javascript, etc, there are a number of security issues with mixed-mode pages. A discussion of some of them is here: http://code.google.com/p/support/issues/detail?id=3400 Note particularly the injection problem - if you're at a wifi hotspot or similar, somebody can replace the non-secure parts and suddenly control the horzontal and vertical on your page, while you still think it's secure. (Yes they can screw with totally non-secure pages too, but a lot of people implicitly trust https: more than http:) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From charles at knownelement.com Mon Mar 15 01:00:15 2010 From: charles at knownelement.com (Charles N Wyble) Date: Sun, 14 Mar 2010 23:00:15 -0700 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: Message-ID: <4B9DCCEF.8000203@knownelement.com> Guillaume FORTAINE wrote: > Misters, > > No comments ? > > http://docs.google.com/viewer?url=http://www.loud-fat-bloke.co.uk/obeseus2.pdf > > > http://docs.google.com/viewer?url=http://www.parliament.uk/documents/upload/F012Interoute121109.pdf > > > http://barometer.interoute.com/barom_main.php The paper is pretty high level, and the software doesn't appear to be available for download. So it's kinda theoretical. From gfortaine at live.com Mon Mar 15 01:56:33 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Mon, 15 Mar 2010 07:56:33 +0100 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: <4B9DCCEF.8000203@knownelement.com> References: <4B9DCCEF.8000203@knownelement.com> Message-ID: Dear Mister Wyble, Thank you for your reply. On 03/15/2010 07:00 AM, Charles N Wyble wrote: > The paper is pretty high level, and the software doesn't appear to be > available for download. http://www.loud-fat-bloke.co.uk/obeseus.html http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz > So it's kinda theoretical. > > "We have it running parallel with a commercial product and it detects the following attacks ? SYN floods ? RST floods ? ICMP floods ? General UDP floods ? General TCP floods" Best Regards, Guillaume FORTAINE From pstewart at nexicomgroup.net Mon Mar 15 07:59:00 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 15 Mar 2010 08:59:00 -0400 Subject: Network Naming Conventions In-Reply-To: <201003150311.o2F3BKtL017964@aurora.sol.net> References: <6bb5f5b11003141643h8d00e33hb051fa05592c4694@mail.gmail.com> from "Rubens Kuhl" at Mar 14, 2010 08:43:17 PM <201003150311.o2F3BKtL017964@aurora.sol.net> Message-ID: I have yet to see a core router named "Luke" or "Bart"... ;) -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: March-14-10 11:11 PM To: Rubens Kuhl Cc: Paul Stewart; NANOG list Subject: Re: Network Naming Conventions > On Sat, Mar 13, 2010 at 6:01 PM, Paul Stewart wrote: > > Yeah, just learning that... got a *tonne* of offline replies. > > > > Planets won't work well, simpson characters we'll run out very > > quickly.... umm.. forgot the rest. ?We were looking for something that > > makes sense to the function of the box itself and scales up (as per some > > other folks point).... > > With 726 episodes in 30 TV seasons and 11 feature films, it's very > difficult to run out of Star Trek characters. Not main characters, > though. Not to mention all the books, etc. Really, it's not hard to find precompiled lists of this sort of stuff. One could start at someplace like http://starwars.wikia.com/wiki/Coruscant for Star WARS (not Trek) stuff and probably scale up to a very large size with all the names, places, planets, etc. In the old days (pre-Web), it was actually a lot harder to come up with a comprehensive naming scheme. ... 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. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From james at freedomnet.co.nz Mon Mar 15 08:06:09 2010 From: james at freedomnet.co.nz (James Jones) Date: Mon, 15 Mar 2010 09:06:09 -0400 Subject: Network Naming Conventions In-Reply-To: References: <4B9BB812.3090501@freedomnet.co.nz> Message-ID: <4B9E30C1.7000005@freedomnet.co.nz> It was a small network. On 3/13/10 2:58 PM, Randy Bush wrote: >> On my last network I named all the routers after simpsons characters. >> > scaled well? > From MAdcock at hisna.com Mon Mar 15 08:10:40 2010 From: MAdcock at hisna.com (Adcock, Matt [HISNA]) Date: Mon, 15 Mar 2010 06:10:40 -0700 Subject: Network Naming Conventions References: <4B9BB812.3090501@freedomnet.co.nz> <20100313213301.GH69741@neu.cow.org> Message-ID: I've used a Jimmy Buffett theme in test labs before. ? ?Matt Adcock, Manager 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com 700 Hyundai Blvd.?/ Montgomery, AL 36105 P The average office worker uses 10,000 sheets of paper = 1.2 trees, per year By not printing this email, you?ve saved paper, ink and millions of trees ? From: Ravi Pina [mailto:ravi at cow.org] Sent: Sat 3/13/2010 3:33 PM To: Randy Bush Cc: nanog at nanog.org Subject: Re: Network Naming Conventions On Sun, Mar 14, 2010 at 04:58:11AM +0900, Randy Bush wrote: > > On my last network I named all the routers after simpsons characters. > > scaled well? Don't forget there were 5 Snowballs... ? The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information.?If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited.??We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message.?We cannot accept liability for any loss or damage caused by software viruses.?If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments ? -------------- next part -------------- A non-text attachment was scrubbed... Name: vertical_bar.gif Type: image/gif Size: 1391 bytes Desc: vertical_bar.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.gif Type: image/gif Size: 1745 bytes Desc: logo.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: horizontal_bar.gif Type: image/gif Size: 1418 bytes Desc: horizontal_bar.gif URL: From Greg.Whynott at oicr.on.ca Mon Mar 15 08:52:57 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 15 Mar 2010 09:52:57 -0400 Subject: Network Naming Conventions Message-ID: We use confidence inspiring names here for our devices, shakey, broken, jitter, crusty.... G ----- Original Message ----- From: Adcock, Matt [HISNA] To: Ravi Pina ; Randy Bush Cc: nanog at nanog.org Sent: Mon Mar 15 09:10:40 2010 Subject: RE: Network Naming Conventions I've used a Jimmy Buffett theme in test labs before. ? ?Matt Adcock, Manager 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com 700 Hyundai Blvd.?/ Montgomery, AL 36105 P The average office worker uses 10,000 sheets of paper = 1.2 trees, per year By not printing this email, you?ve saved paper, ink and millions of trees ? From: Ravi Pina [mailto:ravi at cow.org] Sent: Sat 3/13/2010 3:33 PM To: Randy Bush Cc: nanog at nanog.org Subject: Re: Network Naming Conventions On Sun, Mar 14, 2010 at 04:58:11AM +0900, Randy Bush wrote: > > On my last network I named all the routers after simpsons characters. > > scaled well? Don't forget there were 5 Snowballs... ? The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information.?If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited.??We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message.?We cannot accept liability for any loss or damage caused by software viruses.?If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments ? From trelane at trelane.net Mon Mar 15 08:57:32 2010 From: trelane at trelane.net (Andrew D Kirch) Date: Mon, 15 Mar 2010 09:57:32 -0400 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <4B9E3CCC.5080604@trelane.net> Nice, I've used mountains (Denali, Everest, Olympus, etc) in the past to name systems. Used profanity for awhile to name machines, there's really quite a bit of it, and every language has it's own set, giving a large pool to choose from. Sadly, when outages occurred, it was somewhat difficult to determine which machines were down, and this was discarded. Andrew Greg Whynott wrote: > We use confidence inspiring names here for our devices, shakey, broken, jitter, crusty.... > > G > From joel.esler at me.com Mon Mar 15 09:05:52 2010 From: joel.esler at me.com (Joel Esler) Date: Mon, 15 Mar 2010 10:05:52 -0400 Subject: Network Naming Conventions In-Reply-To: <4B9E3CCC.5080604@trelane.net> References: <4B9E3CCC.5080604@trelane.net> Message-ID: <4A7CD644-FB26-4791-92B1-3CB663D3C5F0@me.com> Being in the IDS business mostly involved with Snort, I've given my sensors "pig names" in the past. Wilbur, Arnold, Lechoncito.... On Mar 15, 2010, at 9:57 AM, Andrew D Kirch wrote: > Nice, I've used mountains (Denali, Everest, Olympus, etc) in the past to > name systems. Used profanity for awhile to name machines, there's > really quite a bit of it, and every language has it's own set, giving a > large pool to choose from. Sadly, when outages occurred, it was > somewhat difficult to determine which machines were down, and this was > discarded. > > Andrew > > Greg Whynott wrote: >> We use confidence inspiring names here for our devices, shakey, broken, jitter, crusty.... >> >> G >> > > -- Joel Esler http://blog.joelesler.net From nanog at daork.net Mon Mar 15 09:08:19 2010 From: nanog at daork.net (Nathan Ward) Date: Tue, 16 Mar 2010 03:08:19 +1300 Subject: Network Naming Conventions In-Reply-To: References: <4B9BB812.3090501@freedomnet.co.nz> <20100313213301.GH69741@neu.cow.org> Message-ID: On 16/03/2010, at 2:10 AM, Adcock, Matt [HISNA] wrote: > I've used a Jimmy Buffett theme in test labs before. Naming themes are fine in test labs, because devices have a different function/role several times per day, a name acts like an asset tag in that it sticks with it through its lifetime. Same goes for those servers that sit in our networks that I can only really think to call "bitch boxes". They do all sorts of random one-off network hackery tasks, and never get any love. They're not supposed to scale, they were only supposed to be there for one job 5 years ago and they're still there. If I've got guys out there rolling out gear according to cookie cutter designs, I don't want them coming up with names and using ex girlfriends or TV shows or whatever. They're going to run out of ideas, and I don't want to have 50 boxes called "rachel" on the network with no idea what they do. That sort of thing works fine when you're the only person putting the names in to boxes - like in a lab - but no good if you've grown much. I'm a contractor/consultant type thing, and getting my customers to use naming schemes like the rant that follows helps me understand their network if they do things without me, and helps anyone else who comes along too. So, for production network and server gear, I like domain names built with city and site codes: site.city.domain Perhaps if I had a bigger network I'd have .country.domain on the end of that instead. Hosts within each site are told to search within their site, then city, then domain. Here's how in resolv.conf: search site.city.domain, city.domain, domain This lets me refer to a host called 'access-1' as, access-1, or access-1.site, or access-1.site.city depending on where I am. That's handy and saves my lazy ass typing lots. It also means we can have standard configs for lots of things. For example, we can syslog to "syslog" and it will choose either the one in the local site if its size warrants it, or one in the city, or a network-wide one. I'm sure you can think of other ways this can be useful. It can be annoying when a box doesn't let you display a full hostname in a prompt, or fudge it and set the "hostname" to "hostname.site.city" because hostnames shouldn't have periods in them. YMMV, etc. The benefits outweigh the negatives for me I think. Things can get a bit hairy when devices identify themselves by their hostnames in some other protocols though. Ignoring that and using DNS is encouraged, etc. As for hostnames themselves, I have varying ways of doing that, but I never use a naming scheme that won't scale for.. a long time. I always use numbers, but never use leading zeros - ie. access-1, not access-001. It's not hard to sort numerically, come on now. I generally try to use something that describes the devices function. "access-[1-9][0-9]*" = access router. "core-[1-9][0-9]*" = core router. "IP" is implied unless it's something else, ie. "(eth|atm)-access-[1-9][0-9]*" are Ethernet or ATM switches. For places where I collapse functionality, ie. a small site with collapsed core and access boxes, I call them access, because they are less to move and hence need renaming when core boxes come in the future to support additional access boxes. Interface addresses in DNS include the interface name and VLAN or some other logical circuit details (PVC, etc.), as is common. Juniper boxes have re0-hostname.domain and re1-hostname.domain, and also re-hostname.domain if I've got a moving master IP address configured. That's about all I can think of to write, I hope it's useful to someone, YMMV, etc. -- Nathan Ward From jgreco at ns.sol.net Mon Mar 15 09:19:33 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 15 Mar 2010 08:19:33 -0600 (CST) Subject: Network Naming Conventions In-Reply-To: from "Nathan Ward" at Mar 16, 2010 03:08:19 AM Message-ID: <201003151419.o2FEJXJU082484@aurora.sol.net> > So, for production network and server gear, I like domain names > built with city and site codes: > site.city.domain I don't think anyone's saying you can't also do that. Using CLLI or IATA or whatever alongside router names works fine, and using CNAME's allows you to provide both a functional name and a hostname for your device. We've done this for many, many years, and it works fine. ... 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 Greg.Whynott at oicr.on.ca Mon Mar 15 09:39:55 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 15 Mar 2010 10:39:55 -0400 Subject: Network Naming Conventions In-Reply-To: References: <4B9BB812.3090501@freedomnet.co.nz> <20100313213301.GH69741@neu.cow.org> Message-ID: ours is a small network, so is ok to have fun. 8) we do use CNAMES to provide useful information(and make managers happy).. and name servers after the service the provide, eg ldap1.auth.mgt here is an example: gwhynott at ops:~$ host rma.mgt rma.mgt.oicr.on.ca is an alias for RiserRoom5a.hp8212.rack2.mgt.oicr.on.ca. RiserRoom5a.hp8212.rack2.mgt.oicr.on.ca has address 10.3.200.35 gwhynott at ops:~$ -g On Mar 15, 2010, at 10:08 AM, Nathan Ward wrote: > On 16/03/2010, at 2:10 AM, Adcock, Matt [HISNA] wrote: > >> I've used a Jimmy Buffett theme in test labs before. > > Naming themes are fine in test labs, because devices have a different function/role several times per day, a name acts like an asset tag in that it sticks with it through its lifetime. > > Same goes for those servers that sit in our networks that I can only really think to call "bitch boxes". They do all sorts of random one-off network hackery tasks, and never get any love. They're not supposed to scale, they were only supposed to be there for one job 5 years ago and they're still there. > > If I've got guys out there rolling out gear according to cookie cutter designs, I don't want them coming up with names and using ex girlfriends or TV shows or whatever. They're going to run out of ideas, and I don't want to have 50 boxes called "rachel" on the network with no idea what they do. That sort of thing works fine when you're the only person putting the names in to boxes - like in a lab - but no good if you've grown much. > > I'm a contractor/consultant type thing, and getting my customers to use naming schemes like the rant that follows helps me understand their network if they do things without me, and helps anyone else who comes along too. > > > So, for production network and server gear, I like domain names built with city and site codes: > site.city.domain > > Perhaps if I had a bigger network I'd have .country.domain on the end of that instead. > > Hosts within each site are told to search within their site, then city, then domain. Here's how in resolv.conf: > search site.city.domain, city.domain, domain > > This lets me refer to a host called 'access-1' as, access-1, or access-1.site, or access-1.site.city depending on where I am. That's handy and saves my lazy ass typing lots. It also means we can have standard configs for lots of things. For example, we can syslog to "syslog" and it will choose either the one in the local site if its size warrants it, or one in the city, or a network-wide one. I'm sure you can think of other ways this can be useful. > > It can be annoying when a box doesn't let you display a full hostname in a prompt, or fudge it and set the "hostname" to "hostname.site.city" because hostnames shouldn't have periods in them. YMMV, etc. The benefits outweigh the negatives for me I think. Things can get a bit hairy when devices identify themselves by their hostnames in some other protocols though. Ignoring that and using DNS is encouraged, etc. > > As for hostnames themselves, I have varying ways of doing that, but I never use a naming scheme that won't scale for.. a long time. > I always use numbers, but never use leading zeros - ie. access-1, not access-001. It's not hard to sort numerically, come on now. > I generally try to use something that describes the devices function. "access-[1-9][0-9]*" = access router. "core-[1-9][0-9]*" = core router. "IP" is implied unless it's something else, ie. "(eth|atm)-access-[1-9][0-9]*" are Ethernet or ATM switches. > > For places where I collapse functionality, ie. a small site with collapsed core and access boxes, I call them access, because they are less to move and hence need renaming when core boxes come in the future to support additional access boxes. > > Interface addresses in DNS include the interface name and VLAN or some other logical circuit details (PVC, etc.), as is common. > > Juniper boxes have re0-hostname.domain and re1-hostname.domain, and also re-hostname.domain if I've got a moving master IP address configured. > > That's about all I can think of to write, I hope it's useful to someone, YMMV, etc. > > -- > Nathan Ward > > From frank at fttx.org Mon Mar 15 10:34:41 2010 From: frank at fttx.org (Frank A. Coluccio) Date: Mon, 15 Mar 2010 08:34:41 -0700 Subject: Network Naming Conventions Message-ID: <20100315083441.541F86A5@resin12.mta.everyone.net> On-net we use law enforcement agency names, and for those off-net we use the names of reigning mafia families in NFL cities and South American drug cartels. --- MAdcock at hisna.com wrote: From: "Adcock, Matt [HISNA]" To: "Ravi Pina" , "Randy Bush" Cc: nanog at nanog.org Subject: RE: Network Naming Conventions Date: Mon, 15 Mar 2010 06:10:40 -0700 I've used a Jimmy Buffett theme in test labs before. ? ?Matt Adcock, Manager 334-481-6629 (w) / 334-312-5393 (m) / MAdcock at hisna.com 700 Hyundai Blvd.?/ Montgomery, AL 36105 P The average office worker uses 10,000 sheets of paper = 1.2 trees, per year By not printing this email, you?ve saved paper, ink and millions of trees ? From: Ravi Pina [mailto:ravi at cow.org] Sent: Sat 3/13/2010 3:33 PM To: Randy Bush Cc: nanog at nanog.org Subject: Re: Network Naming Conventions On Sun, Mar 14, 2010 at 04:58:11AM +0900, Randy Bush wrote: > > On my last network I named all the routers after simpsons characters. > > scaled well? Don't forget there were 5 Snowballs... ? The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information.?If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited.??We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message.?We cannot accept liability for any loss or damage caused by software viruses.?If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments ? From marcus.sachs at verizon.com Mon Mar 15 10:37:48 2010 From: marcus.sachs at verizon.com (Sachs, Marcus Hans (Marc)) Date: Mon, 15 Mar 2010 11:37:48 -0400 Subject: Network Naming Conventions In-Reply-To: <20100315083441.541F86A5@resin12.mta.everyone.net> References: <20100315083441.541F86A5@resin12.mta.everyone.net> Message-ID: <81D582C724CA1046A279A7EE1299638B034167B4@FHDP1LUMXCV24.us.one.verizon.com> I used to use dead presidents to name devices. Lincoln, Washington, Jefferson, etc. Humorous yet patriotic. Marc From tme at americafree.tv Mon Mar 15 10:44:04 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 15 Mar 2010 11:44:04 -0400 Subject: Network Naming Conventions In-Reply-To: <81D582C724CA1046A279A7EE1299638B034167B4@FHDP1LUMXCV24.us.one.verizon.com> References: <20100315083441.541F86A5@resin12.mta.everyone.net> <81D582C724CA1046A279A7EE1299638B034167B4@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: On Mar 15, 2010, at 11:37 AM, Sachs, Marcus Hans (Marc) wrote: > I used to use dead presidents to name devices. Lincoln, Washington, > Jefferson, etc. Humorous yet patriotic. > We used to use deceased musicians. Popular (i.e., rock) for Linux servers. Classical musicians for everything else. But, lately, we are moving more to just numbers (webNNN, etc.) . Regards Marshall > > Marc From rah at shipwright.com Mon Mar 15 11:15:10 2010 From: rah at shipwright.com (R.A. Hettinga) Date: Mon, 15 Mar 2010 12:15:10 -0400 Subject: Network Naming Conventions In-Reply-To: <20100315083441.541F86A5@resin12.mta.everyone.net> References: <20100315083441.541F86A5@resin12.mta.everyone.net> Message-ID: For Shipwright.com, it's Donald McKay's ships and famous clippers (shortened) (Flying) cloud, (Neptune's) car, &cet, then Jack Aubrey's commands (sophie, surprise...), and, finally, the names of various sentient ships in the Iain M. Banks "Culture" universe (Prosthetic) conscience, (Kiss My) ass, (Shoot Them) later, &cet. Haven't really scratched the surface, there :-). For IBUC.com it's names of bearer instruments throughout history. bullae, talent, penny, &cet. For Philodox.com it's sophists and other intellectual charlatans. protagoras, gorgias, mesmer, lysenko, &cet. No shortage of those, either. rah.ai is only one machine, so far. Haven't come up with a naming convention there, haven't begun to think about it, either. Maybe the words of the LRY Cheer, or something... Cheers, RAH From mvh at hosteurope.de Mon Mar 15 11:44:20 2010 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Mon, 15 Mar 2010 17:44:20 +0100 Subject: Network Naming Conventions In-Reply-To: References: <20100315083441.541F86A5@resin12.mta.everyone.net> <81D582C724CA1046A279A7EE1299638B034167B4@FHDP1LUMXCV24.us.one.verizon.com> Message-ID: <4B9E63E4.5060500@hosteurope.de> Hi there, we brainstormed alot about this topic some time ago, following some conclusions: - anything trademarked might be a problem (so Zoidberg might be cool for a router, but I couldn't take a router named Zapp for serious, and "Farnsworth is going mad" would be considered as normal operation ;-)) - anything just existing in a limited number will be a problem (the mentioned presidents of the US of A might not follow a fast as needed by network growth, same applies to grape varieties, planets and similar) - anything which may be regarded as discriminating like female names might be a problem (while "Sharra" is a beautiful name for a router, at least if you like George R. R. Martin) - anything vendor or model related is a bad idea in case of replacements So, what remains? Stars [astr.] are an option. There are enough of them, they are neither trademarked nor discriminating, there are even enough with quite short and simple names. Further, we wanted device type and location to be encoded. So we ended up with something like xe-0-0-0.cr-polaris.fra1.hosteurope.de, xe-0-1-0.cr-pollux.cgn3.hosteurope.de or ae0-v12.cs-slave.r2.cgn3.hosteurope.de Since Core Switches always are operated as redundant pairs, the are named master/slave, as they work as those per data centre room. Of course, we could have just chosen "cr-$number", but at least a little bit of "colour" should be allowed in such a digital world like ours ;-) Kind regards, .m -- Malte von dem Hagen Teamleitung Network Engineering & Operation Abteilung Technik ----------------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de Welserstra?e 14 - 51149 K?ln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht K?ln - USt-IdNr.: DE187370678 Gesch?ftsf?hrer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulverm?ller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From deepak at ai.net Mon Mar 15 12:04:41 2010 From: deepak at ai.net (Deepak Jain) Date: Mon, 15 Mar 2010 13:04:41 -0400 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> Message-ID: At first blush, I would say it's an interesting idea but won't actually resolve anything of the scariest DDOS attacks we've seen. (Unless I've missed something obvious about your doodle). The advantage/disadvantage of 100,000+ host drone armies is that they don't actually *have* to flood you, per se. 10 pps (or less) each and you are going to crush almost everything without raising any alarms based on statistically significant patterns especially based on IPs. Fully/properly formed HTTP port 80 requests to "/" won't set of any alarms since each host is opening 1 or 2 connections and sending keepalives after that. If you forcibly close the connection, it can wait 5 seconds or 15 minutes before it reopens, it doesn't really care. Anything that hits you faster than that is certainly obnoxious, but MUCH easier to address simply because they are being boring. You *can* punt those requests that are all identical to caches/proxies/IDS/Arbor/what have you and give higher priority to requests that show some differences from them... but you are still mostly at the mercy of serving them unless you *can* learn something about the originator/flow/pattern -- which might get you into a state problem. Where this might work is if you are a large network that only serves one sort of customer and you'd rather block rogue behavior than serve it (at the risk of upsetting your 1% type customers). This would work for that. Probably good at stomping torrents and other things as well. Best, Deepak > -----Original Message----- > From: Guillaume FORTAINE [mailto:gfortaine at live.com] > Sent: Monday, March 15, 2010 2:57 AM > To: nanog at nanog.org > Subject: Re: OBESEUS - A new type of DDOS protector > > Dear Mister Wyble, > > Thank you for your reply. > > > On 03/15/2010 07:00 AM, Charles N Wyble wrote: > > The paper is pretty high level, and the software doesn't appear to be > > available for download. > > > http://www.loud-fat-bloke.co.uk/obeseus.html > > http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz > > > > > So it's kinda theoretical. > > > > > > > "We have it running parallel with a commercial product and it detects > the following > attacks > ? SYN floods > ? RST floods > ? ICMP floods > ? General UDP floods > ? General TCP floods" > > > > > Best Regards, > > Guillaume FORTAINE > From drrtuy at ya.ru Mon Mar 15 12:36:37 2010 From: drrtuy at ya.ru (drrtuy) Date: Mon, 15 Mar 2010 19:36:37 +0200 Subject: Request for Youtube tech contact. Message-ID: <4B9E7025.8060204@ya.ru> Hello. Recently I have faced with youtube content access problem. It looks, that our subnets got banned in some way. I would be very pleased to get Youtube or maybe Google technical contact. WBR Roman A. Nozdrin ISP Tis-Dialog LLC From sakthivadivel.ccie at gmail.com Mon Mar 15 12:50:48 2010 From: sakthivadivel.ccie at gmail.com (sakthi vadivel) Date: Mon, 15 Mar 2010 20:50:48 +0300 Subject: Need some info about "Clean pipe" Message-ID: Hi, Is there any one has idea about what is "clean pipe" ? what exactly upstream providers do using this term " clean pipe"? whether would it add any latency in the traffic flow ? Please if you have any link or draft , please share it. Planning to implement it in our peering pipes ? thanks and regards, sakthi From michael.holstein at csuohio.edu Mon Mar 15 13:06:51 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Mon, 15 Mar 2010 14:06:51 -0400 Subject: Need some info about "Clean pipe" In-Reply-To: References: Message-ID: <4B9E773B.4060006@csuohio.edu> > Is there any one has idea about what is "clean pipe" ? what exactly upstream > providers do using this term " clean pipe"? > Call it "managed DDOS protection" .. sort of like the SaS model, but for networking. Simple ASCII artwork : Internet -> ISP (big pipe) -> DDOS gear -> (your circuit) -> you. In short, instead of paying for a (n*)gbps circuit and buying your own DDOS prevention gear, you buy $n worth of bandwidth that has somebody actively managing the DDOS protection. Prolexic is one of the bigger players in this market (www.prolexic.com). No, it's not cheap. But neither are circuits of sufficient capacity to absorb a 100k botnet type of DDOS and the accompanying RTBH gear (Arbor, et.al.). Cheers, Michael Holstein Cleveland State University From tony at lava.net Mon Mar 15 13:14:15 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 15 Mar 2010 08:14:15 -1000 (HST) Subject: Network Naming Conventions In-Reply-To: References: Message-ID: On Mon, 15 Mar 2010, Greg Whynott wrote: > We use confidence inspiring names here for our devices, shakey, broken, > jitter, crusty.... Ah, try endangered plants/animals :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From rdobbins at arbor.net Mon Mar 15 13:35:29 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 15 Mar 2010 18:35:29 +0000 Subject: Need some info about "Clean pipe" In-Reply-To: <4B9E773B.4060006@csuohio.edu> References: <4B9E773B.4060006@csuohio.edu> Message-ID: On Mar 16, 2010, at 1:06 AM, Michael Holstein wrote: > In short, instead of paying for a (n*)gbps circuit and buying your own DDOS prevention gear, you buy $n worth of bandwidth that has somebody actively managing the DDOS protection. And of course, if one's organization is an SP, one can in fact offer this type of service commercially to one's transit/hosting/co-location/ASP/cloud/etc. customers. ;> Responding to the original poster's question about latency, if the service architecture is well-defined and takes backhaul-induced latency into account as part of the design/topological service coverage, latency experienced by the end-customer is typically minimal. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From bpfankuch at cpgreeley.com Mon Mar 15 13:49:44 2010 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Mon, 15 Mar 2010 12:49:44 -0600 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <01759D50DC387C45A018FE1817CE27D757918D8037@CPExchange1.cpgreeley.com> Can always call a router "packetloss". I used to use the names of transformers ;) -----Original Message----- From: Antonio Querubin [mailto:tony at lava.net] Sent: Monday, March 15, 2010 12:14 PM To: Greg Whynott Cc: 'nanog at nanog.org' Subject: Re: Network Naming Conventions On Mon, 15 Mar 2010, Greg Whynott wrote: > We use confidence inspiring names here for our devices, shakey, > broken, jitter, crusty.... Ah, try endangered plants/animals :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From brandon.kim at brandontek.com Mon Mar 15 13:58:32 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 15 Mar 2010 14:58:32 -0400 Subject: Need some info about "Clean pipe" In-Reply-To: References: , <4B9E773B.4060006@csuohio.edu>, Message-ID: Is this a new concept? I've never heard of this before. It's very interesting. Not that I personally have a need for it, but companies are always finding more "services" to provide for you....errr....manage for you..... > From: rdobbins at arbor.net > To: nanog at nanog.org > Date: Mon, 15 Mar 2010 18:35:29 +0000 > Subject: Re: Need some info about "Clean pipe" > > > On Mar 16, 2010, at 1:06 AM, Michael Holstein wrote: > > > In short, instead of paying for a (n*)gbps circuit and buying your own DDOS prevention gear, you buy $n worth of bandwidth that has somebody actively managing the DDOS protection. > > And of course, if one's organization is an SP, one can in fact offer this type of service commercially to one's transit/hosting/co-location/ASP/cloud/etc. customers. > > ;> > > Responding to the original poster's question about latency, if the service architecture is well-defined and takes backhaul-induced latency into account as part of the design/topological service coverage, latency experienced by the end-customer is typically minimal. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > From rdobbins at arbor.net Mon Mar 15 14:02:32 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 15 Mar 2010 19:02:32 +0000 Subject: Need some info about "Clean pipe" In-Reply-To: References: , <4B9E773B.4060006@csuohio.edu>, Message-ID: <73F3EE59-117E-4ED0-9C10-4D75F6285287@arbor.net> On Mar 16, 2010, at 1:58 AM, Brandon Kim wrote: > Is this a new concept? I've never heard of this before. It's been around for the last 8 years or so - part of the reason folks may not've heard much about it is the inexplicable general underemphasis on the 'Availability' part of the 'Confidentiality - Integrity - Availability' infosec triad. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From aiverson at spamresource.com Mon Mar 15 14:26:48 2010 From: aiverson at spamresource.com (Al Iverson) Date: Mon, 15 Mar 2010 14:26:48 -0500 Subject: Need some info about "Clean pipe" In-Reply-To: References: <4B9E773B.4060006@csuohio.edu> Message-ID: On Mon, Mar 15, 2010 at 1:58 PM, Brandon Kim wrote: > > Is this a new concept? I've never heard of this before. It's very interesting. Not that I personally have > a need for it, but companies are always finding more "services" to provide for you....errr....manage for you..... I didn't really know much about this either, but I saw this guy Joseph Menn speak at a conference recently, and he wrote a book that touches on who the bad guys are nowadays and what kind of stuff they're up to. Prolexic and its founder Barrett Lyon come up quite a bit in the book and I found it insightful. http://www.amazon.com/Fatal-System-Error-Bringing-Internet/dp/1586487485 Cheers, Al Iverson From jfried at deloitte.com Mon Mar 15 14:40:31 2010 From: jfried at deloitte.com (Fried, Jason (US - Hattiesburg)) Date: Mon, 15 Mar 2010 14:40:31 -0500 Subject: Network Naming Conventions In-Reply-To: <4B9E63E4.5060500@hosteurope.de> References: <20100315083441.541F86A5@resin12.mta.everyone.net><81D582C724CA1046A279A7EE1299638B034167B4@FHDP1LUMXCV24.us.one.verizon.com> <4B9E63E4.5060500@hosteurope.de> Message-ID: <9963A3ED609CA0478546F3814FE42BD317A270A1BE@uscnt1405.us.deloitte.com> A Helpful resource. http://www.namingschemes.com/ I used Element names from the periodic table for physical servers in a VMware Cluster once. I used robot names from Futurama for Continuous Integration build agents (Atlassian Bamboo) I have seen stars, greek gods, Lord of the rings characters and places, cheers characters, Greek Letters. This was all at one place mind you. System names should be fun, you can give out a professional aliases to managers. -- Jason Fried Deloitte Consulting LLP Tel/Direct: +1 601 584 1536 www.deloitte.com This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1] From stanrandom at gmail.com Mon Mar 15 14:53:21 2010 From: stanrandom at gmail.com (andrew wales) Date: Mon, 15 Mar 2010 19:53:21 +0000 Subject: Request for Youtube tech contact. In-Reply-To: <4B9E7025.8060204@ya.ru> References: <4B9E7025.8060204@ya.ru> Message-ID: <8f5c65421003151253w7e2ae41dkb86fb047ff5f24dc@mail.gmail.com> On 15 March 2010 17:36, drrtuy wrote: > Recently I have faced with youtube content access problem. It looks, that > our subnets got banned in some way. I would be very pleased to get Youtube > or maybe Google technical contact. > > You're not using 1.0.0.0/8 on your network are you? Andrew From nonobvious at gmail.com Mon Mar 15 17:42:27 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 15 Mar 2010 15:42:27 -0700 Subject: Network Naming Conventions In-Reply-To: <9963A3ED609CA0478546F3814FE42BD317A270A1BE@uscnt1405.us.deloitte.com> References: <20100315083441.541F86A5@resin12.mta.everyone.net> <81D582C724CA1046A279A7EE1299638B034167B4@FHDP1LUMXCV24.us.one.verizon.com> <4B9E63E4.5060500@hosteurope.de> <9963A3ED609CA0478546F3814FE42BD317A270A1BE@uscnt1405.us.deloitte.com> Message-ID: <18a5e7cb1003151542h493724fap8bf27476195cdd30@mail.gmail.com> - Beers (the main server got to be "anchor", which made our ex-Navy boss happy and seemed more professional than some others - Mountains, mostly volcanic - Psychoactive chemicals ("the database is on speed, the development project's on prozac...) - Friends at Princeton used quarks ("Up is down today.") and random names like "3bvax". - Classical composers - Tolkien characters (one of the reasons for DNS was that too many people wanted to name their machine "frodo" or "mozart".) From patrick at ianai.net Mon Mar 15 17:51:17 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 15 Mar 2010 18:51:17 -0400 Subject: Network Naming Conventions In-Reply-To: <18a5e7cb1003151542h493724fap8bf27476195cdd30@mail.gmail.com> References: <20100315083441.541F86A5@resin12.mta.everyone.net> <81D582C724CA1046A279A7EE1299638B034167B4@FHDP1LUMXCV24.us.one.verizon.com> <4B9E63E4.5060500@hosteurope.de> <9963A3ED609CA0478546F3814FE42BD317A270A1BE@uscnt1405.us.deloitte.com> <18a5e7cb1003151542h493724fap8bf27476195cdd30@mail.gmail.com> Message-ID: <41DA6691-206E-4E5E-B82B-138F6AE9BDAC@ianai.net> Sub-atomic particles. Some people say there are not enough, but they just don't realize how many there are. Plus you can expand into elements, then compounds. -- TTFN, patrick From gbonser at seven.com Mon Mar 15 18:30:38 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 15 Mar 2010 16:30:38 -0700 Subject: 10GBase-t switch In-Reply-To: <4B9957B4.7080009@gmail.com> References: <20100311060407.13AFB1CC0D@ptavv.es.net> <4B9957B4.7080009@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6635@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Dave Temkin > Sent: Thursday, March 11, 2010 12:51 PM > To: Kevin Oberman > Cc: nanog at nanog.org > Subject: Re: 10GBase-t switch > > Can you point to another 1U box that has more than 16MB per-port > buffer? > > -Dave Anyone know what the buffer depth is on the Brocade TurboIron 24x? One thing to keep in mind is that neither the Arista nor the Brocade TurboIron are store and forward, they are both "cut through" switches which means they use less buffering for a given amount of traffic. Basically, a packet is already going out the egress interface before it is even completely received on the ingress interface. I have them (TI24X) in production and they work ok. They are lacking some features of the larger switches, though. No MRP or stp-group stuff. But they are a decent switch for the price. George From joelja at bogus.com Mon Mar 15 18:51:37 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 15 Mar 2010 16:51:37 -0700 Subject: 10GBase-t switch In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE6635@RWC-EX1.corp.seven.com> References: <20100311060407.13AFB1CC0D@ptavv.es.net> <4B9957B4.7080009@gmail.com> <5A6D953473350C4B9995546AFE9939EE08FE6635@RWC-EX1.corp.seven.com> Message-ID: <4B9EC809.5000106@bogus.com> On 03/15/2010 04:30 PM, George Bonser wrote: > > > >> -----Original Message----- >> From: Dave Temkin >> Sent: Thursday, March 11, 2010 12:51 PM >> To: Kevin Oberman >> Cc: nanog at nanog.org >> Subject: Re: 10GBase-t switch >> >> Can you point to another 1U box that has more than 16MB per-port >> buffer? >> >> -Dave > > Anyone know what the buffer depth is on the Brocade TurboIron 24x? One > thing to keep in mind is that neither the Arista nor the Brocade > TurboIron are store and forward, they are both "cut through" switches > which means they use less buffering for a given amount of traffic. > Basically, a packet is already going out the egress interface before it > is even completely received on the ingress interface. Strickly speaking when mixed 1Gb/10Gb configurations are supported (as the original poster was requesting) cut-through forwarding no-longer works. > I have them (TI24X) in production and they work ok. They are lacking > some features of the larger switches, though. No MRP or stp-group > stuff. But they are a decent switch for the price. > > George > > > From Michael.Balasko at cityofhenderson.com Mon Mar 15 19:13:40 2010 From: Michael.Balasko at cityofhenderson.com (Michael Balasko) Date: Mon, 15 Mar 2010 17:13:40 -0700 Subject: Inside plant 10G fiber specs? In-Reply-To: <20100314191743.GA28316@angus.ind.WPI.EDU> References: <4B9D2815.6070000@utc.edu> <20100314191743.GA28316@angus.ind.WPI.EDU> Message-ID: <9AF22D15085E7D409ED5710CBC779E930DF52341@COHNTCS09.ci.henderson.nv.us> Bullpucky with regards to 10G optics cost. (1G we can agree on) You can do SPF+ 10G LRM for 220M of shiny-light goodness for 280 bucks. LR is nearly 4 times that much. We find that 220 gets us to most places in the building. Jeff- As far as fiber goes we spec sumitomo or corning and try to stick to LRM optics when we can. Michael Balasko CCSP, MCSE Network Specialist II City of Henderson, Nevada 240 Water St. Henderson, Nevada 89015 702.267.4337 -----Original Message----- From: Chuck Anderson [mailto:cra at WPI.EDU] Sent: Sunday, March 14, 2010 12:18 PM To: nanog at nanog.org Subject: Re: Inside plant 10G fiber specs? On Sun, Mar 14, 2010 at 02:16:53PM -0400, Jeff Kell wrote: > I am working up network specs for a new building, and trying to > accomodate a 10G distribution from the start. The safe bet of running > singlemode everywhere doesn't quite fit due to cost of the optics and > the need for multimode for some other (non-network) devices anyway. Pull a hybrid MM/SM cable. For the life expectancy of most fiber installs, you'll want the SM to run 10G now, and 40G, 100G, ?? in the future over the same infrastructure. SM optics aren't really that much more expensive anymore. From fenner at aristanetworks.com Mon Mar 15 20:06:59 2010 From: fenner at aristanetworks.com (Bill Fenner) Date: Mon, 15 Mar 2010 21:06:59 -0400 Subject: 10GBase-t switch In-Reply-To: <20100311213038.GA7593@moussaka.pmacct.net> References: <20100311060407.13AFB1CC0D@ptavv.es.net> <4B990321.10908@ipax.at> <017265BF3B9640499754DD48777C3D2067B738F2A9@MBX9.EXCHPROD.USA.NET> <4B995EA9.2050708@nipper.de> <20100311213038.GA7593@moussaka.pmacct.net> Message-ID: On Thu, Mar 11, 2010 at 5:30 PM, Paolo Lucente wrote: > On Thu, Mar 11, 2010 at 10:20:41PM +0100, Arnold Nipper wrote: >> On 11.03.2010 16:29 Dylan Ebner wrote >> >> > Do the Arista switches support netflow? From a management perspective >> > netflow can be vital. This is something we have been unhappy with on >> > our 3560 and 3750 cisco's. >> > >> >> They don't (yet). Given you buy enoughboxes, Arista may be willing to >> implement this feature. Would like to have this as well. > > And if you have to request a vendor of L2 devices to implement something > in this sense then definitely ask for sFlow. sFlow will be available at the end of Q2 2010. Bill Fenner Arista Networks, Inc. From gfortaine at live.com Mon Mar 15 20:44:41 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Tue, 16 Mar 2010 02:44:41 +0100 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> Message-ID: Dear Mister Jain, Thank you for your reply. You are speaking about EDoS (Economic Denial of Sustainability). Please see the following article : http://www.rationalsurvivability.com/blog/?s=EDos Consider a new take on an old problem based on ecommerce: Click-fraud. I frame this new embodiment as something called EDoS ? economic denial of sustainability. Distributed Denial of Service (DDoS) attacks are blunt force trauma. The goal, regardless of motive, is to overwhelm infrastructure and remove from service a networked target by employing a distributed number of attackers. An example of DDoS is where a traditional botnet is activated to swarm/overwhelm an Internet connected website using an asynchronous attack which makes the site unavailable due to an exhaustion of resources (compute, network, or storage.) EDoS attacks, however, are death by a thousand cuts. EDoS can also utilize distributed attack sources as well as single entities, but works by making legitimate web requests at volumes that may appear to be ?normal? but are done so to drive compute, network, and storage utility billings in a cloud model abnormally high. An example of EDoS as a variant of click fraud is where a botnet is activated to visit a website whose income results from ecommerce purchases. The requests are all legitimate but purchases are never made. The vendor has to pay the cloud provider for increased elastic use of resources but revenue is never recognized to offset them. We have anti-DDoS capabilities today with tools that are quite mature. DDoS is generally easy to spot given huge increases in traffic. EDoS attacks are not necessarily easy to detect, because the instrumentation and business logic is not present in most applications or stacks of applications and infrastructure to provide the correlation between ?requests? and ? successful transactions.? In the example above, increased requests may look like normal activity. Many customers do not invest in this sort of integration and Cloud providers generally will not have visibility into applications that they do not own. Best Regards, Guillaume FORTAINE On 03/15/2010 06:04 PM, Deepak Jain wrote: > At first blush, I would say it's an interesting idea but won't actually resolve anything of the scariest DDOS attacks we've seen. (Unless I've missed something obvious about your doodle). > > The advantage/disadvantage of 100,000+ host drone armies is that they don't actually *have* to flood you, per se. 10 pps (or less) each and you are going to crush almost everything without raising any alarms based on statistically significant patterns especially based on IPs. Fully/properly formed HTTP port 80 requests to "/" won't set of any alarms since each host is opening 1 or 2 connections and sending keepalives after that. If you forcibly close the connection, it can wait 5 seconds or 15 minutes before it reopens, it doesn't really care. Anything that hits you faster than that is certainly obnoxious, but MUCH easier to address simply because they are being boring. > > You *can* punt those requests that are all identical to caches/proxies/IDS/Arbor/what have you and give higher priority to requests that show some differences from them... but you are still mostly at the mercy of serving them unless you *can* learn something about the originator/flow/pattern -- which might get you into a state problem. > > Where this might work is if you are a large network that only serves one sort of customer and you'd rather block rogue behavior than serve it (at the risk of upsetting your 1% type customers). This would work for that. Probably good at stomping torrents and other things as well. > > Best, > > Deepak > > >> -----Original Message----- >> From: Guillaume FORTAINE [mailto:gfortaine at live.com] >> Sent: Monday, March 15, 2010 2:57 AM >> To: nanog at nanog.org >> Subject: Re: OBESEUS - A new type of DDOS protector >> >> Dear Mister Wyble, >> >> Thank you for your reply. >> >> >> On 03/15/2010 07:00 AM, Charles N Wyble wrote: >> >>> The paper is pretty high level, and the software doesn't appear to be >>> available for download. >>> >> >> http://www.loud-fat-bloke.co.uk/obeseus.html >> >> http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz >> >> >> >> >>> So it's kinda theoretical. >>> >>> >>> >> >> "We have it running parallel with a commercial product and it detects >> the following >> attacks >> ? SYN floods >> ? RST floods >> ? ICMP floods >> ? General UDP floods >> ? General TCP floods" >> >> >> >> >> Best Regards, >> >> Guillaume FORTAINE >> >> > From morrowc.lists at gmail.com Mon Mar 15 20:47:26 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 15 Mar 2010 21:47:26 -0400 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> Message-ID: <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> On Mon, Mar 15, 2010 at 9:44 PM, Guillaume FORTAINE wrote: > Dear Mister Jain, > > Thank you for your reply. > > You are speaking about EDoS (Economic Denial of Sustainability). Please see > the following article : > > http://www.rationalsurvivability.com/blog/?s=EDos > > Consider a new take on an old problem based on ecommerce: Click-fraud. I actually deepak was just saying that if you diffuse the botnet enough you don't have to send more traffic from individual nodes than would be normally expected. In total they swamp the end service (potentially). There wasn't any discussion of clickfraud in his note. From gfortaine at live.com Mon Mar 15 20:59:44 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Tue, 16 Mar 2010 02:59:44 +0100 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> Message-ID: Dear Mister Morrow, Thank you for your reply. To quote : "The advantage/disadvantage of 100,000+ host drone armies is that they don't actually *have* to flood you, per se. 10 pps (or less) each and you are going to crush almost everything without raising any alarms based on statistically significant patterns especially based on IPs. Fully/properly formed HTTP port 80 requests to "/" won't set of any alarms since each host is opening 1 or 2 connections and sending keepalives after that. If you forcibly close the connection, it can wait 5 seconds or 15 minutes before it reopens, it doesn't really care. Anything that hits you faster than that is certainly obnoxious, but MUCH easier to address simply because they are being boring. " From my point of view, it seems similar to the EDoS concept : http://www.rationalsurvivability.com/blog/?s=EDos "EDoS attacks, however, are death by a thousand cuts. EDoS can also utilize distributed attack sources as well as single entities, but works by making legitimate web requests at volumes that may appear to be ?normal? but are done so to drive compute, network, and storage utility billings in a cloud model abnormally high." Best Regards, Guillaume FORTAINE On 03/16/2010 02:47 AM, Christopher Morrow wrote: > On Mon, Mar 15, 2010 at 9:44 PM, Guillaume FORTAINE wrote: > >> Dear Mister Jain, >> >> Thank you for your reply. >> >> You are speaking about EDoS (Economic Denial of Sustainability). Please see >> the following article : >> >> http://www.rationalsurvivability.com/blog/?s=EDos >> >> Consider a new take on an old problem based on ecommerce: Click-fraud. I >> > actually deepak was just saying that if you diffuse the botnet enough > you don't have to send more traffic from individual nodes than would > be normally expected. In total they swamp the end service > (potentially). There wasn't any discussion of clickfraud in his note. > > From ops.lists at gmail.com Mon Mar 15 21:02:48 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 16 Mar 2010 07:32:48 +0530 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> Message-ID: That's right M.Fortaine .. and your model does not, as yet, appear to address what you term as EDoS and what the general security community calls "DDoS" On Tue, Mar 16, 2010 at 7:29 AM, Guillaume FORTAINE wrote: > From my point of view, it seems similar to the EDoS concept : > > http://www.rationalsurvivability.com/blog/?s=EDos > > "EDoS attacks, however, are death by a thousand cuts. EDoS can also utilize > distributed attack sources as well as single entities, but works by making > legitimate web requests at volumes that may appear to be ?normal? but are > done so to drive compute, network, and storage utility billings in a cloud > model abnormally high." -- Suresh Ramasubramanian (ops.lists at gmail.com) From morrowc.lists at gmail.com Mon Mar 15 21:05:28 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 15 Mar 2010 22:05:28 -0400 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> Message-ID: <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> On Mon, Mar 15, 2010 at 10:02 PM, Suresh Ramasubramanian wrote: > That's right M.Fortaine .. and your model does not, as yet, appear to > address what you term as EDoS and what the general security community > calls "DDoS" eh.. I guess I'm splitting hairs. the goal of 100k bots sending 1 query per second to a service that you know can only sustain 50k queries/second is.. not to economically Dos someone, it's to obliterate their service infrastructure. Sure, you could ALSO target something hosted (for instance) at Amazon-AWS and increase costs by making lots and lots and lots of queries, but that wasn't the point of what Deepak wrote, nor what i corrected. -chris > On Tue, Mar 16, 2010 at 7:29 AM, Guillaume FORTAINE wrote: >> From my point of view, it seems similar to the EDoS concept : >> >> http://www.rationalsurvivability.com/blog/?s=EDos >> >> "EDoS attacks, however, are death by a thousand cuts. EDoS can also utilize >> distributed attack sources as well as single entities, but works by making >> legitimate web requests at volumes that may appear to be ?normal? but are >> done so to drive compute, network, and storage utility billings in a cloud >> model abnormally high." > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > From ops.lists at gmail.com Mon Mar 15 21:11:02 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 16 Mar 2010 07:41:02 +0530 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> Message-ID: I got your point. What I was saying is that what he calls EDoS (and I'm sure he'll say obliterating infrastructure is the ultimate form of an economic dos) is just what goes on ... You may or may not be able to overload the AWS infrastructure by too many queries but you sure as hell will blow the application out if that ddos isnt filtered .. edos again. On Tue, Mar 16, 2010 at 7:35 AM, Christopher Morrow wrote: > > > eh.. I guess I'm splitting hairs. the goal of 100k bots sending 1 > query per second to a service that you know can only sustain 50k > queries/second is.. not to economically Dos someone, it's to > obliterate their service infrastructure. > > Sure, you could ALSO target something hosted (for instance) at > Amazon-AWS and increase costs by making lots and lots and lots of > queries, but that wasn't the point of what Deepak wrote, nor what i > corrected. -- Suresh Ramasubramanian (ops.lists at gmail.com) From Jeff-Kell at utc.edu Mon Mar 15 21:15:51 2010 From: Jeff-Kell at utc.edu (Jeff Kell) Date: Mon, 15 Mar 2010 22:15:51 -0400 Subject: Inside plant 10G fiber specs? Message-ID: <1268705751.a0c922bcJeff-Kell@utc.edu> And a follow-up to my original question... I'm reading the Cisco SFP GBIC-SH spec for 50u OM3 and it shows a rating of 1000m? Really? That's better than the LH rating over the same fiber (550m)? Jeff From gfortaine at live.com Mon Mar 15 22:47:57 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Tue, 16 Mar 2010 04:47:57 +0100 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> Message-ID: Misters, Thank you for your reply. 1) First of all, I am absolutely not related to the Obeseus project. From my point of view, the interesting things were that : a) This project was unknown. http://www.google.com/search?q="obeseus"+"ddos"&btnG=Search&hl=en&esrch=FT1&sa=2 b) This project comes from an ISP. http://www.loud-fat-bloke.co.uk/links.html c) Its code is Open Source. http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz My conclusion is that I give far more credit to Obeseus than to Arbor Networks. By the way, I am surprised that this post didn't generate more interest given the uninteresting babble that I have been forced to read in the past on the NANOG mailing-list from the so-called "experts". 2) EDoS is a "DDoS 2.0" DDoS is about malicious traffic. EDoS is malicious traffic engineered to look like legitimate one. However, the goal is the same : "to obliterate the service infrastructure", to quote Mister Morrow. 3) I do my homeworks something that doesn't seem to be the case for a lot of people on this mailing-list. a) I would want to highlight the post of Tom Sands, Chief Network Engineer, Rackspace Hosting entitled "DDoS mitigation recommendations" [1]. -It seems evidence that he tried the Arbor solution so the three "Arbor++" mails don't make sense. -About the fourth one : "Sorry but RTFM http://mailman.nanog.org/pipermail/nanog/2010-January/thread.html#16675 Best regards" Hey kid, Tom Sands subscribed nearly a decade ago on the NANOG mailing-list. When you went out of school, he was already dealing with DoS concerns : http://www.mcabee.org/lists/nanog/Jan-02/msg00177.html b) I am really asking myself how much credit I could give to a spam expert, Suresh Ramasubramanian, about a DDoS related post [2]. c) Mister Morrow, even if you are a Network Security engineer at Google [3] (morrowc at google.com) : -You didn't provide any useful feedback on Obeseus. -You totally missed the point on my other mails. This is definitely disappointing. Is this mailing-list a joke ? Especially, where is Roland Dobbins ? Best Regards, Guillaume FORTAINE [1] http://mailman.nanog.org/pipermail/nanog/2010-January/016675.html [2] http://www.hserus.net/ [3] http://www.linkedin.com/in/morrowc On 03/16/2010 03:11 AM, Suresh Ramasubramanian wrote: > I got your point. What I was saying is that what he calls EDoS (and > I'm sure he'll say obliterating infrastructure is the ultimate form of > an economic dos) is just what goes on ... > > You may or may not be able to overload the AWS infrastructure by too > many queries but you sure as hell will blow the application out if > that ddos isnt filtered .. edos again. > > On Tue, Mar 16, 2010 at 7:35 AM, Christopher Morrow > wrote: > >> >> eh.. I guess I'm splitting hairs. the goal of 100k bots sending 1 >> query per second to a service that you know can only sustain 50k >> queries/second is.. not to economically Dos someone, it's to >> obliterate their service infrastructure. >> >> Sure, you could ALSO target something hosted (for instance) at >> Amazon-AWS and increase costs by making lots and lots and lots of >> queries, but that wasn't the point of what Deepak wrote, nor what i >> corrected. >> > > > From nanog at daork.net Mon Mar 15 23:01:38 2010 From: nanog at daork.net (Nathan Ward) Date: Tue, 16 Mar 2010 17:01:38 +1300 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> Message-ID: <2C943E71-97D5-4141-A7F3-CF2C7064F267@daork.net> If only there were other security experts on this list with a proven ability to make this thread even more absurd. On 16/03/2010, at 4:47 PM, Guillaume FORTAINE wrote: > Misters, > > Thank you for your reply. > > 1) First of all, I am absolutely not related to the Obeseus project. From my point of view, the interesting things were that : > > a) This project was unknown. > > http://www.google.com/search?q="obeseus"+"ddos"&btnG=Search&hl=en&esrch=FT1&sa=2 > > > b) This project comes from an ISP. > > http://www.loud-fat-bloke.co.uk/links.html > > > c) Its code is Open Source. > > http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz > > > My conclusion is that I give far more credit to Obeseus than to Arbor Networks. By the way, I am surprised that this post didn't generate more interest given the uninteresting babble that I have been forced to read in the past on the NANOG mailing-list from the so-called "experts". > > > 2) EDoS is a "DDoS 2.0" > > DDoS is about malicious traffic. > > EDoS is malicious traffic engineered to look like legitimate one. > > However, the goal is the same : "to obliterate the service infrastructure", to quote Mister Morrow. > > > > 3) I do my homeworks something that doesn't seem to be the case for a lot of people on this mailing-list. > > a) I would want to highlight the post of Tom Sands, Chief Network Engineer, Rackspace Hosting entitled "DDoS mitigation recommendations" [1]. > > -It seems evidence that he tried the Arbor solution so the three "Arbor++" mails don't make sense. > > -About the fourth one : > > "Sorry but RTFM > > http://mailman.nanog.org/pipermail/nanog/2010-January/thread.html#16675 > > Best regards" > > Hey kid, Tom Sands subscribed nearly a decade ago on the NANOG mailing-list. When you went out of school, he was already dealing with DoS concerns : > > http://www.mcabee.org/lists/nanog/Jan-02/msg00177.html > > > > b) I am really asking myself how much credit I could give to a spam expert, Suresh Ramasubramanian, about a DDoS related post [2]. > > > c) Mister Morrow, even if you are a Network Security engineer at Google [3] (morrowc at google.com) : > > -You didn't provide any useful feedback on Obeseus. > > -You totally missed the point on my other mails. > > This is definitely disappointing. > > > Is this mailing-list a joke ? > > Especially, where is Roland Dobbins ? > > > Best Regards, > > Guillaume FORTAINE > > [1] http://mailman.nanog.org/pipermail/nanog/2010-January/016675.html > [2] http://www.hserus.net/ > [3] http://www.linkedin.com/in/morrowc > > > > On 03/16/2010 03:11 AM, Suresh Ramasubramanian wrote: >> I got your point. What I was saying is that what he calls EDoS (and >> I'm sure he'll say obliterating infrastructure is the ultimate form of >> an economic dos) is just what goes on ... >> >> You may or may not be able to overload the AWS infrastructure by too >> many queries but you sure as hell will blow the application out if >> that ddos isnt filtered .. edos again. >> >> On Tue, Mar 16, 2010 at 7:35 AM, Christopher Morrow >> wrote: >> >>> >>> eh.. I guess I'm splitting hairs. the goal of 100k bots sending 1 >>> query per second to a service that you know can only sustain 50k >>> queries/second is.. not to economically Dos someone, it's to >>> obliterate their service infrastructure. >>> >>> Sure, you could ALSO target something hosted (for instance) at >>> Amazon-AWS and increase costs by making lots and lots and lots of >>> queries, but that wasn't the point of what Deepak wrote, nor what i >>> corrected. >>> >> >> >> > > > !DSPAM:22,4b9effc213882481555555! > > From rdobbins at arbor.net Mon Mar 15 23:16:59 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 16 Mar 2010 04:16:59 +0000 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> Message-ID: <0CA06D17-695A-4F74-BC30-F5387D284494@arbor.net> On Mar 16, 2010, at 10:47 AM, Guillaume FORTAINE wrote: > Especially, where is Roland Dobbins ? At your service. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rgolodner at infratection.com Mon Mar 15 23:17:29 2010 From: rgolodner at infratection.com (Richard Golodner) Date: Mon, 15 Mar 2010 23:17:29 -0500 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> Message-ID: <1268713049.6353.48.camel@Andromeda> On Tue, 2010-03-16 at 04:47 +0100, Guillaume FORTAINE wrote: > Misters, > > Thank you for your reply. Mr. Fortaine, I am in communication with the gentlemen you address in your latest email on very rare occasions. I ask questions that are way out of my league, yet they answer me with honest information in an attempt to answer my novice queries These guys could beat the hell out of me with the amount of knowledge they have, and as they are knowledgeable, they also have varying personalities. These guys were not being mean or hurtful. They were letting you know what they thought and you asked for it. Sincerely, Richard Golodner From gfortaine at live.com Mon Mar 15 23:30:52 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Tue, 16 Mar 2010 05:30:52 +0100 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: <0CA06D17-695A-4F74-BC30-F5387D284494@arbor.net> References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> <0CA06D17-695A-4F74-BC30-F5387D284494@arbor.net> Message-ID: Dear Mister Dobbins, Thank you for your reply. What do you think about Obeseus ? I look forward to your answer, Best Regards, Guillaume FORTAINE On 03/16/2010 05:16 AM, Dobbins, Roland wrote: > On Mar 16, 2010, at 10:47 AM, Guillaume FORTAINE wrote: > > >> Especially, where is Roland Dobbins ? >> > At your service. > > ;> > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > > > From ras at e-gerbil.net Tue Mar 16 00:39:39 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 16 Mar 2010 00:39:39 -0500 Subject: Inside plant 10G fiber specs? In-Reply-To: <1268705751.a0c922bcJeff-Kell@utc.edu> References: <1268705751.a0c922bcJeff-Kell@utc.edu> Message-ID: <20100316053939.GR75640@gerbil.cluepon.net> On Mon, Mar 15, 2010 at 10:15:51PM -0400, Jeff Kell wrote: > And a follow-up to my original question... > > I'm reading the Cisco SFP GBIC-SH spec for 50u OM3 and it shows a > rating of 1000m? Really? That's better than the LH rating over the > same fiber (550m)? Hi Jeff, I don't know of any optics with a 1km reach over MMF at either 1G or 10G rates. Over OM3 fiber you can get ~260-300 meters of 10G, over older MMF you can potentially get much less, it depends on the exact signal you're trying to pass. Yes you can get 550 meters with 1G LX over MMF, but the MMF itself is ultimately what is limiting you. I recently did a NANOG presentation on some of this, you may want to take a look at: http://www.nanog.org/meetings/nanog48/presentations/Sunday/RAS_opticalnet_N48.pdf Personally my take on this particular problem is to stop doing MMF runs and standardize on SMF where possible. If you do any amount of shopping at all you can find optics for SMF which are barely any more expensive than optics for MMF, especially if you're only talking about 1GE or 10G SFP+. The grief caused over the long run by having more installed MMF plant, especially as you try to move to 10G speeds and beyond, is IMHO not worth the relatively small short term cost optimization. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From gfortaine at live.com Tue Mar 16 02:09:57 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Tue, 16 Mar 2010 08:09:57 +0100 Subject: Need some info about "Clean pipe" In-Reply-To: References: Message-ID: Dear Mister Vadivel, On 03/15/2010 06:50 PM, sakthi vadivel wrote: > Hi, > > Is there any one has idea about what is "clean pipe" ? It's a buzzword : "clean pipe" = Managed Network Security Service (like "Cloud Computing" = Distributed Systems) > what exactly upstream > providers do using this term " clean pipe"? > Mister Holstein gave a good explanation. There is also Google : http://www.google.com/search?q="clean+pipe"+"ddos"&btnG=Search&hl=en&esrch=FT1&sa=2 > whether would it add any latency in the traffic flow ? > Yes, knowing that you will add some computational treatment (stateful inspection) to your network traffic . What are your requirements ? > Please if you have any link or draft , please share it. > ISP : http://www.tatacommunications.com/downloads/enterprise/Data%20Sheet%20-%20%20Internet-clean-pipe%20-%20DDOS%20Protection.pdf http://www.pacnet.com/pub/Product%20Brochures/DDoS_brochure.pdf CISCO : http://www.cisco.com/assets/cdc_content_elements/networking_solutions/service_provider/ddos_protection_sol/ddos_protection.pdf > Planning to implement it in our peering pipes ? > Obeseus ;) ! http://docs.google.com/viewer?url=http://www.loud-fat-bloke.co.uk/obeseus2.pdf > thanks and regards, > sakthi > > > Best Regards, Guillaume FORTAINE From gordslater at ieee.org Tue Mar 16 02:53:02 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 16 Mar 2010 07:53:02 +0000 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> Message-ID: <1268725982.31837.19.camel@ub-g-d2> On Tue, 2010-03-16 at 04:47 +0100, Guillaume FORTAINE wrote: > c) Its code is Open Source. > > http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz > > > My conclusion is that I give far more credit to Obeseus than to Arbor > Networks. > Hmm, the "hey! it's open source!" factor doesn't hold much sway in the network world, no-one will be amazed at that. Many observers are surprised at the amount of free software employed by ISPs and the like, but it's certainly no news to insiders. Cisco, Arbor and others all have products based on Linux kernels and BSDs, as only two examples. Sure, the "products" aren't open sourced, but in a world where moving packets is the main business - what works, goes. (I'm a Beastie/Puffy/Tux proponent myself, so I'm not trying to criticise your approach, just a comment on addressing the list. Most of us here are either one of the following here: 1/ Open-Source users/converts 2/ FOSS users/converts (not the same thing as #1) 3/ "Originals" (eg: Vixie et.al.) 4/ BSD-style-license industrial users (some very big names involved, quietly, in this category) 5/ Quagga/Bird/OpenBGPd users 6/ MS-Windows-only people who happily SSH into various items of hardware running various operating systems all day long without worrying about it. 7/ a combination of all of the above and more At the end of the day, I say it again - what works, goes >Especially, where is Roland Dobbins ? hey, careful, if you're looking for a fight we'll let Randy out of his box, and you don't want to get that ;) It's mainly (ie: intended to be...lol) an operational list, not a theoretical discussion list. It's always good to have a different point of view here, just don't bait the dogs so hard =8^} Gord -- rockin ze NOC ( mit MOC in a shell ) From sakthivadivel.ccie at gmail.com Tue Mar 16 03:43:01 2010 From: sakthivadivel.ccie at gmail.com (sakthi vadivel) Date: Tue, 16 Mar 2010 11:43:01 +0300 Subject: Need some info about "Clean pipe" In-Reply-To: References: Message-ID: Thanks a lot guys...have enough info to drill down on "clean pipe" regards, sakthi On Tue, Mar 16, 2010 at 10:09 AM, Guillaume FORTAINE wrote: > Dear Mister Vadivel, > > > > On 03/15/2010 06:50 PM, sakthi vadivel wrote: > >> Hi, >> >> Is there any one has idea about what is "clean pipe" ? >> > > > It's a buzzword : "clean pipe" = Managed Network Security Service (like > "Cloud Computing" = Distributed Systems) > > > what exactly upstream >> providers do using this term " clean pipe"? >> >> > > Mister Holstein gave a good explanation. > > There is also Google : > > http://www.google.com/search?q= > "clean+pipe"+"ddos"&btnG=Search&hl=en&esrch=FT1&sa=2 > > > whether would it add any latency in the traffic flow ? >> >> > > Yes, knowing that you will add some computational treatment (stateful > inspection) to your network traffic . What are your requirements ? > > > Please if you have any link or draft , please share it. >> >> > > ISP : > > > http://www.tatacommunications.com/downloads/enterprise/Data%20Sheet%20-%20%20Internet-clean-pipe%20-%20DDOS%20Protection.pdf > > http://www.pacnet.com/pub/Product%20Brochures/DDoS_brochure.pdf > > > CISCO : > > > http://www.cisco.com/assets/cdc_content_elements/networking_solutions/service_provider/ddos_protection_sol/ddos_protection.pdf > > > Planning to implement it in our peering pipes ? >> >> > > Obeseus ;) ! > > > http://docs.google.com/viewer?url=http://www.loud-fat-bloke.co.uk/obeseus2.pdf > > > thanks and regards, >> sakthi >> >> >> >> > > > Best Regards, > > Guillaume FORTAINE > > From gordslater at ieee.org Tue Mar 16 03:46:53 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 16 Mar 2010 08:46:53 +0000 Subject: Network Naming Conventions In-Reply-To: <41DA6691-206E-4E5E-B82B-138F6AE9BDAC@ianai.net> References: <20100315083441.541F86A5@resin12.mta.everyone.net> <81D582C724CA1046A279A7EE1299638B034167B4@FHDP1LUMXCV24.us.one.verizon.com> <4B9E63E4.5060500@hosteurope.de> <9963A3ED609CA0478546F3814FE42BD317A270A1BE@uscnt1405.us.deloitte.com> <18a5e7cb1003151542h493724fap8bf27476195cdd30@mail.gmail.com> <41DA6691-206E-4E5E-B82B-138F6AE9BDAC@ianai.net> Message-ID: <1268729213.31837.35.camel@ub-g-d2> On Mon, 2010-03-15 at 18:51 -0400, Patrick W. Gilmore wrote: > but they just don't realize how many there are. wow, deja-vu ! A few years ago I went into a large SSI infrastructure undergoing reconfiguration where the cluster nodes were named along the lines of biscuits, pizzas, vegetables, sweets (candies), types of mud/dirt, grit, etc etc - it made no sense until I came across a README_NOC_OPS document that clarified it all (paraphrasing): "Serviceable nodes have are named after fragments known to be found in Richard M. Stallman's beard. At-risk, scheduled-for-pull or questionable throughput nodes are named after fragments assumed to be found in Ballmer's shorts. " Both categories seemed at least 128-bit-space to me :) Gord -- Do you know? Don't you wonder? What's going on down under you We have all been here before, we have all been here before -David Crosby From sakthivadivel.ccie at gmail.com Tue Mar 16 04:03:28 2010 From: sakthivadivel.ccie at gmail.com (sakthi vadivel) Date: Tue, 16 Mar 2010 12:03:28 +0300 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN Message-ID: Hi all, If someone have come across with this topic "Network / preventive maintenance plan?, please offer me some url to obtain more info on this. Regards, sakthi From clenton at gmail.com Tue Mar 16 04:07:46 2010 From: clenton at gmail.com (Christopher Lenton) Date: Tue, 16 Mar 2010 20:07:46 +1100 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: References: Message-ID: Bahahahahaha. On 16 March 2010 20:03, sakthi vadivel wrote: > Hi all, > > If someone have come across with this topic "Network / preventive > maintenance plan?, please offer me some url to obtain more info on this. > > Regards, > > sakthi > From nenolod at systeminplace.net Tue Mar 16 04:13:28 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Tue, 16 Mar 2010 04:13:28 -0500 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: <1268725982.31837.19.camel@ub-g-d2> References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> <1268725982.31837.19.camel@ub-g-d2> Message-ID: <1268730808.1220.94.camel@petrie> On Tue, 2010-03-16 at 07:53 +0000, gordon b slater wrote: > Hmm, the "hey! it's open source!" factor doesn't hold much sway in the > network world, no-one will be amazed at that. Many observers are > surprised at the amount of free software employed by ISPs and the > like, but it's certainly no news to insiders. Not to mention that it is only "open source for private non-commercial use only", and is crippled. Also, Obeseus doesn't seem to be any better then stuff I have made myself for my own usage and clients' usage. All it does it look at a pcap dump and analyze it. Obeseus is actually worse: it does not work in realtime, the data structures it uses are not suited to realtime detection, and in a DDoS, I think this could take several minutes to trigger appropriate events like IP nullroutes and ACLs etcetera. The best way to detect DDoS is to run a 30 second rolling average. If you're suddenly doing a gigabit inbound within 30 seconds of UDP traffic, you're probably being DDoSed ;). William From sakthivadivel.ccie at gmail.com Tue Mar 16 04:39:11 2010 From: sakthivadivel.ccie at gmail.com (sakthi vadivel) Date: Tue, 16 Mar 2010 12:39:11 +0300 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: References: Message-ID: Yes , chris, It looks funny...ya....i am preparing one with more stuff...options are more and list is growing.. I need to get an expert opinion on this , how other network experts / admins are getting this over. regards. sakthi On Tue, Mar 16, 2010 at 12:07 PM, Christopher Lenton wrote: > Bahahahahaha. > > On 16 March 2010 20:03, sakthi vadivel > wrote: > > Hi all, > > > > If someone have come across with this topic "Network / preventive > > maintenance plan?, please offer me some url to obtain more info on this. > > > > Regards, > > > > sakthi > > > From gfortaine at live.com Tue Mar 16 04:39:13 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Tue, 16 Mar 2010 10:39:13 +0100 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: References: Message-ID: Dear Mister Vadivel, First of all, it would be more enjoyable if you didn't write the title of your email in capital letters. People will assimilate this as spam. Moreover, I have already asked myself if you were serious in your post about "clean pipes". A two seconds search on Google was enough to provide you the needed replies. According to your Linkedin profile [1], you are a network consultant. This post is more than questionable. What are you paid for ? I suppose that Mister Lenton laugh to not tell you that he will not do your homeworks for free as everybody on this mailing-list. On my side, I simply find this pathetic. Good luck :) ! Best Regards, Guillaume FORTAINE [1] http://in.linkedin.com/pub/sakthi-vadivel/b/895/a79 On 03/16/2010 10:07 AM, Christopher Lenton wrote: > Bahahahahaha. > > On 16 March 2010 20:03, sakthi vadivel wrote: > >> Hi all, >> >> If someone have come across with this topic "Network / preventive >> maintenance plan?, please offer me some url to obtain more info on this. >> >> Regards, >> >> sakthi >> >> > > > From sakthivadivel.ccie at gmail.com Tue Mar 16 05:14:45 2010 From: sakthivadivel.ccie at gmail.com (sakthi vadivel) Date: Tue, 16 Mar 2010 13:14:45 +0300 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: References: Message-ID: Yes of-course , people will not do it for free..Even i am not asking people to do it for free,, I just asked,what people follow it on their network or is their any links to follow the standards or samples or templates , so that it can add more perfection in the docs.We all come across these kind of requirements once in while , we may need to find it through google or forums or blogs..etc. Asking or requesting or consulting with people is not an bad idea ..that's the reason we have internet to share stuff and get others opinion on...if at all, it (my mail) bothered you in any case. please ignore...May be you are looking into this in different view. .It doesn't mean that we have a title that every one knows everything...First of all , i am not a document specialist, i come across some requirement where i need to search for ...that is what all other people do.. anyway ...my mail might have bothered you a lot.sorry for that. regards, sakthi On Tue, Mar 16, 2010 at 12:39 PM, Guillaume FORTAINE wrote: > Dear Mister Vadivel, > > First of all, it would be more enjoyable if you didn't write the title of > your email in capital letters. People will assimilate this as spam. > > Moreover, I have already asked myself if you were serious in your post > about "clean pipes". A two seconds search on Google was enough to provide > you the needed replies. > > According to your Linkedin profile [1], you are a network consultant. > > This post is more than questionable. What are you paid for ? > > I suppose that Mister Lenton laugh to not tell you that he will not do your > homeworks for free as everybody on this mailing-list. > > On my side, I simply find this pathetic. > > Good luck :) ! > > Best Regards, > > Guillaume FORTAINE > > > [1] http://in.linkedin.com/pub/sakthi-vadivel/b/895/a79 > > > > On 03/16/2010 10:07 AM, Christopher Lenton wrote: > >> Bahahahahaha. >> >> On 16 March 2010 20:03, sakthi vadivel >> wrote: >> >> >>> Hi all, >>> >>> If someone have come across with this topic "Network / preventive >>> maintenance plan?, please offer me some url to obtain more info on this. >>> >>> Regards, >>> >>> sakthi >>> >>> >>> >> >> >> >> > > From ops.lists at gmail.com Tue Mar 16 05:18:21 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 16 Mar 2010 15:48:21 +0530 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: References: Message-ID: If you want to "search for" something - use google http://www.google.co.in/search?hl=en&q=routine+network+maintenance+plan&sourceid=navclient-ff&rlz=1B3GGGL_enIN311IN311&ie=UTF-8 If you want to ask specific questions, use nanog, or as you're in the asiapac region, use sanog. Before you ask questions, show your work .. say what you have done, what you plan to do, and what question you have based on that. On Tue, Mar 16, 2010 at 3:44 PM, sakthi vadivel wrote: > > .It doesn't mean that we have a title that every one knows > everything...First of all , i am not a document specialist, i come across > some requirement where i need to search for ...that is what all other people > do.. -- Suresh Ramasubramanian (ops.lists at gmail.com) From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Mar 16 05:22:41 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 16 Mar 2010 20:52:41 +1030 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: References: Message-ID: <20100316205241.33b0d68d@opy.nosense.org> On Tue, 16 Mar 2010 15:48:21 +0530 Suresh Ramasubramanian wrote: > If you want to "search for" something - use google > http://www.google.co.in/search?hl=en&q=routine+network+maintenance+plan&sourceid=navclient-ff&rlz=1B3GGGL_enIN311IN311&ie=UTF-8 > A better version - http://tinyurl.com/yen2722 > If you want to ask specific questions, use nanog, or as you're in the > asiapac region, use sanog. > > Before you ask questions, show your work .. say what you have done, > what you plan to do, and what question you have based on that. > > On Tue, Mar 16, 2010 at 3:44 PM, sakthi vadivel > wrote: > > > > .It doesn't mean that we have a title that every one knows > > everything...First of all , i am not a document specialist, i come across > > some requirement where i need to search for ...that is what all other people > > do.. > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > From gfortaine at live.com Tue Mar 16 05:40:18 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Tue, 16 Mar 2010 11:40:18 +0100 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: <20100316205241.33b0d68d@opy.nosense.org> References: <20100316205241.33b0d68d@opy.nosense.org> Message-ID: Let's use Google Caffeine : http://209.85.225.103/ Best Regards, Guillaume FORTAINE On 03/16/2010 11:22 AM, Mark Smith wrote: > On Tue, 16 Mar 2010 15:48:21 +0530 > Suresh Ramasubramanian wrote: > > >> If you want to "search for" something - use google >> http://www.google.co.in/search?hl=en&q=routine+network+maintenance+plan&sourceid=navclient-ff&rlz=1B3GGGL_enIN311IN311&ie=UTF-8 >> >> > A better version - > > http://tinyurl.com/yen2722 > > >> If you want to ask specific questions, use nanog, or as you're in the >> asiapac region, use sanog. >> >> Before you ask questions, show your work .. say what you have done, >> what you plan to do, and what question you have based on that. >> >> On Tue, Mar 16, 2010 at 3:44 PM, sakthi vadivel >> wrote: >> >>> .It doesn't mean that we have a title that every one knows >>> everything...First of all , i am not a document specialist, i come across >>> some requirement where i need to search for ...that is what all other people >>> do.. >>> >> >> >> -- >> Suresh Ramasubramanian (ops.lists at gmail.com) >> >> > > > From lists at quux.de Tue Mar 16 06:21:32 2010 From: lists at quux.de (Jens Link) Date: Tue, 16 Mar 2010 12:21:32 +0100 Subject: Network Naming Conventions In-Reply-To: <18a5e7cb1003151542h493724fap8bf27476195cdd30@mail.gmail.com> (Bill Stewart's message of "Mon, 15 Mar 2010 15:42:27 -0700") References: <20100315083441.541F86A5@resin12.mta.everyone.net> <81D582C724CA1046A279A7EE1299638B034167B4@FHDP1LUMXCV24.us.one.verizon.com> <4B9E63E4.5060500@hosteurope.de> <9963A3ED609CA0478546F3814FE42BD317A270A1BE@uscnt1405.us.deloitte.com> <18a5e7cb1003151542h493724fap8bf27476195cdd30@mail.gmail.com> Message-ID: <877hpctsub.fsf@laphroiag.quux.de> Bill Stewart writes: > - Tolkien characters (one of the reasons for DNS was that too many > people wanted to name their machine "frodo" or "mozart".) Diskworld characters are also quite common. For my own systems I use names of single malts. cheers Je 'typing on Bowmore' ns -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From gordslater at ieee.org Tue Mar 16 06:29:20 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 16 Mar 2010 11:29:20 +0000 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: References: Message-ID: <1268738960.31837.182.camel@ub-g-d2> On Tue, 2010-03-16 at 12:03 +0300, sakthi vadivel wrote: > Hi all, > > If someone have come across with this topic "Network / preventive > maintenance plan?, please offer me some url to obtain more info on this. > > Regards, > > sakthi > Maybe this will help / give some ideas about further reading: http://www.ciscopress.com/bookstore/product.asp?isbn=1587132109 HTH :) Gord PS: maybe I got the wrong idea? - did you mean swap-out / fail-over techniques? Live-working pre-emptive PSU replacement while on RPS? Hot-site/cold-site switching for re-racking? -- kick me, I deserve it, I just can't help myself! From jmamodio at gmail.com Tue Mar 16 07:13:56 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 16 Mar 2010 06:13:56 -0600 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <202705b1003160513x267d460ft7534a2db6dc16644@mail.gmail.com> Access network primarily CLLI codes of the building where the POP is located or closest serving CO, backbone three letter airport codes and in some cases CLLI codes. During the transition form JvNCNet to VERIO/NTT we had some CNAMES to the old network names where things at for example Philadelphia where named cheesesteake_something, and some other names well known to the community at that time such as tiger.jvnc.net for the dialup access server. Regards Jorge From jmamodio at gmail.com Tue Mar 16 07:27:03 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 16 Mar 2010 06:27:03 -0600 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: Message-ID: <202705b1003160527r1b17112eh50f2fa6910146aa1@mail.gmail.com> Is this a joke of some kind ? J From nanog at maunier.org Tue Mar 16 08:15:59 2010 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Tue, 16 Mar 2010 14:15:59 +0100 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <54718ee81003160615k5e882b5fnd64d31c20ed88ec6@mail.gmail.com> 2010/3/13 Paul Stewart > Hi Folks... > > > > With many changes going on this year in our network, I figured it's a > good time to revisit our naming conventions used in our networks. > > > > Today, we use the following example: > > > > Core1-rtr-to-ge1-1-1-vl20.nexicom.net > > > > Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc > etc.... > > > Hello, On our side we're using things like : xe3-3-0-154.tcr1.th2.par.as8218.eu xe3-3-0 : interface (Juniper behaviour) 154 : vlan (if we use vlans on the interface) tcr1 = first transport core router th2 = datacenter (Telehouse 2, generally 2 to 4 letters at our appreciation) par = city (Paris, using the 3 letters IATA City code, not the Airport code such as CDG for Paris) -- Pierre-Yves Maunier From gordslater at ieee.org Tue Mar 16 08:34:37 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 16 Mar 2010 13:34:37 +0000 Subject: Network Naming Conventions In-Reply-To: <54718ee81003160615k5e882b5fnd64d31c20ed88ec6@mail.gmail.com> References: <54718ee81003160615k5e882b5fnd64d31c20ed88ec6@mail.gmail.com> Message-ID: <1268746477.31837.220.camel@ub-g-d2> On Tue, 2010-03-16 at 14:15 +0100, Pierre-Yves Maunier wrote: > par = city (Paris, using the 3 letters IATA City code, not the Airport code > such as CDG for Paris) definitely +1 for IATA city codes. Less problems than the airport ones. ^ ^ ^------------------------------------------ ^ ISTR we've been here ^ before about 6 months ago? If so, apologies. Gord -- "is ncurses what you do if fsck fails?" - anon From rdobbins at arbor.net Tue Mar 16 08:35:43 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 16 Mar 2010 13:35:43 +0000 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> <0CA06D17-695A-4F74-BC30-F5387D284494@arbor.net> Message-ID: <30B768FE-2D3E-4B69-84AA-8717B767C374@arbor.net> On Mar 16, 2010, at 11:30 AM, Guillaume FORTAINE wrote: > What do you think about Obeseus ? Flow telemetry has demonstrated its extraordinary utility to network operators worldwide over the last decade, and continued advances such as Cisco's Flexible NetFlow and the IETF IPFIX/PSAMP effort signify that this is the broad consensus of the operational community. Scalability in terms of logically centralized detection/classification/traceback and minimizing the insertion of additional hardware devices into the network should be core design principles of any operationally viable solution in this space. Volume is only one input into an operationally-viable detection/classification system. Traceback is also very important from an operational perspective. ASIC-based edge routers do an excellent job of mitigating simple high-pps packet-flooding attacks via D/RTBH, S/RTBH and flowspec - again, the utility of these techniques has been validated by the operational community. Layer-7 attacks against various types of services/apps can achieve significant amplification effects and disproportionate impact, are increasing in frequency and impact, and therefore must be addressed by any operationally viable solution in this space. I believe that an effective and operationally useful open-source solution for basic DDoS detection/classification/traceback/mitigation can be implemented using existing widely-used and -understood tools/techniques as described here: ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From eriks at nationalfastfreight.com Tue Mar 16 09:36:22 2010 From: eriks at nationalfastfreight.com (Erik Soosalu) Date: Tue, 16 Mar 2010 10:36:22 -0400 Subject: Network Naming Conventions In-Reply-To: <54718ee81003160615k5e882b5fnd64d31c20ed88ec6@mail.gmail.com> References: <54718ee81003160615k5e882b5fnd64d31c20ed88ec6@mail.gmail.com> Message-ID: <0B224A2FE01CC54C860290D42474BF60042D1008@exchange.nff.local> For pretty much all hardware we use And for routers/switches I add the interface info. e.g: Tracing route to cal1sw-01.nff.local [10.1.9.4] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms con1sw-01-v103.nff.local [10.1.3.2] 2 1 ms <1 ms <1 ms con1rt-01-fe0-0.nff.local [10.1.250.99] 3 4 ms 3 ms 3 ms tor1rt-01-fe0-0s550.nff.local [10.1.254.1] 4 48 ms 48 ms 50 ms cal1rt-01-fe0-1.nff.local [10.1.254.22] 5 56 ms 50 ms 48 ms cal1sw-01.nff.local [10.1.9.4] But this also covers a lot of other stuff. We've got a list of 20 different device types edm1ppc01 - Edmonton 1, page printer, color, unit 1 mtl2rt-02 - Montreal 2, router, unit 2 cal1lp-04 - Calgary 1, line printer 4 con1lt-12 - Concord 1, laptop #12 Everything gets asset tagged and labelled with the ID. Servers are labelled by function (monitor, sql, etc). Thanks, Erik -----Original Message----- From: Pierre-Yves Maunier [mailto:nanog at maunier.org] Sent: Tuesday, March 16, 2010 9:16 AM To: Paul Stewart Cc: NANOG list Subject: Re: Network Naming Conventions 2010/3/13 Paul Stewart > Hi Folks... > > > > With many changes going on this year in our network, I figured it's a > good time to revisit our naming conventions used in our networks. > > > > Today, we use the following example: > > > > Core1-rtr-to-ge1-1-1-vl20.nexicom.net > > > > Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc > etc.... > > > Hello, On our side we're using things like : xe3-3-0-154.tcr1.th2.par.as8218.eu xe3-3-0 : interface (Juniper behaviour) 154 : vlan (if we use vlans on the interface) tcr1 = first transport core router th2 = datacenter (Telehouse 2, generally 2 to 4 letters at our appreciation) par = city (Paris, using the 3 letters IATA City code, not the Airport code such as CDG for Paris) -- Pierre-Yves Maunier From nanog at shreddedmail.com Tue Mar 16 09:38:42 2010 From: nanog at shreddedmail.com (Rick Ernst) Date: Tue, 16 Mar 2010 07:38:42 -0700 Subject: IPv6, multihoming, and customer allocations In-Reply-To: References: Message-ID: Regurgitating the original e-mail for context and follow-up. General responses (some that didn't make it to the list): - "There really is that much space, don't worry about it." - /48s for those that ask for it is fine, ARIN won't ask unless it's a bigger assignment - /52 (or /56) on smaller assignments for conservation if it makes you feel better - Open question on whether byte/octet-boundary assignment (/56 vs /52) is better for some reason I haven't seen anything on the general feel for prefix filtering. I've seen discussions from /48 down to /54. Any feel for what the "standard" (widely deployed) IPv6 prefix filter size will be? Thanks, On Sat, Mar 13, 2010 at 10:49 PM, Rick Ernst wrote: > > A couple of different incantations searching the archive didn't enlighten > me, and I find it hard to believe this hasn't been discussed. Apologies and > a request for pointers if I'm rehashing an old question. > > As a small/regional ISP, we got our /32 assigned and it's time to start > moving forward (customers are asking for it). New hardware, updated IOS, > etc. are in the pipe. Discussions are beginning with our upstream providers > for peering. Now, what do we do? > > A /48 seems to be the standard end-user/multi-homed customer allocation and > is the minimum allocation size from ARIN. A /32 provides 65K /48s so, in > theory, we could give each of our customers a /48 and still have room for > growth. A /48 also appears to be generally accepted as the the longest > prefix allowed through filters (although /49 through /54 are also > discussed). Most customers, however, won't be multi-homed. > > Partly from an IPv4 scarcity perspective, and partly from general > efficiency and thrift, it seems awfully silly to hand out /48s to somebody > that may have a handful of servers or a couple of home machines, especially > with special addressing like link-local if the hosts are not expected to be > internet reachable (back-end servervs, etc). > > Based on the above, I'm looking to establish some initial policies to save > grief in the future: > - /52 allocations to end-users (residential, soho, etc.) > - /48 allocations to those that request it > - If you are going to multi-home, get your own space > > This is obviously a very broad brush and takes an insanely large addressing > model and makes it even larger (assigning /52s instead of /48s) but, to me > at least, it seems reasonable for a first-pass. > > For context/scope, we currently have the equivalent of a bit more than the > equivalent of a /16 (IPv4) in use. > > Thanks, > > From jeroen at unfix.org Tue Mar 16 09:58:49 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 16 Mar 2010 15:58:49 +0100 Subject: IPv6 filtering practices (Was: IPv6, multihoming, and customer allocations) In-Reply-To: References: Message-ID: <4B9F9CA9.9000408@spaghetti.zurich.ibm.com> Rick Ernst wrote: [..] > I haven't seen anything on the general feel for prefix filtering. I've seen > discussions from /48 down to /54. Any feel for what the "standard" (widely > deployed) IPv6 prefix filter size will be? There have been a lot of discussions on this before. (See also http://lists.cluenet.de/mailman/listinfo/ipv6-ops) 1) IRR data, use whois.ripe.net to store also your non-RIPE, thus ARIN,APNIC etc details. This the best place to get your data. When a prefix is here, accept that size, clearly the ISP intends to distribute it that way. 2) Allocation size as given by the RIR(*), thus a /32 if the block is truly a /32 and a /48 when it is a /48. If you have PI that is PI, if you have PA it is Aggregated by you the provider, thus don't chop it up into little blocks. 3) Gert Doering's filter recommendations: http://www.space.net/~gert/RIPE/ipv6-filters.html Also note that it is your network, accept/reject what you want. Do remember the little problem that when you accept a /64 from some ISP, that that prefix has to leak through a lot of little crappy holes to actually get to you, it is a more specific, but the route might be really really bad to get there. As for the /48 vs /56 to end-user discussions, these prefixes are coming out of PA space and thus should not exist in the DFZ. It is Provider Aggregated, not PD (Provider Deaggregated) after all. Greets, Jeroen * = Unfortunately it seems that ARIN is giving 1 entity prefixes spread over multiple blocks, eg four distinct /32's; one can internally aggregate those of course. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From jtk at cymru.com Tue Mar 16 11:17:31 2010 From: jtk at cymru.com (John Kristoff) Date: Tue, 16 Mar 2010 11:17:31 -0500 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <20100316111731.2866cd07@t61p> On Sat, 13 Mar 2010 10:47:28 -0500 "Paul Stewart" wrote: > Going forward, I'd like to examine a better method to identify the > devices.... does anyone have published standards on what they use or > that of other networks and maybe even why they chose those methods? Bottom line is there is probably no perfect naming scheme, but some do suck more than others. This came up on another list and resulted in a long thread, where lots of people still prefer cutesy names, but I'd recommend against them. Here is point where I contributed so I don't need to repeat it here. An ISP's naming scheme may differ slightly due to the multitude of interface conventions you might want a name to associate with, but you'll get the gist of my stance. Then browse forward and backward to see what others had to say. John From owen at delong.com Tue Mar 16 11:17:02 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 16 Mar 2010 09:17:02 -0700 Subject: IPv6, multihoming, and customer allocations In-Reply-To: References: Message-ID: <06B401FA-D168-4282-829B-B5CFA5B28235@delong.com> On Mar 16, 2010, at 7:38 AM, Rick Ernst wrote: > Regurgitating the original e-mail for context and follow-up. > > General responses (some that didn't make it to the list): > - "There really is that much space, don't worry about it." > - /48s for those that ask for it is fine, ARIN won't ask unless it's a > bigger assignment > - /52 (or /56) on smaller assignments for conservation if it makes you > feel better > - Open question on whether byte/octet-boundary assignment (/56 vs /52) is > better for some reason > Octet boundary, not really. Nibble boundary, yes. Both for DNS delegation convenience and for human factors issues. > I haven't seen anything on the general feel for prefix filtering. I've seen > discussions from /48 down to /54. Any feel for what the "standard" (widely > deployed) IPv6 prefix filter size will be? > So far, mostly it's /48 with a few select providers trying to hold the line at /32. Owen From baldwinmathew at gmail.com Tue Mar 16 12:53:42 2010 From: baldwinmathew at gmail.com (Matt Baldwin) Date: Tue, 16 Mar 2010 10:53:42 -0700 Subject: Yahoo Mail Admin Message-ID: <5c0303b01003161053q414a15a6q658fb63d3cf925dc@mail.gmail.com> Hi: Can a Yahoo! mail admin please contact me off-list, please? Tnx. -matt From lists at billfehring.com Tue Mar 16 13:40:43 2010 From: lists at billfehring.com (Bill Fehring) Date: Tue, 16 Mar 2010 11:40:43 -0700 Subject: Yahoo Mail Admin In-Reply-To: <5c0303b01003161053q414a15a6q658fb63d3cf925dc@mail.gmail.com> References: <5c0303b01003161053q414a15a6q658fb63d3cf925dc@mail.gmail.com> Message-ID: On Tue, Mar 16, 2010 at 10:53, Matt Baldwin wrote: > Hi: > > Can a Yahoo! mail admin please contact me off-list, please? > > Tnx. > -matt You didn't say why you believe that you need to talk directly to a Yahoo! mail admin, but if it's related to abuse, it came up a little over a month ago. http://www.merit.edu/mail.archives/nanog/threads2.html Search for "Yahoo Abuse" on 02/09/10. From brandon.kim at brandontek.com Tue Mar 16 13:54:37 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 16 Mar 2010 14:54:37 -0400 Subject: Yahoo Mail Admin In-Reply-To: References: <5c0303b01003161053q414a15a6q658fb63d3cf925dc@mail.gmail.com>, Message-ID: Maybe he's lonely? =) > Date: Tue, 16 Mar 2010 11:40:43 -0700 > Subject: Re: Yahoo Mail Admin > From: lists at billfehring.com > To: baldwinmathew at gmail.com > CC: nanog at nanog.org > > On Tue, Mar 16, 2010 at 10:53, Matt Baldwin wrote: > > Hi: > > > > Can a Yahoo! mail admin please contact me off-list, please? > > > > Tnx. > > -matt > > You didn't say why you believe that you need to talk directly to a > Yahoo! mail admin, but if it's related to abuse, it came up a little > over a month ago. > > http://www.merit.edu/mail.archives/nanog/threads2.html Search for > "Yahoo Abuse" on 02/09/10. > From ayoung at voxel.net Tue Mar 16 14:03:36 2010 From: ayoung at voxel.net (Andrew Young) Date: Tue, 16 Mar 2010 15:03:36 -0400 (EDT) Subject: peer1 contact Message-ID: <00b101cac53b$61846790$248d36b0$@net> Could someone from peer1 noc contact me off thread. Got a issue and could use some help. Thanks! Andrew Young Network Engineer Voxel Dot Net From standalone.sysadmin at gmail.com Tue Mar 16 14:10:46 2010 From: standalone.sysadmin at gmail.com (Matt Simmons) Date: Tue, 16 Mar 2010 15:10:46 -0400 Subject: Newedge USA LLC Contact? Message-ID: <5bcb62b61003161210h56225fb4r1fb8dae55d2c95ba@mail.gmail.com> We're having a problem routing traffic to Newedge USA (www.newedge.com) from our primary and secondary sites. If there's anyone from that group on this list, could you contact me off-list? Thanks very much, --Matt -- LITTLE GIRL: But which cookie will you eat FIRST? COOKIE MONSTER: Me think you have misconception of cookie-eating process. COOKIE MONSTER: Boy, I wish I were a sysadmin so I could go to the NJ-PICC Sysadmin Conference! http://www.picconf.org From gfortaine at live.com Tue Mar 16 14:56:31 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Tue, 16 Mar 2010 20:56:31 +0100 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: <30B768FE-2D3E-4B69-84AA-8717B767C374@arbor.net> References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> <0CA06D17-695A-4F74-BC30-F5387D284494@arbor.net> <30B768FE-2D3E-4B69-84AA-8717B767C374@arbor.net> Message-ID: Dear Mister Dobbins, Thank you for your reply. > Flow telemetry has demonstrated its extraordinary utility to network operators worldwide over the last decade, and continued advances such as Cisco's Flexible NetFlow and the IETF IPFIX/PSAMP effort signify that this is the broad consensus of the operational community. > What about Argus ? [1] http://qosient.com/argus/ > Layer-7 attacks against various types of services/apps can achieve significant amplification effects and disproportionate impact, are increasing in frequency and impact, and therefore must be addressed by any operationally viable solution in this space. > https://www.dpacket.org/ > I believe that an effective and operationally useful open-source solution for basic DDoS detection/classification/traceback/mitigation can be implemented using existing widely-used and -understood tools/techniques as described here: > > > Me and my partners are working on a Flow Based Security Awareness Framework for High-Speed Networks. http://docs.google.com/viewer?url=http://www.vabo.cz/spi/2009/presentations/03/02-celeda_rehak_CAMNEP_no_video.pdf For a demo : http://demo.cognitivesecurity.cz/ I look forward to your answer, Best Regards, Guillaume FORTAINE [1] https://tools.netsa.cert.org/wiki/download/attachments/10027010/Bullard_IntroductionToArgus.pdf?version=1&modificationDate=1263221338000 From joelja at bogus.com Tue Mar 16 16:01:25 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 16 Mar 2010 14:01:25 -0700 Subject: IPv6, multihoming, and customer allocations In-Reply-To: References: Message-ID: <4B9FF1A5.10804@bogus.com> On 03/16/2010 07:38 AM, Rick Ernst wrote: > Regurgitating the original e-mail for context and follow-up. > > General responses (some that didn't make it to the list): > - "There really is that much space, don't worry about it." > - /48s for those that ask for it is fine, ARIN won't ask unless it's a > bigger assignment > - /52 (or /56) on smaller assignments for conservation if it makes you > feel better > - Open question on whether byte/octet-boundary assignment (/56 vs /52) is > better for some reason > > I haven't seen anything on the general feel for prefix filtering. I've seen > discussions from /48 down to /54. Any feel for what the "standard" (widely > deployed) IPv6 prefix filter size will be? I filter at /48. I would consider filtering on something shorter for assignments of /32 or shorter if there were obvious bad behaver's. We do advertise more specific /36s but we also have the covering /32. > Thanks, > > > On Sat, Mar 13, 2010 at 10:49 PM, Rick Ernst wrote: > >> >> A couple of different incantations searching the archive didn't enlighten >> me, and I find it hard to believe this hasn't been discussed. Apologies and >> a request for pointers if I'm rehashing an old question. >> >> As a small/regional ISP, we got our /32 assigned and it's time to start >> moving forward (customers are asking for it). New hardware, updated IOS, >> etc. are in the pipe. Discussions are beginning with our upstream providers >> for peering. Now, what do we do? >> >> A /48 seems to be the standard end-user/multi-homed customer allocation and >> is the minimum allocation size from ARIN. A /32 provides 65K /48s so, in >> theory, we could give each of our customers a /48 and still have room for >> growth. A /48 also appears to be generally accepted as the the longest >> prefix allowed through filters (although /49 through /54 are also >> discussed). Most customers, however, won't be multi-homed. >> >> Partly from an IPv4 scarcity perspective, and partly from general >> efficiency and thrift, it seems awfully silly to hand out /48s to somebody >> that may have a handful of servers or a couple of home machines, especially >> with special addressing like link-local if the hosts are not expected to be >> internet reachable (back-end servervs, etc). >> >> Based on the above, I'm looking to establish some initial policies to save >> grief in the future: >> - /52 allocations to end-users (residential, soho, etc.) >> - /48 allocations to those that request it >> - If you are going to multi-home, get your own space >> >> This is obviously a very broad brush and takes an insanely large addressing >> model and makes it even larger (assigning /52s instead of /48s) but, to me >> at least, it seems reasonable for a first-pass. >> >> For context/scope, we currently have the equivalent of a bit more than the >> equivalent of a /16 (IPv4) in use. >> >> Thanks, >> >> > From rdobbins at arbor.net Tue Mar 16 16:23:14 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 16 Mar 2010 21:23:14 +0000 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> <0CA06D17-695A-4F74-BC30-F5387D284494@arbor.net> <30B768FE-2D3E-4B69-84AA-8717B767C374@arbor.net> Message-ID: On Mar 17, 2010, at 2:56 AM, Guillaume FORTAINE wrote: > What about Argus ? [1] Argus is OK, but I believe that it mainly relies upon packet capture - it does now support NetFlow v5, and v9 support as well as support for Juniper flow telemetry and others is supposed to be coming. I've personally not played with Argus and NetFlow; nfdump/nfsen is a useful open-source NetFlow collection/analysis system. > https://www.dpacket.org/ This is Web forum focused on discussions regarding DPI, which is orthogonal to IDMS. > Me and my partners are working on a Flow Based Security Awareness > Framework for High-Speed Networks. > > http://docs.google.com/viewer?url=http://www.vabo.cz/spi/2009/presentations/03/02-celeda_rehak_CAMNEP_no_video.pdf > > For a demo : > > http://demo.cognitivesecurity.cz/ It's always good to see folks motivated to work on solutions they believe will benefit the community at large. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From randy at psg.com Tue Mar 16 17:56:37 2010 From: randy at psg.com (Bandy Rush) Date: Tue, 16 Mar 2010 15:56:37 -0700 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: References: Message-ID: > If someone have come across with this topic "Network / preventive > maintenance plan?, please offer me some url to obtain more info on this. we have found that weekly washing and polishing with a damp cloth gives about as good a measured improvement as the other methods we tried. From Valdis.Kletnieks at vt.edu Tue Mar 16 18:55:53 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 16 Mar 2010 19:55:53 -0400 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: Your message of "Tue, 16 Mar 2010 15:56:37 PDT." References: Message-ID: <21471.1268783753@localhost> On Tue, 16 Mar 2010 15:56:37 PDT, Bandy Rush said: > > If someone have come across with this topic "Network / preventive > > maintenance plan", please offer me some url to obtain more info on this. > > we have found that weekly washing and polishing with a damp cloth gives > about as good a measured improvement as the other methods we tried. Weekly? Is that your secret? Most of us just do a massive clean-up once a year - the next one is just 15 days away. Maybe that's the problem - go too long between chlorine rinses and you get zombies accumulating in the tubes... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From egon at egon.cc Tue Mar 16 19:05:17 2010 From: egon at egon.cc (James Downs) Date: Tue, 16 Mar 2010 17:05:17 -0700 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: <21471.1268783753@localhost> References: <21471.1268783753@localhost> Message-ID: <2AD2D22E-9C94-4C36-88EE-3ADBE0C31AA1@egon.cc> On Mar 16, 2010, at 4:55 PM, Valdis.Kletnieks at vt.edu wrote: > Weekly? Is that your secret? Most of us just do a massive clean-up > once > a year - the next one is just 15 days away. Maybe that's the > problem - go I still have a box of the plastic covers to put on the ends of the cables when the internet lines are cleaned. Our series of tubes are never clogged, but sometimes some dust gets blown out. From jmamodio at gmail.com Tue Mar 16 19:21:57 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 16 Mar 2010 18:21:57 -0600 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: References: Message-ID: <202705b1003161721h79fba1kd09bee3fbd5ab8f2@mail.gmail.com> Change your router's oil every three months or six thousand petabytes, whatever it comes first, some models may require maintenance sooner than you expect or plan, others may run forever and become difficult to find where the heck are they located. Some devices designed in Japan have the tendency to randomly increase out of control the speed of your interfaces, if you experience that problem send them to the factory for refurbishing and to be resold to a poor ISP. Never, ever, clean fiber optic connectors with spit ... J From steve at ibctech.ca Tue Mar 16 20:06:09 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 16 Mar 2010 21:06:09 -0400 Subject: IPv6, multihoming, and customer allocations In-Reply-To: <4B9FF1A5.10804@bogus.com> References: <4B9FF1A5.10804@bogus.com> Message-ID: <4BA02B01.1070703@ibctech.ca> On 2010.03.16 17:01, Joel Jaeggli wrote: > > > On 03/16/2010 07:38 AM, Rick Ernst wrote: >> Regurgitating the original e-mail for context and follow-up. >> >> General responses (some that didn't make it to the list): >> - "There really is that much space, don't worry about it." >> - /48s for those that ask for it is fine, ARIN won't ask unless it's a >> bigger assignment >> - /52 (or /56) on smaller assignments for conservation if it makes you >> feel better >> - Open question on whether byte/octet-boundary assignment (/56 vs /52) is >> better for some reason >> >> I haven't seen anything on the general feel for prefix filtering. I've seen >> discussions from /48 down to /54. Any feel for what the "standard" (widely >> deployed) IPv6 prefix filter size will be? > > I filter at /48. Although I'm small and insignificant, I do too. > I would consider filtering on something shorter for > assignments of /32 or shorter if there were obvious bad behaver's. We do > advertise more specific /36s but we also have the covering /32. I think that it's going to filter down into a situation where people who can allow a prefix might change their policy, given that the originator is known. That doesn't mean that the next person in the chain will accept it though. For me, I'll accept /48's until one of two things happen: - the RIRs decide that they won't be handing them out anymore - that my routers can't handle the number of prefixes Other than that, I'd like to see /48 become a standard for acceptance. Steve From steve at ibctech.ca Tue Mar 16 20:12:50 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 16 Mar 2010 21:12:50 -0400 Subject: IPv6, multihoming, and customer allocations In-Reply-To: <4BA02B01.1070703@ibctech.ca> References: <4B9FF1A5.10804@bogus.com> <4BA02B01.1070703@ibctech.ca> Message-ID: <4BA02C92.9050208@ibctech.ca> On 2010.03.16 21:06, Steve Bertrand wrote: > On 2010.03.16 17:01, Joel Jaeggli wrote: >> >> >> On 03/16/2010 07:38 AM, Rick Ernst wrote: >>> Regurgitating the original e-mail for context and follow-up. >>> >>> General responses (some that didn't make it to the list): >>> - "There really is that much space, don't worry about it." >>> - /48s for those that ask for it is fine, ARIN won't ask unless it's a >>> bigger assignment >>> - /52 (or /56) on smaller assignments for conservation if it makes you >>> feel better >>> - Open question on whether byte/octet-boundary assignment (/56 vs /52) is >>> better for some reason >>> >>> I haven't seen anything on the general feel for prefix filtering. I've seen >>> discussions from /48 down to /54. Any feel for what the "standard" (widely >>> deployed) IPv6 prefix filter size will be? >> >> I filter at /48. > > Although I'm small and insignificant, I do too. > >> I would consider filtering on something shorter for >> assignments of /32 or shorter if there were obvious bad behaver's. We do >> advertise more specific /36s but we also have the covering /32. > > I think that it's going to filter down into a situation where people who > can allow a prefix might change their policy, given that the originator > is known. That doesn't mean that the next person in the chain will > accept it though. > > For me, I'll accept /48's until one of two things happen: > > - the RIRs decide that they won't be handing them out anymore > - that my routers can't handle the number of prefixes > > Other than that, I'd like to see /48 become a standard for acceptance. err... if the /48 was allocated/assigned from your local RIR from a block that was originally designed for such purposes. Otherwise, I don't blame anyone who is selective on filtering above /48 when the original alloc was /32 (or larger). Steve From jgreco at ns.sol.net Tue Mar 16 20:22:02 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 16 Mar 2010 19:22:02 -0600 (CST) Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) In-Reply-To: <2AD2D22E-9C94-4C36-88EE-3ADBE0C31AA1@egon.cc> from "James Downs" at Mar 16, 2010 05:05:17 PM Message-ID: <201003170122.o2H1M2un098425@aurora.sol.net> > On Mar 16, 2010, at 4:55 PM, Valdis.Kletnieks at vt.edu wrote: > > Weekly? Is that your secret? Most of us just do a massive clean-up > > once > > a year - the next one is just 15 days away. Maybe that's the > > problem - go > > I still have a box of the plastic covers to put on the ends of the > cables when the internet lines are cleaned. Our series of tubes are > never clogged, but sometimes some dust gets blown out. Plastic covers? You're supposed to ue a 50 ohm resistor... ... 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 chris at uplogon.com Tue Mar 16 20:23:55 2010 From: chris at uplogon.com (Chris Gotstein) Date: Tue, 16 Mar 2010 20:23:55 -0500 Subject: Mail List Test Message-ID: <4BA02F2B.1050801@uplogon.com> Haven't gotten a message through the NANOG mailing list for a week or so now. Seeing if this works. -- ---- ---- ---- ---- Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP http://uplogon.com | +1 906 774 4847 | chris at uplogon.com From Bryan.Welch at arrisi.com Tue Mar 16 20:25:37 2010 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Tue, 16 Mar 2010 18:25:37 -0700 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) In-Reply-To: <201003170122.o2H1M2un098425@aurora.sol.net> References: <2AD2D22E-9C94-4C36-88EE-3ADBE0C31AA1@egon.cc> from "James Downs" at Mar 16, 2010 05:05:17 PM <201003170122.o2H1M2un098425@aurora.sol.net> Message-ID: -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Tuesday, March 16, 2010 6:22 PM To: James Downs Cc: nanog at nanog.org Subject: Re: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) >> On Mar 16, 2010, at 4:55 PM, Valdis.Kletnieks at vt.edu wrote: >> > Weekly? Is that your secret? Most of us just do a massive clean-up >> > once >> > a year - the next one is just 15 days away. Maybe that's the >> > problem - go >> >> I still have a box of the plastic covers to put on the ends of the >> cables when the internet lines are cleaned. Our series of tubes are >> never clogged, but sometimes some dust gets blown out. > Plastic covers? You're supposed to ue a 50 ohm resistor... Doing forget to lube the CPU/RE bearings on occasion..... Bryan From if at xip.at Tue Mar 16 20:34:04 2010 From: if at xip.at (Ingo Flaschberger) Date: Wed, 17 Mar 2010 02:34:04 +0100 (CET) Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) In-Reply-To: <201003170122.o2H1M2un098425@aurora.sol.net> References: <201003170122.o2H1M2un098425@aurora.sol.net> Message-ID: and never forget to check the circuit breakers for good grounding, prefered use an etherkill(tm) cable - but be aware, that there is currently no such cable available for fiber optics. If you are unshure if your fiber cables are properly grounded try to use an optical isolation transformer. Kind regards, ingo flaschberger From l at p8x.net Tue Mar 16 20:42:08 2010 From: l at p8x.net (p8x) Date: Wed, 17 Mar 2010 09:42:08 +0800 Subject: Mail List Test In-Reply-To: <4BA02F2B.1050801@uplogon.com> References: <4BA02F2B.1050801@uplogon.com> Message-ID: <4BA03370.609@p8x.net> I have been getting them fine... On 17/03/2010 9:23 AM, Chris Gotstein wrote: > Haven't gotten a message through the NANOG mailing list for a week or so > now. Seeing if this works. > From LarrySheldon at cox.net Tue Mar 16 20:44:21 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 16 Mar 2010 20:44:21 -0500 Subject: Mail List Test In-Reply-To: <4BA03370.609@p8x.net> References: <4BA02F2B.1050801@uplogon.com> <4BA03370.609@p8x.net> Message-ID: <4BA033F5.10607@cox.net> On 3/16/2010 20:42, p8x wrote: > I have been getting them fine... > > On 17/03/2010 9:23 AM, Chris Gotstein wrote: >> Haven't gotten a message through the NANOG mailing list for a week or so >> now. Seeing if this works. Well that is certainly helpful. He is not. >> > > > -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From gfortaine at live.com Tue Mar 16 20:50:15 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Wed, 17 Mar 2010 02:50:15 +0100 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> <75cb24521003151847x97bc4d5qe59190f2b3f9b972@mail.gmail.com> <75cb24521003151905u6400e5b8ka65d86ba3b0bde09@mail.gmail.com> <0CA06D17-695A-4F74-BC30-F5387D284494@arbor.net> <30B768FE-2D3E-4B69-84AA-8717B767C374@arbor.net> Message-ID: Dear Mister Dobbins, Thank you for your reply. > Argus is OK, but I believe that it mainly relies upon packet capture - it does now support NetFlow v5, and v9 support as well as support for Juniper flow telemetry and others is supposed to be coming. > Argus is a superset of Netflow [1]. It's a *better* Netflow : http://docs.google.com/viewer?url=http://www.cert.org/flocon/2009/presentations/Bullard_ControlPlane.pdf > I've personally not played with Argus and NetFlow; nfdump/nfsen is a useful open-source NetFlow collection/analysis system. > > There is also Psyche from Pontetec that is a better nfsen : http://psyche.pontetec.com/ >> Me and my partners are working on a Flow Based Security Awareness >> Framework for High-Speed Networks. >> >> http://docs.google.com/viewer?url=http://www.vabo.cz/spi/2009/presentations/03/02-celeda_rehak_CAMNEP_no_video.pdf >> >> For a demo : >> >> http://demo.cognitivesecurity.cz/ >> > It's always good to see folks motivated to work on solutions they believe will benefit the community at large. > > Thank you. The question is : Who are the people interested in our work ? Best Regards, Guillaume FORTAINE [1] http://www.qosient.com/argus/argusnetflow.htm From jmamodio at gmail.com Tue Mar 16 21:01:22 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 16 Mar 2010 20:01:22 -0600 Subject: Mail List Test In-Reply-To: <4BA02F2B.1050801@uplogon.com> References: <4BA02F2B.1050801@uplogon.com> Message-ID: <202705b1003161901g5224955bibb6f7425dac37734@mail.gmail.com> Messages of operational content have been filtered, we are currently focusing on how to keep your gear oiled and well maintained, your pipes clean, and how obesity can act as a DDoS deterrent. My .02 Jorge On Tue, Mar 16, 2010 at 7:23 PM, Chris Gotstein wrote: > Haven't gotten a message through the NANOG mailing list for a week or so > now. ?Seeing if this works. > > -- > ---- ---- ---- ---- > Chris Gotstein, Sr Network Engineer, UP Logon/Computer Connection UP > http://uplogon.com | +1 906 774 4847 | chris at uplogon.com > > From ggm at apnic.net Tue Mar 16 21:55:05 2010 From: ggm at apnic.net (George Michaelson) Date: Wed, 17 Mar 2010 12:55:05 +1000 Subject: AARNet AS7575 announcing 1.0.0.0/24, 1.1.1.0/24 and 1.2.3.0/24 soon Message-ID: <02C6A2BA-3600-4F07-B52C-2800FDDF54A7@apnic.net> As part of the ongoing measurement of traffic in 1.0.0.0/8 three /24s from the range are shortly going to be announced by AARNet, via AS7575: 1.0.0.0/24 1.1.1.0/24 1.2.3.0/24 This will be happening over the next week or so. cheers -George From frank at fttx.org Tue Mar 16 23:16:28 2010 From: frank at fttx.org (Frank A. Coluccio) Date: Tue, 16 Mar 2010 21:16:28 -0700 Subject: Inside plant 10G fiber specs? Message-ID: <20100316211628.69636647@resin14.mta.everyone.net> re: "The grief caused over the long run by having more installed MMF plant, especially as you try to move to 10G speeds and beyond, is IMHO not worth the relatively small short term cost optimization." A good point, which becomes particularly germane moving forward. According to a TIA presentation I attended today, a 40G link will require eight (8) strands of 8MMF. And the way things look now, a 100Gbps link will require twenty (20) strands of MMF. Neither is likely to reach beyond 100 to 150 meters max. A single pair of SMF will suffice for both and cover eminently greater distances. Until now the tradeoffs have been a no-brainer, favoring MMF. But as the number of strands begin to add bulk and handling issues and the price points continue to fall for SMF at 10G and above, it will become more trying to decide. Incidentally, there's a couple of good pieces in the March 2010 issue of Lightwave Mag on the subject of falling prices of Photonic Integrated Circuits (PICs) at 10G and above, and one on advancements being made in Planar chips as well on pp 6 and 24, respectively,' here: [1]http://online.qmags.com/LW0310/Default.aspx?sessionID=43F4572DBED1C1 526DB2E9CBB&cid=218039&eid=14800#pg1 Frank --- ras at e-gerbil.net wrote: From: Richard A Steenbergen To: Jeff Kell Cc: nanog at nanog.org Subject: Re: RE: Inside plant 10G fiber specs? Date: Tue, 16 Mar 2010 00:39:39 -0500 On Mon, Mar 15, 2010 at 10:15:51PM -0400, Jeff Kell wrote: > And a follow-up to my original question... > > I'm reading the Cisco SFP GBIC-SH spec for 50u OM3 and it shows a > rating of 1000m? Really? That's better than the LH rating over the > same fiber (550m)? Hi Jeff, I don't know of any optics with a 1km reach over MMF at either 1G or 10G rates. Over OM3 fiber you can get ~260-300 meters of 10G, over older MMF you can potentially get much less, it depends on the exact signal you're trying to pass. Yes you can get 550 meters with 1G LX over MMF, but the MMF itself is ultimately what is limiting you. I recently did a NANOG presentation on some of this, you may want to take a look at: http://www.nanog.org/meetings/nanog48/presentations/Sunday/RAS_opticaln et_N48.pdf Personally my take on this particular problem is to stop doing MMF runs and standardize on SMF where possible. If you do any amount of shopping at all you can find optics for SMF which are barely any more expensive than optics for MMF, especially if you're only talking about 1GE or 10G SFP+. The grief caused over the long run by having more installed MMF plant, especially as you try to move to 10G speeds and beyond, is IMHO not worth the relatively small short term cost optimization. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) References 1. http://online.qmags.com/LW0310/Default.aspx?sessionID=43F4572DBED1C1526DB2E9CBB&cid=218039&eid=14800#pg1 From jul_bsd at yahoo.fr Wed Mar 17 01:45:03 2010 From: jul_bsd at yahoo.fr (jul) Date: Wed, 17 Mar 2010 07:45:03 +0100 Subject: anti-ddos test solutions ? Message-ID: <4BA07A6F.4010104@yahoo.fr> Hello nanogers, Following the multiple thread on ddos attack, I was asking myself how someone could test chosen solutions. In most cases, you can't load your Internet access in the same way attackers will (does someone have a botners with ten thousands computers or more :) ?) But a solution to test basic attack (synflood, slowloris, socktress, ...) with 10 to hundred computers would be interesting, so not a tool but more a service. Found only Parabon [1] on Google Does someone know something similar ? Thanks Best regards, Jul Note: Please, don't forget this kind of public tests have some serious legal impact and you need to have an agreement with your ISP/operators to do it in most countries. Note2: Google has a lot of answers. Most of them are about tool and methodology, so not sure for a live test. I'm not looking for a lab solution but real one with business acceptation (and a wise choice on the hours of the test so front-end can be switch to "maintenance mode") [1] New grid service simulates DDoS attacks, May 2009 http://www.computerworlduk.com/technology/security-products/business-continuity/news/index.cfm?newsId=14640 From Skeeve at eintellego.net Wed Mar 17 01:51:13 2010 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Wed, 17 Mar 2010 17:51:13 +1100 Subject: AARNet AS7575 announcing 1.0.0.0/24, 1.1.1.0/24 and 1.2.3.0/24 soon In-Reply-To: <02C6A2BA-3600-4F07-B52C-2800FDDF54A7@apnic.net> References: <02C6A2BA-3600-4F07-B52C-2800FDDF54A7@apnic.net> Message-ID: <292AF25E62B8894C921B893B53A19D973974B77ED8@BUSINESSEX.business.ad> Hey George, If AARNet or someone has the bandwidth, would it not be of value to announce the entire 1/8 and see what areas are targeted by traffic - clearly analysing it and removing DoS or scan traffic. I'm just wondering if there are any /24's or space that is unsuitable to allocate inside 1/8. ...Skeeve -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? > -----Original Message----- > From: George Michaelson [mailto:ggm at apnic.net] > Sent: Wednesday, 17 March 2010 1:55 PM > To: NANOG > Subject: AARNet AS7575 announcing 1.0.0.0/24, 1.1.1.0/24 and 1.2.3.0/24 > soon > > > As part of the ongoing measurement of traffic in 1.0.0.0/8 three /24s > from the range are shortly going to be announced by AARNet, via AS7575: > > 1.0.0.0/24 > 1.1.1.0/24 > 1.2.3.0/24 > > This will be happening over the next week or so. > > cheers > > -George From gordslater at ieee.org Wed Mar 17 03:07:40 2010 From: gordslater at ieee.org (gordon b slater) Date: Wed, 17 Mar 2010 08:07:40 +0000 Subject: anti-ddos test solutions ? In-Reply-To: <4BA07A6F.4010104@yahoo.fr> References: <4BA07A6F.4010104@yahoo.fr> Message-ID: <1268813261.22661.27.camel@ub-g-d2> On Wed, 2010-03-17 at 07:45 +0100, jul dit: > But a solution to test basic attack (synflood, slowloris, socktress, > ...) with 10 to hundred computers would be interesting, so not a tool > but more a service. > > Found only Parabon [1] on Google > > Does someone know something similar ? If you have access to a large enough network in a campus-size establishment, try booting a large room (100+) full of desktop PCs with a live CD/USB and script (or clusterSSH) some hpings, blind netcats (large file as input), iperfs or nmap+nmapscripting) through a _good_ switch stack. Set a low mtu on the interfaces for maximum pps. Please remember to fully air-gap it (and the redundants) from the cloud and the rest of the campus backbone in case you have thick fingers entering the target - your upstream might be tempted to ring you on the BatFone in a hurry. That gets embarrassing, as a friend of mine found out in December last year. Other than that, I suspect it's going to cost you for "real" kit :( Depends how "real" you need it I guess. Kiddies seem to be able to do it with E1/T1-sized pipes so it should at least be better than waiting for one to come your way naturally :) regards Gord -- gurgle. gurgle-splat. splat. splat. sploo-oo-oshhh = rommon From gordslater at ieee.org Wed Mar 17 03:46:54 2010 From: gordslater at ieee.org (gordon b slater) Date: Wed, 17 Mar 2010 08:46:54 +0000 Subject: anti-ddos test solutions ? In-Reply-To: <1268813261.22661.27.camel@ub-g-d2> References: <4BA07A6F.4010104@yahoo.fr> <1268813261.22661.27.camel@ub-g-d2> Message-ID: <1268815614.22661.30.camel@ub-g-d2> On Wed, 2010-03-17 at 08:07 +0000, gordon b slater wrote: (large file as input), iperfs or nmap+nmapscripting) through a _good_ > switch stack. Set a low mtu on the interfaces for maximum pps. ^^^^^^^^^^^^^ ~fail~ correcting myself: set low packet/payload sizes (fragmenting where possible). reason: lack of coffee, too early, feel ill :( G From bit.gossip at chello.nl Wed Mar 17 04:12:04 2010 From: bit.gossip at chello.nl (bit gossip) Date: Wed, 17 Mar 2010 10:12:04 +0100 Subject: anti-ddos test solutions ? In-Reply-To: <4BA07A6F.4010104@yahoo.fr> References: <4BA07A6F.4010104@yahoo.fr> Message-ID: <1268817124.2479.3.camel@localhost> Nessus is a vulnerability scanner: http://www.nessus.org/nessus/ Ixia provides a full Nessus implementation in one of its platform. Bit. On Wed, 2010-03-17 at 07:45 +0100, jul wrote: > Hello nanogers, > > Following the multiple thread on ddos attack, I was asking myself how > someone could test chosen solutions. > In most cases, you can't load your Internet access in the same way > attackers will (does someone have a botners with ten thousands computers > or more :) ?) > But a solution to test basic attack (synflood, slowloris, socktress, > ...) with 10 to hundred computers would be interesting, so not a tool > but more a service. > > Found only Parabon [1] on Google > > Does someone know something similar ? > > Thanks > Best regards, > > Jul > > Note: Please, don't forget this kind of public tests have some serious > legal impact and you need to have an agreement with your ISP/operators > to do it in most countries. > Note2: Google has a lot of answers. Most of them are about tool and > methodology, so not sure for a live test. I'm not looking for a lab > solution but real one with business acceptation (and a wise choice on > the hours of the test so front-end can be switch to "maintenance mode") > > [1] New grid service simulates DDoS attacks, May 2009 > http://www.computerworlduk.com/technology/security-products/business-continuity/news/index.cfm?newsId=14640 > From nanog at daork.net Wed Mar 17 05:15:39 2010 From: nanog at daork.net (Nathan Ward) Date: Wed, 17 Mar 2010 23:15:39 +1300 Subject: AARNet AS7575 announcing 1.0.0.0/24, 1.1.1.0/24 and 1.2.3.0/24 soon In-Reply-To: <292AF25E62B8894C921B893B53A19D973974B77ED8@BUSINESSEX.business.ad> References: <02C6A2BA-3600-4F07-B52C-2800FDDF54A7@apnic.net> <292AF25E62B8894C921B893B53A19D973974B77ED8@BUSINESSEX.business.ad> Message-ID: <3E93606B-4F3B-4629-9710-94210AE0C7D9@daork.net> On 17/03/2010, at 7:51 PM, Skeeve Stevens wrote: > Hey George, > > If AARNet or someone has the bandwidth, would it not be of value to announce the entire 1/8 and see what areas are targeted by traffic - clearly analysing it and removing DoS or scan traffic. > > I'm just wondering if there are any /24's or space that is unsuitable to allocate inside 1/8. If only there was someone who pushed a whole lot of outbound data and had not really that much inbound - advertising 1/8 wouldn't really impact them that much. Some kind of, video sharing site, maybe? route-views>sh ip bgp 1.0.0.0/8 BGP routing table entry for 1.0.0.0/8, version 600951180 Paths: (24 available, no best path) Flag: 0x820 Not advertised to any peer 1239 174 36561 144.228.241.130 (inaccessible) from 144.228.241.130 (144.228.241.130) Origin IGP, localpref 100, valid, external % whois -a AS36561 | grep -i name OrgName: YouTube, Inc. :-) -- Nathan Ward From p.vanarkel at gmail.com Wed Mar 17 05:25:45 2010 From: p.vanarkel at gmail.com (Peter van Arkel) Date: Wed, 17 Mar 2010 11:25:45 +0100 Subject: AARNet AS7575 announcing 1.0.0.0/24, 1.1.1.0/24 and 1.2.3.0/24 soon In-Reply-To: <3E93606B-4F3B-4629-9710-94210AE0C7D9@daork.net> References: <02C6A2BA-3600-4F07-B52C-2800FDDF54A7@apnic.net> <292AF25E62B8894C921B893B53A19D973974B77ED8@BUSINESSEX.business.ad> <3E93606B-4F3B-4629-9710-94210AE0C7D9@daork.net> Message-ID: <20100317102544.GQ26650@cthulhu.oldones.net> On Wed, 17 Mar 2010, Nathan Ward wrote: > route-views>sh ip bgp 1.0.0.0/8 > BGP routing table entry for 1.0.0.0/8, version 600951180 > Paths: (24 available, no best path) > Flag: 0x820 > Not advertised to any peer > 1239 174 36561 > 144.228.241.130 (inaccessible) from 144.228.241.130 (144.228.241.130) > Origin IGP, localpref 100, valid, external > > % whois -a AS36561 | grep -i name > OrgName: YouTube, Inc. http://www.merit.edu/mail.archives/nanog/msg06402.html "Accordingly, APNIC authorizes AS36351 to periodically advertise a route for 1.0.0.0/8 from now until 21 March 2010, and requests that AS36351's peers and upstreams accept this as a legitimate routing advertisement." :-) -- Peter van Arkel T: +31 623988844 | p.vanarkel at gmail.com RIPE: PvA63-RIPE | PGP: 0xA0991D6B From negativeduck at gmail.com Wed Mar 17 06:34:45 2010 From: negativeduck at gmail.com (Bryan Laird) Date: Wed, 17 Mar 2010 07:34:45 -0400 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) MAINTENANCE PLAN In-Reply-To: <202705b1003161721h79fba1kd09bee3fbd5ab8f2@mail.gmail.com> References: <202705b1003161721h79fba1kd09bee3fbd5ab8f2@mail.gmail.com> Message-ID: <20100317113443.GA4764@kitty.darkwing.net> On Tue, Mar 16, 2010 at 06:21:57PM -0600, Jorge Amodio wrote: > Change your router's oil every three months or six thousand petabytes, > whatever it comes first, some models may require maintenance sooner > than you expect or plan, others may run forever and become difficult > to find where the heck are they located. > > Some devices designed in Japan have the tendency to randomly increase > out of control the speed of your interfaces, if you experience that > problem send them to the factory for refurbishing and to be resold to > a poor ISP. > > Never, ever, clean fiber optic connectors with spit ... > > J Is this for extreme routing? Or do the terms of your maintenance schedule change based on routing conditions. My owners manual says that turning on the router is extreme. sending a packet with a GET string is extreme, but I take them to JiffyTic's every now and then for their .signature service. -- Saving Lost Packets since 1993 Have you seen this packet? 1010101111010 From jethro.binks at strath.ac.uk Wed Mar 17 06:45:46 2010 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Wed, 17 Mar 2010 11:45:46 +0000 (GMT) Subject: 10GBase-t switch In-Reply-To: References: Message-ID: On Thu, 11 Mar 2010, Greg Whynott wrote: > Brocade is the king of license gouging, it is no surprise they want > money to view a pdf. To be fair, Foundry removed their manuals from public view a good few years ago, long before Brocade came on the scene. It annoyed me too. Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks Computing Officer, IT Services, University Of Strathclyde, Glasgow, UK > ________________________________________ > From: David Hubbard [dhubbard at dino.hostasaurus.com] > Sent: Thursday, March 11, 2010 1:31 PM > To: nanog at nanog.org > Subject: RE: 10GBase-t switch > > From: Malte von dem Hagen [mailto:mvh at hosteurope.de] > > > > Hi, > > > > Am 11.03.10 16:29 schrieb Dylan Ebner: > > > Do the Arista switches support netflow? > > > > nothing about it in the datasheets, and regarding documentation: > > > > "A registered account and a valid support contract is required to > > access the Software Download and Documentation section of the > > website." > > > > Service fail. > > +1 > > After Brocade started doing that with the Foundry > docs, which hung me out to dry one night when I > needed some docs I didn't have easy access to, I > decided I will try to avoid buying from companies > that require a support contract to read the manual. > > David > > > From drew.weaver at thenap.com Wed Mar 17 07:14:42 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 17 Mar 2010 08:14:42 -0400 Subject: 10GBase-t switch In-Reply-To: References: Message-ID: To be fair, Foundry removed their manuals from public view a good few years ago, long before Brocade came on the scene. It annoyed me too. ----- Don't know if this is still true but you used to be able to view all of the docs for foundry on the JP site. -Drew From nanog at daork.net Wed Mar 17 07:16:41 2010 From: nanog at daork.net (Nathan Ward) Date: Thu, 18 Mar 2010 01:16:41 +1300 Subject: anti-ddos test solutions ? In-Reply-To: <1268817124.2479.3.camel@localhost> References: <4BA07A6F.4010104@yahoo.fr> <1268817124.2479.3.camel@localhost> Message-ID: <11A32E77-458E-4D88-BEA7-7464922917F0@daork.net> Hire/buy what I know as a router tester. People call them different things. It's a device that generates packets, and can normally simulate TCP etc. all the way up to HTTP etc. or higher. BGP, OSPF, MPLS, etc. etc. etc. Tell it to generate packets that look like they come from many many hosts (you can normally simulate some kind of network topology with hosts in different places and hence different TTLs etc.), and viola. They normally let you generate background noise traffic, or you could record 24 hours of packet headers from somewhere in your network and play it back through your test network. This needs a lot of disk of course. I used to work for an anti-ddos vendor (Esphion, now owned by Allot) and built their first test rig. First we did it with a bank of PCs with custom Linux kernel code to generate packets because we were a startup doing things on the cheap and I was a bit masochistic. Then we got a router tester and did exactly the same thing, but in a whole lot less space with a whole lot less effort. Both worked great, naturally I recommend a router tester. -- Nathan Ward From tabrams4 at gmail.com Wed Mar 17 07:57:55 2010 From: tabrams4 at gmail.com (travis abrams) Date: Wed, 17 Mar 2010 08:57:55 -0400 Subject: anti-ddos test solutions ? In-Reply-To: <4BA07A6F.4010104@yahoo.fr> References: <4BA07A6F.4010104@yahoo.fr> Message-ID: <8f4f45bb1003170557ocf93121yaecd3e383653eb4f@mail.gmail.com> I would suggest looking at Breaking Point Systems. They have boxes that can generate lots of traffic and they can also run exploits against the systems. HD Moore was affiliated with this company at some point so Metasploit is probably used for vulnerability testing. Travis www.theIPSGuy.com On Wed, Mar 17, 2010 at 2:45 AM, jul wrote: > Hello nanogers, > > Following the multiple thread on ddos attack, I was asking myself how > someone could test chosen solutions. > In most cases, you can't load your Internet access in the same way > attackers will (does someone have a botners with ten thousands computers > or more :) ?) > But a solution to test basic attack (synflood, slowloris, socktress, > ...) with 10 to hundred computers would be interesting, so not a tool > but more a service. > > Found only Parabon [1] on Google > > Does someone know something similar ? > > Thanks > Best regards, > > Jul > > Note: Please, don't forget this kind of public tests have some serious > legal impact and you need to have an agreement with your ISP/operators > to do it in most countries. > Note2: Google has a lot of answers. Most of them are about tool and > methodology, so not sure for a live test. I'm not looking for a lab > solution but real one with business acceptation (and a wise choice on > the hours of the test so front-end can be switch to "maintenance mode") > > [1] New grid service simulates DDoS attacks, May 2009 > > http://www.computerworlduk.com/technology/security-products/business-continuity/news/index.cfm?newsId=14640 > > -- Travis Abrams, GCIH, CISSP, etc. www.theipsguy.com From gfortaine at live.com Wed Mar 17 08:01:45 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Wed, 17 Mar 2010 14:01:45 +0100 Subject: anti-ddos test solutions ? Message-ID: Dear jul, I would advise Breaking Point : -News : http://www.breakingpointsystems.com/news/press-releases/breakingpoint-distributed-denial-of-service-ddos-and-botnet-test-methodology-helps-networks-prepare-for-imminent-attack -Methodology http://www.breakingpointsystems.com/resources/testmethodologies/breakingpoint-ddos-botnet-testing-methodology -Documentation : http://docs.google.com/viewer?url=http://www.breakingpointsystems.com/resources/how-to-guides/simulating-distributed-denial-of-service.pdf Best Regards, Guillaume FORTAINE On 03/17/2010 07:45 AM, jul wrote: > Hello nanogers, > > Following the multiple thread on ddos attack, I was asking myself how > someone could test chosen solutions. > In most cases, you can't load your Internet access in the same way > attackers will (does someone have a botners with ten thousands computers > or more :) ?) > But a solution to test basic attack (synflood, slowloris, socktress, > ...) with 10 to hundred computers would be interesting, so not a tool > but more a service. > > Found only Parabon [1] on Google > > Does someone know something similar ? > > Thanks > Best regards, > > Jul > > Note: Please, don't forget this kind of public tests have some serious > legal impact and you need to have an agreement with your ISP/operators > to do it in most countries. > Note2: Google has a lot of answers. Most of them are about tool and > methodology, so not sure for a live test. I'm not looking for a lab > solution but real one with business acceptation (and a wise choice on > the hours of the test so front-end can be switch to "maintenance mode") > > [1] New grid service simulates DDoS attacks, May 2009 > http://www.computerworlduk.com/technology/security-products/business-continuity/news/index.cfm?newsId=14640 > > > > From wsummers at deerfield.edu Wed Mar 17 09:01:24 2010 From: wsummers at deerfield.edu (Summers, William) Date: Wed, 17 Mar 2010 10:01:24 -0400 Subject: ISC DHCP server failover Message-ID: Greetings Nanog members, I am wondering if anyone has implemented the failover features of ISC DHCP? And if so, how successful has failover been in your environment? Many thanks, William Summers Network Administrator Information Technology Services Deerfield Academy From sthaug at nethelp.no Wed Mar 17 09:09:53 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 17 Mar 2010 15:09:53 +0100 (CET) Subject: ISC DHCP server failover In-Reply-To: References: Message-ID: <20100317.150953.71121227.sthaug@nethelp.no> > I am wondering if anyone has implemented the failover features of ISC DHCP? And if so, how successful has failover been in your environment? Yes, some of us have implemented DHCP failover using ISC DHCP. However, you are much more likely to get answers to ISC DHCP questions if you ask on the dhcp-users at lists.isc.org list. See https://lists.isc.org/mailman/listinfo/dhcp-users Steinar Haug, Nethelp consulting, sthaug at nethelp.no From dwhite at olp.net Wed Mar 17 09:22:06 2010 From: dwhite at olp.net (Dan White) Date: Wed, 17 Mar 2010 09:22:06 -0500 Subject: ISC DHCP server failover In-Reply-To: References: Message-ID: <20100317142206.GB4773@dan.olp.net> On 17/03/10?10:01?-0400, Summers, William wrote: >Greetings Nanog members, > >I am wondering if anyone has implemented the failover features of ISC DHCP? And if so, how successful has failover been in your environment? We've been running version 4 in a failover scenario for a couple of years. It's worked very well for us in an ISP environment. We serve several networks from a pair of servers. We've experienced two types of problems from time to time: The servers stop balancing their addresses, and one server starts to exhibit 'peer holds all free leases' in its logs, in which case we need to restart the dhcpd process(es) to force a rebalance. In some cases, and I'm not sure which equipment may be to blame, if one server goes down then the other server will not hand out addresses to clients which had originally received addresses from the failed server. We've dealt with that by balancing our lease times with our MTTR for a failed server. -- Dan White From sfouant at shortestpathfirst.net Wed Mar 17 10:53:37 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 17 Mar 2010 09:53:37 -0600 Subject: anti-ddos test solutions ? In-Reply-To: References: Message-ID: <003101cac5ea$0327a770$0976f650$@net> > -----Original Message----- > From: Guillaume FORTAINE [mailto:gfortaine at live.com] > Sent: Wednesday, March 17, 2010 7:02 AM > To: nanog at nanog.org > Subject: Re: anti-ddos test solutions ? > > Dear jul, > > I would advise Breaking Point : To those advising using BreakingPoint for DDoS simulation, I have to ask have you ever actually used it? I have spent considerable time using the BreakingPoint in my DDoS lab and I can tell you that I for one would absolutely and unequivocally NOT advocate using the BreakingPoint for DDoS testing. Sure it's a good box for testing firewalls, but the FPGAs on that box are extremely limited and I would be remiss if I didn't warn you before using this box as a DDoS simulation platform. Here are some of the limitations I've encountered when using the BreakingPoint BPS Elite: - No support for ICMP or ICMP flooding attacks - There are several methods to similate UDP and TCP floods - AppSim and ClientSim only allow you to generate UDP/TCP floods using fixed ports. Another component called Routing Robot lets you use randomize source/destination ports, but is limited to only 64 hosts per interface. In my experience most DDoS attacks are far and away above 64 source hosts. - No ability to fragment packets or modify other items within the packets, such as bits in the IP Options portion of the IP header. - No ability to manipulate DSCP bits with fine grained control - No ability to parse microflows - for example, when running a test, one can look at the Applications tab and see a visible display of how much DNS traffic is received vs. HTTP traffic, however there is no ability to parse the individual microflows within the DNS traffic, for example to identify the malicious DNS traffic vs. the good DNS traffic - Large amount of issues with the Web based GUI, which will cause the end-user considerable frustration when you have to continually reopen the application due to hangs, etc. This is just a small sample of the issues I've encountered. All I'm saying is don't say I didn't warn you. This is *NOT* the box for DDoS testing. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From bdfleming at kanren.net Wed Mar 17 11:26:38 2010 From: bdfleming at kanren.net (Brad Fleming) Date: Wed, 17 Mar 2010 11:26:38 -0500 Subject: L2TPv3 Vendor Support Message-ID: Hello all, We've run across a project that requires support for several (ie: 10-20) L2TPv3 tunnels due to user needs/constraints. As far as I can tell, the only major vendor supporting L2TPv3 features at this time is Cisco; however, I openly admit that I'm not very familiar with the more traditional service provider offerings. While I'd love to drop a ton of cash on some new Cisco gear, I'm afraid that will push our budget over the limit. Is there a box out there with decent port density at a reasonable price that supports L2TPv3? It doesn't need a TON of management features.. it'll only be used as an L2TPv3 aggregator. I very much appreciate any suggestions or insights. -- Brad Fleming From bgreene at senki.org Wed Mar 17 11:27:20 2010 From: bgreene at senki.org (Barry Raveendran Greene) Date: Wed, 17 Mar 2010 09:27:20 -0700 Subject: anti-ddos test solutions ? In-Reply-To: <003101cac5ea$0327a770$0976f650$@net> References: <003101cac5ea$0327a770$0976f650$@net> Message-ID: <002801cac5ee$c4af94d0$4e0ebe70$@org> I use all the testing tools out there for DDOS testing (you name it I've most likely have used or currently have in the lab). The only way I've been able to whack anti-DDOS solutions is by build a couple of racks of servers to emulate a DDOS Botnet. From brandon.kim at brandontek.com Wed Mar 17 11:55:00 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 17 Mar 2010 12:55:00 -0400 Subject: anti-ddos test solutions ? In-Reply-To: <002801cac5ee$c4af94d0$4e0ebe70$@org> References: , <003101cac5ea$0327a770$0976f650$@net>, <002801cac5ee$c4af94d0$4e0ebe70$@org> Message-ID: Hey Barry, What program do you use to simulate the DDOS Botnet? Is it a custom program or something off the shelf? > From: bgreene at senki.org > To: sfouant at shortestpathfirst.net; gfortaine at live.com; nanog at nanog.org > Subject: RE: anti-ddos test solutions ? > Date: Wed, 17 Mar 2010 09:27:20 -0700 > > I use all the testing tools out there for DDOS testing (you name it I've > most likely have used or currently have in the lab). The only way I've been > able to whack anti-DDOS solutions is by build a couple of racks of servers > to emulate a DDOS Botnet. > > > > From matthew at matthew.at Wed Mar 17 12:00:21 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 17 Mar 2010 10:00:21 -0700 Subject: anti-ddos test solutions ? In-Reply-To: References: , <003101cac5ea$0327a770$0976f650$@net>, <002801cac5ee$c4af94d0$4e0ebe70$@org> Message-ID: <4BA10AA5.3070502@matthew.at> Brandon Kim wrote: > Hey Barry, > > What program do you use to simulate the DDOS Botnet? Is it a custom program or something off > the shelf? > > > Don't you just set up an IRC server and then say something inflammatory to the wrong person? Matthew Kaufman From drew.weaver at thenap.com Wed Mar 17 12:17:30 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 17 Mar 2010 13:17:30 -0400 Subject: anti-ddos test solutions ? In-Reply-To: <4BA10AA5.3070502@matthew.at> References: , <003101cac5ea$0327a770$0976f650$@net>, <002801cac5ee$c4af94d0$4e0ebe70$@org> <4BA10AA5.3070502@matthew.at> Message-ID: Or let your users post something on their blog that person x y z might not like =) -----Original Message----- From: Matthew Kaufman [mailto:matthew at matthew.at] Sent: Wednesday, March 17, 2010 1:00 PM To: Brandon Kim Cc: nanog at nanog.org Subject: Re: anti-ddos test solutions ? Brandon Kim wrote: > Hey Barry, > > What program do you use to simulate the DDOS Botnet? Is it a custom program or something off > the shelf? > > > Don't you just set up an IRC server and then say something inflammatory to the wrong person? Matthew Kaufman From Valdis.Kletnieks at vt.edu Wed Mar 17 12:20:00 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 17 Mar 2010 13:20:00 -0400 Subject: anti-ddos test solutions ? In-Reply-To: Your message of "Wed, 17 Mar 2010 10:00:21 PDT." <4BA10AA5.3070502@matthew.at> References: <003101cac5ea$0327a770$0976f650$@net> <002801cac5ee$c4af94d0$4e0ebe70$@org> <4BA10AA5.3070502@matthew.at> Message-ID: <16800.1268846400@localhost> On Wed, 17 Mar 2010 10:00:21 PDT, Matthew Kaufman said: > Don't you just set up an IRC server and then say something inflammatory > to the wrong person? For a slightly more interesting packet mix, go over to 4chan and get anon ticked at you. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bruns at 2mbit.com Wed Mar 17 12:25:47 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 17 Mar 2010 17:25:47 +0000 Subject: anti-ddos test solutions ? In-Reply-To: <16800.1268846400@localhost> References: <003101cac5ea$0327a770$0976f650$@net><002801cac5ee$c4af94d0$4e0ebe70$@org><4BA10AA5.3070502@matthew.at><16800.1268846400@localhost> Message-ID: <1097935603-1268846851-cardhu_decombobulator_blackberry.rim.net-1476589005-@bda895.bisx.prod.on.blackberry> (Written on a blackberry - please don't flame me for top posting.) Depends on what kind of DoS - cause your more likely to experience a phone DoS moreso then an Internet DoS. Hope you don't need to make or receive any calls for a week or two :) -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org -----Original Message----- From: Valdis.Kletnieks at vt.edu Date: Wed, 17 Mar 2010 13:20:00 To: Cc: Subject: Re: anti-ddos test solutions ? On Wed, 17 Mar 2010 10:00:21 PDT, Matthew Kaufman said: > Don't you just set up an IRC server and then say something inflammatory > to the wrong person? For a slightly more interesting packet mix, go over to 4chan and get anon ticked at you. From gfortaine at live.com Wed Mar 17 12:59:03 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Wed, 17 Mar 2010 18:59:03 +0100 Subject: OBESEUS - A new type of DDOS protector In-Reply-To: References: <4B9DCCEF.8000203@knownelement.com> Message-ID: Dear Mister Jain, Thank you for your reply. Please see the following article from Barry Greene : http://www.senki.org/?p=623 DDOS Trends Changing ? More Effective Attack Classes. I will giving an interview today that the industry has done a poor job in communicating the changes in Denial of Service (DOS) attacks. CERT-FI?s release of the ?Sockstress? details yesterday has a few people confused. Outpost24 discovered some new TCP state abuse technique which can cause a range of issue on a TCP stack (see CERT-FI?s release details). It is a serious issue. But, if it is serious, why is there not a lot of attention on this attack vector. The answer is simple. There is a lot of attention ? TCP Connection Oriented State abuse is real. There is a real TCP state DOS threat. It is just not generally visible to the public. In fact, the TCP Connection Oriented State attacks more real than the general IT industry realizes. Why? Cyber-Criminal Market Dynamics! Go back to 2006. In those days, a cyber-criminal would plan a extortion attack. ?Pay me big buck by this date or I?m going to DOS you to oblivion.? To demonstrate the threat is real, the cyber-criminal would provide a demonstration, whacking the victim with a TCP SYN flood which would overwhelm the site?s ability to respond via TCP (TCP table s full). The TCP flood would take up all the target?s bandwidth to the Internet. To achieve this, the cyber-criminal would need to put more bandwidth at the target then the bandwidth available to the target (i.e. throw 1 Gbps of attack traffic down a 155 Mbps link). This overload would trigger a second set of events. The ?demonstration? would send way too many TCP SYNs, filling up the bandwidth to the victim, back pressuring on the Service Provider?s PE router, and creating collateral damage on the SP?s other customers. This collateral damage wakes up the sleeping giant ? with a SP?s SLA getting violated and forcing them to act. Now the cyber-criminal is dealing with their ?target? and the target?s SP. The SP can and will throw want ever resource available to insure their SLAs to the range of the customers to not get violated. The victim gets help (or gets offered a ?clean pipes? service). In the end, the cyber-criminal?s pay off of ?big bucks? is disrupted. All because their TCP State attack threw to many packets at the target. What they need was a better tool. Fast forward to July 2009. A new BOTnet starts an attack on a range of US Government, commercial and Korean sites. The press goes wild with ?North Korean cyber-warefare.? What is missed is that this attack is effective and not choking up bandwidth. This July 2009 attack is typical of what is seen today ? a crafted TCP Connection Oriented State attack which is not a SYN flood. The malware in the BOTNET is designed to use a variety of TCP techniques ? some simple (open a TCP connection and tickle it to keep it alive) and TCP abusive (attacks highlighted by Outpost24, Phrack, and others). All these techniques are designed to fill up a target?s ?state table.? This state table can be a server (web, voice, application), a firewall, a load balancer, a reverse cache or any other device which terminates TCP State. The core principle of these sort of TCP State attack are to keep TCP connections open and alive. The more TCP connections you can keep open, greater the chance you will fill up the TCP state table ? allowing no new TCP connection into the system ? completing the DOS attack. The advantage with this class of TCP State attacks is that you do not need a lot of bandwidth. TCP SYN floods FIFO (First In First Out) the TCP state table, which is why it requires a lot of packets. Connection oriented TCP state attacks just need to open the session and keep the session open, needing far fewer packets. Far fewer packets mean you are not flooding the target?s links to the Internet. Not flooding the links to the Internet means no collateral damage on the SP?s infrastructure or customers. The SP?s SLA is not violated, hence, the SP is not motivated to jump into the middle of the attack. In essence, the cyber-criminal?s goal is complete. They can now threaten the target with ?Pay me big buck by this date or I?m going to DOS you to oblivion? without the big SP getting into the way of the ?big bucks.? The obvious next question is ?if this is so easy, why isn?t it happening more often?? We?ll get to that in the next article. There are a range of factors ? some economic, some technology, and some based on the dialectic with the community which mitigates wide spread extortion, retribution, and vindictive TCP Connection Oriented State Attacks from being more widely used. For now, anyone who is really interested in this topic should download and read Security Assessment of the Transmission Control Protocol (TCP) by Fernando Gont and sponsored by the UK CPNI (Centre for the Protection of National Infrastructure). http://www.cpni.gov.uk/Products/technicalnotes/Feb-09-security-assessment-TCP.aspx Best Regards, Guillaume FORTAINE On 03/15/2010 06:04 PM, Deepak Jain wrote: > At first blush, I would say it's an interesting idea but won't actually resolve anything of the scariest DDOS attacks we've seen. (Unless I've missed something obvious about your doodle). > > The advantage/disadvantage of 100,000+ host drone armies is that they don't actually *have* to flood you, per se. 10 pps (or less) each and you are going to crush almost everything without raising any alarms based on statistically significant patterns especially based on IPs. Fully/properly formed HTTP port 80 requests to "/" won't set of any alarms since each host is opening 1 or 2 connections and sending keepalives after that. If you forcibly close the connection, it can wait 5 seconds or 15 minutes before it reopens, it doesn't really care. Anything that hits you faster than that is certainly obnoxious, but MUCH easier to address simply because they are being boring. > > You *can* punt those requests that are all identical to caches/proxies/IDS/Arbor/what have you and give higher priority to requests that show some differences from them... but you are still mostly at the mercy of serving them unless you *can* learn something about the originator/flow/pattern -- which might get you into a state problem. > > Where this might work is if you are a large network that only serves one sort of customer and you'd rather block rogue behavior than serve it (at the risk of upsetting your 1% type customers). This would work for that. Probably good at stomping torrents and other things as well. > > Best, > > Deepak > > >> -----Original Message----- >> From: Guillaume FORTAINE [mailto:gfortaine at live.com] >> Sent: Monday, March 15, 2010 2:57 AM >> To: nanog at nanog.org >> Subject: Re: OBESEUS - A new type of DDOS protector >> >> Dear Mister Wyble, >> >> Thank you for your reply. >> >> >> On 03/15/2010 07:00 AM, Charles N Wyble wrote: >> >>> The paper is pretty high level, and the software doesn't appear to be >>> available for download. >>> >> >> http://www.loud-fat-bloke.co.uk/obeseus.html >> >> http://www.loud-fat-bloke.co.uk/tools/obeseusvB.tar.gz >> >> >> >> >>> So it's kinda theoretical. >>> >>> >>> >> >> "We have it running parallel with a commercial product and it detects >> the following >> attacks >> ? SYN floods >> ? RST floods >> ? ICMP floods >> ? General UDP floods >> ? General TCP floods" >> >> >> >> >> Best Regards, >> >> Guillaume FORTAINE >> >> > From charles at knownelement.com Wed Mar 17 13:15:36 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 17 Mar 2010 11:15:36 -0700 Subject: anti-ddos test solutions ? In-Reply-To: <1268817124.2479.3.camel@localhost> References: <4BA07A6F.4010104@yahoo.fr> <1268817124.2479.3.camel@localhost> Message-ID: <4BA11C48.6000506@knownelement.com> bit gossip wrote: > Nessus is a vulnerability scanner: > > http://www.nessus.org/nessus/ > > Ixia provides a full Nessus implementation in one of its platform. > Well these days I would use http://www.openvas.org and http://www.metasploit.org for vulnerability scanning and analysis. However that wouldn't be a DDoS, but could certainly lead to DOS. From charles at knownelement.com Wed Mar 17 13:18:07 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 17 Mar 2010 11:18:07 -0700 Subject: anti-ddos test solutions ? In-Reply-To: <11A32E77-458E-4D88-BEA7-7464922917F0@daork.net> References: <4BA07A6F.4010104@yahoo.fr> <1268817124.2479.3.camel@localhost> <11A32E77-458E-4D88-BEA7-7464922917F0@daork.net> Message-ID: <4BA11CDF.3020201@knownelement.com> Nathan Ward wrote: > Hire/buy what I know as a router tester. People call them different things. > It's a device that generates packets, Linux has a packet generator in the kernel as well. More info readily available from your local search engine. > and can normally simulate TCP etc. all the way up to HTTP etc. or higher. BGP, OSPF, MPLS, etc. etc. etc. > Hmmm. What about a fuzzer, or something like scapy? > Tell it to generate packets that look like they come from many many hosts (you can normally simulate some kind of network topology with hosts in different places and hence different TTLs etc.), and viola. > They normally let you generate background noise traffic, or you could record 24 hours of packet headers from somewhere in your network and play it back through your test network. This needs a lot of disk of course. > tcpreplay is great for that. From sfouant at shortestpathfirst.net Wed Mar 17 13:24:18 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 17 Mar 2010 12:24:18 -0600 Subject: anti-ddos test solutions ? In-Reply-To: <4BA10AA5.3070502@matthew.at> References: , <003101cac5ea$0327a770$0976f650$@net>, <002801cac5ee$c4af94d0$4e0ebe70$@org> <4BA10AA5.3070502@matthew.at> Message-ID: <004f01cac5ff$0fa2a490$2ee7edb0$@net> > -----Original Message----- > From: Matthew Kaufman [mailto:matthew at matthew.at] > Sent: Wednesday, March 17, 2010 11:00 AM > > Don't you just set up an IRC server and then say something inflammatory > to the wrong person? You can always get DNS hosting from Ultra. You're apt to experience some noise in that scenario too ;) Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From sfouant at shortestpathfirst.net Wed Mar 17 13:28:03 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Wed, 17 Mar 2010 12:28:03 -0600 Subject: anti-ddos test solutions ? In-Reply-To: <4BA11C48.6000506@knownelement.com> References: <4BA07A6F.4010104@yahoo.fr> <1268817124.2479.3.camel@localhost> <4BA11C48.6000506@knownelement.com> Message-ID: <005001cac5ff$96a55370$c3effa50$@net> > -----Original Message----- > From: Charles N Wyble [mailto:charles at knownelement.com] > Sent: Wednesday, March 17, 2010 12:16 PM > To: nanog at nanog.org > Subject: Re: anti-ddos test solutions ? > > bit gossip wrote: > > Nessus is a vulnerability scanner: > > > > http://www.nessus.org/nessus/ > > > > Ixia provides a full Nessus implementation in one of its platform. > > > > Well these days I would use http://www.openvas.org and > http://www.metasploit.org > for vulnerability scanning and analysis. > > However that wouldn't be a DDoS, but could certainly lead to DOS. If you can get your hands on a PCAP from a previous attack, you could also use something like Bit-Twist which will allow you to manipulate things like the destination IP and also the transmission rate, etc. Pretty useful tool to include in the DDoS simulation toolbox. http://bittwist.sourceforge.net/ Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From nathan at stonekitty.net Wed Mar 17 13:51:47 2010 From: nathan at stonekitty.net (Nathan) Date: Wed, 17 Mar 2010 11:51:47 -0700 Subject: AARNet AS7575 announcing 1.0.0.0/24, 1.1.1.0/24 and 1.2.3.0/24 soon In-Reply-To: <20100317102544.GQ26650@cthulhu.oldones.net> References: <02C6A2BA-3600-4F07-B52C-2800FDDF54A7@apnic.net> <292AF25E62B8894C921B893B53A19D973974B77ED8@BUSINESSEX.business.ad> <3E93606B-4F3B-4629-9710-94210AE0C7D9@daork.net> <20100317102544.GQ26650@cthulhu.oldones.net> Message-ID: 1.0.0.0/8 has been fun. I wont steal George/Geoff's show by telling all... but I will state that about 18% of the internet is still bogon filtering (or using internally) 1.x... I wouldn't want to be a poor schlub getting assigned something from this space, personally. We're going to announce 27.128.0.0/12 in the next 24 hours as well... To see what backscatter is like in an uninteresting range. I'll send a separate clear message to the list about this too. :) ,N On Wed, Mar 17, 2010 at 3:25 AM, Peter van Arkel wrote: > On Wed, 17 Mar 2010, Nathan Ward wrote: > >> route-views>sh ip bgp 1.0.0.0/8 >> BGP routing table entry for 1.0.0.0/8, version 600951180 >> Paths: (24 available, no best path) >> Flag: 0x820 >> ? Not advertised to any peer >> ? 1239 174 36561 >> ? ? 144.228.241.130 (inaccessible) from 144.228.241.130 (144.228.241.130) >> ? ? ? Origin IGP, localpref 100, valid, external >> >> % whois -a AS36561 | grep -i name >> OrgName: ? ?YouTube, Inc. > > http://www.merit.edu/mail.archives/nanog/msg06402.html > > "Accordingly, APNIC authorizes AS36351 to periodically advertise a > route for 1.0.0.0/8 from now until 21 March 2010, and > requests that AS36351's peers and upstreams accept this as a > legitimate routing advertisement." > > :-) > > -- > Peter van Arkel > ?T: +31 623988844 ? ? ? ? ? ? ? ? ? ? ? | p.vanarkel at gmail.com > ?RIPE: PvA63-RIPE ? ? ? ? ? ? ? ? ? ? ? | PGP: 0xA0991D6B > > From tchristell at springnet.net Wed Mar 17 13:58:26 2010 From: tchristell at springnet.net (Todd Christell) Date: Wed, 17 Mar 2010 13:58:26 -0500 Subject: IPv6 in Education Question Message-ID: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So Im giving an introductory talk on IPv6 for a state wide conference for tech coordinators for education. I have the usual catechism of reasons/advantages from the network side but was wondering if there were any good education specific applications of v6. My major goal is to help them understand the situation so that they can make use of the base of educators in our state to help spread the work about IPv6. Thanks in advance, Todd Todd Christell Manager Network Architecture and Support www.springnet.net 417.831.8688 Key fingerprint = 4F26 A0B4 5AAD 7FCA 48DD 7F40 A57E 9235 5202 D508 -----BEGIN PGP SIGNATURE----- Version: 10.0.1 (Build 4020) Charset: iso-8859-1 wj8DBQFLoSZ1pX6SNVIC1QgRAubmAJ9jCx38cd+jEq3tUYwabyC/o/W2DgCaArb7 7BwL9r8E27sGhO2x394FgYE= =6CqS -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: Christell Todd.vcf Type: text/x-vcard Size: 548 bytes Desc: Christell Todd.vcf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Christell Todd.vcf.sig Type: application/octet-stream Size: 191 bytes Desc: Christell Todd.vcf.sig URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGPexch.htm.pgp Type: application/octet-stream Size: 2117 bytes Desc: PGPexch.htm.pgp URL: From nathan at youtube.com Wed Mar 17 14:09:16 2010 From: nathan at youtube.com (Nathan Hickson) Date: Wed, 17 Mar 2010 12:09:16 -0700 Subject: AS36561 to announce 27.128.0.0/12 Message-ID: <27a54a111003171209x5a585338l122592763d124b20@mail.gmail.com> Similar to the 1.0.0.0/8 experiment... YouTube (only AS36561) will be announcing 27.128.0.0/12 to allow APNIC to study backscatter/traffic to this unallocated space in ipv4 land. We'll start in the next 24 hours. This range is obviously less interesting than 1.x, but figured I'd let you all know anyway. :) Cheers. -- Nathan Hickson AS36561 - YouTube AS15169 - Google From brandon.kim at brandontek.com Wed Mar 17 14:27:31 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 17 Mar 2010 15:27:31 -0400 Subject: IPv6 in Education Question In-Reply-To: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> Message-ID: Will your presentation viewed anywhere like youtube? I'd like to hear or see it..... > From: tchristell at springnet.net > To: nanog at nanog.org > Date: Wed, 17 Mar 2010 13:58:26 -0500 > Subject: IPv6 in Education Question > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So Im giving an introductory talk on IPv6 for a state wide conference for tech coordinators for education. I have the usual catechism of reasons/advantages from the network side but was wondering if there were any good education specific applications of v6. My major goal is to help them understand the situation so that they can make use of the base of educators in our state to help spread the work about IPv6. > > > > Thanks in advance, > > > > Todd > > > > Todd Christell > > Manager Network Architecture and Support > > www.springnet.net > > 417.831.8688 > > > > Key fingerprint = 4F26 A0B4 5AAD 7FCA 48DD 7F40 A57E 9235 5202 D508 > > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: 10.0.1 (Build 4020) > Charset: iso-8859-1 > > wj8DBQFLoSZ1pX6SNVIC1QgRAubmAJ9jCx38cd+jEq3tUYwabyC/o/W2DgCaArb7 > 7BwL9r8E27sGhO2x394FgYE= > =6CqS > -----END PGP SIGNATURE----- > > From alex at blastro.com Wed Mar 17 14:29:13 2010 From: alex at blastro.com (Alex Thurlow) Date: Wed, 17 Mar 2010 14:29:13 -0500 Subject: Intermittent Google issues in Austin area Message-ID: <4BA12D89.1000301@blastro.com> Anyone else having intermittent issues connecting to google servers from the Austin area? I first noticed google.com/jsapi loading slowly to slow down my website from loading, and I've since seen other sites loading from their ajaxapis and even www.google.com's search results taking upwards of 30 seconds to load. Many times it loads fine, and then it won't. I couldn't find a place to submit this to them, so I thought I'd check with you guys. -Alex From ray.sanders at villagevoicemedia.com Wed Mar 17 14:44:39 2010 From: ray.sanders at villagevoicemedia.com (Ray Sanders) Date: Wed, 17 Mar 2010 12:44:39 -0700 Subject: Intermittent Google issues in Austin area In-Reply-To: <4BA12D89.1000301@blastro.com> References: <4BA12D89.1000301@blastro.com> Message-ID: <4BA13127.8030108@villagevoicemedia.com> I was seeing a ton of issues with Google services here in Phoenix earlier this morning. Seemed to clear up by about 9 AM local time. Alex Thurlow wrote: > Anyone else having intermittent issues connecting to google servers > from the Austin area? I first noticed google.com/jsapi loading slowly > to slow down my website from loading, and I've since seen other sites > loading from their ajaxapis and even www.google.com's search results > taking upwards of 30 seconds to load. Many times it loads fine, and > then it won't. I couldn't find a place to submit this to them, so I > thought I'd check with you guys. > > -Alex > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2752 - Release Date: 03/17/10 00:33:00 > > -- -"Prediction is very difficult, especially about the future." -Niels Bohr -- Ray Sanders Linux Administrator Village Voice Media Office: 602-744-6547 Cell: 602-300-4344 From jna at retina.net Wed Mar 17 14:44:40 2010 From: jna at retina.net (John Adams) Date: Wed, 17 Mar 2010 14:44:40 -0500 Subject: Intermittent Google issues in Austin area In-Reply-To: <4BA12D89.1000301@blastro.com> References: <4BA12D89.1000301@blastro.com> Message-ID: <8B336DC9-6D32-4453-9B39-4A4C0573B187@retina.net> No problems getting to google from here, but SxSW is under way and there will be lots of traffic from the 15,000+ attendees. -j (in the midst of sxsw, on 6th St, Austin) Sent from my iPhone On Mar 17, 2010, at 14:29, Alex Thurlow wrote: > Anyone else having intermittent issues connecting to google servers > from the Austin area? I first noticed google.com/jsapi loading > slowly to slow down my website from loading, and I've since seen > other sites loading from their ajaxapis and even www.google.com's > search results taking upwards of 30 seconds to load. Many times it > loads fine, and then it won't. I couldn't find a place to submit > this to them, so I thought I'd check with you guys. > > -Alex > > From jmamodio at gmail.com Wed Mar 17 14:48:59 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 17 Mar 2010 13:48:59 -0600 Subject: Intermittent Google issues in Austin area In-Reply-To: <4BA12D89.1000301@blastro.com> References: <4BA12D89.1000301@blastro.com> Message-ID: <202705b1003171248m5f6c8450q958d5a97f41f9274@mail.gmail.com> No issues 60 miles south (SATX) On Wed, Mar 17, 2010 at 1:29 PM, Alex Thurlow wrote: > Anyone else having intermittent issues connecting to google servers from the > Austin area? I first noticed google.com/jsapi loading slowly to slow down my > website from loading, and I've since seen other sites loading from their > ajaxapis and even www.google.com's search results taking upwards of 30 > seconds to load. ?Many times it loads fine, and then it won't. ?I couldn't > find a place to submit this to them, so I thought I'd check with you guys. > > ? ?-Alex From tchristell at springnet.net Wed Mar 17 15:00:51 2010 From: tchristell at springnet.net (Todd Christell) Date: Wed, 17 Mar 2010 15:00:51 -0500 Subject: IPv6 in Education Question In-Reply-To: References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> Message-ID: <97487AA41962C74E83D8ABABD2A90A4905A2C8139C@mail.springnet.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't know what their plans are but I'm NOT very photogenic... It is really a very basic introduction as the audience will have varied experience levels. Current IPv4 addresses, their exhaustion and why NAT is evil. Intro to the structure of an IPv6 address, beginning subnetting, getting a handle around how huge the numbers are, and why NAT64 is evil. Transition mechanisms and the inherent problems. Mostly trying to continue a grass roots effort to get things moving. When I talk to up streams and hardware vendors all I hear is "We aren't getting many requests for v6." So I'm trying to change that by stirring the masses to push IPv6 requirements to the parties in question. Technically accurate, but something that they all can relate to and take home with them. That's mainly why I was looking for a few cool education-centric ideas to help instill some ownership. Todd Todd Christell Manager Network Architecture and Support www.springnet.net 417.831.8688 Key fingerprint = 4F26 A0B4 5AAD 7FCA 48DD 7F40 A57E 9235 5202 D508 - -----Original Message----- From: Brandon Kim [mailto:brandon.kim at brandontek.com] Sent: Wednesday, March 17, 2010 2:28 PM To: nanog at nanog.org Subject: RE: IPv6 in Education Question Will your presentation viewed anywhere like youtube? I'd like to hear or see it..... > From: tchristell at springnet.net > To: nanog at nanog.org > Date: Wed, 17 Mar 2010 13:58:26 -0500 > Subject: IPv6 in Education Question > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So Im giving an introductory talk on IPv6 for a state wide conference for tech coordinators for education. I have the usual catechism of reasons/advantages from the network side but was wondering if there were any good education specific applications of v6. My major goal is to help them understand the situation so that they can make use of the base of educators in our state to help spread the work about IPv6. > > > > Thanks in advance, > > > > Todd > > > > Todd Christell > > Manager Network Architecture and Support > > www.springnet.net > > 417.831.8688 > > > > Key fingerprint = 4F26 A0B4 5AAD 7FCA 48DD 7F40 A57E 9235 5202 D508 > > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: 10.0.1 (Build 4020) > Charset: iso-8859-1 > > wj8DBQFLoSZ1pX6SNVIC1QgRAubmAJ9jCx38cd+jEq3tUYwabyC/o/W2DgCaArb7 > 7BwL9r8E27sGhO2x394FgYE= > =6CqS > -----END PGP SIGNATURE----- > > No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.791 / Virus Database: 271.1.1/2752 - Release Date: 03/17/10 02:33:00 -----BEGIN PGP SIGNATURE----- Version: 10.0.1 (Build 4020) Charset: utf-8 wj8DBQFLoTUVpX6SNVIC1QgRAm+0AJoCiG0gVHo0E/Fnbg/UYxnEhtSKQgCeNqHn B7aK6H4+IXA/QsWT/sIyYuo= =qK3A -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: Christell Todd.vcf Type: text/x-vcard Size: 548 bytes Desc: Christell Todd.vcf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Christell Todd.vcf.sig Type: application/octet-stream Size: 191 bytes Desc: Christell Todd.vcf.sig URL: From lists at quux.de Wed Mar 17 15:20:11 2010 From: lists at quux.de (Jens Link) Date: Wed, 17 Mar 2010 21:20:11 +0100 Subject: IPv6 in Education Question In-Reply-To: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> (Todd Christell's message of "Wed, 17 Mar 2010 13:58:26 -0500") References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> Message-ID: <87k4tavgxw.fsf@laphroiag.quux.de> Todd Christell writes: > So Im giving an introductory talk on IPv6 for a state wide conference > for tech coordinators for education. I have the usual catechism of > reasons/advantages from the network side but was wondering if there were > any good education specific applications of v6. My major goal is to > help them understand the situation so that they can make use of the base > of educators in our state to help spread the work about IPv6. It's not a question of if but when IPv6 will be used on large scale in the interned. So, form the educational side it's beneficial if students learn about IPv6. So much for the theory I did quite a number of presentations on IPv6 some of them in at university in Germany (not as some official talk but some user group / some students asked me too). Some quotes: "We don't' have time for this." "Well our network equipment is 14 years old, we don't have a budget for new stuff." "We'll implement IPv6 in 13 years, it's when my colleague retires." /me: "Cool. You have IPv6." Professor: "I configured the tunnel myself. Our network people don't this the topic." Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From tshortal at umd.edu Wed Mar 17 15:23:43 2010 From: tshortal at umd.edu (Timothy Shortall) Date: Wed, 17 Mar 2010 16:23:43 -0400 Subject: Intermittent Google issues in Austin area Message-ID: Alex Thurlow wrote: Anyone else having intermittent issues connecting to google servers from the Austin area? I first noticed google.com/jsapi loading slowly to slow down my website from loading, and I've since seen other sites loading from their ajaxapis and even www.google.com's search results taking upwards of 30 seconds to load. Many times it loads fine, and then it won't. I couldn't find a place to submit this to them, so I thought I'd check with you guys. -Alex From tshortal at umd.edu Wed Mar 17 15:33:42 2010 From: tshortal at umd.edu (Timothy Shortall) Date: Wed, 17 Mar 2010 16:33:42 -0400 Subject: Intermittent Google issues in Austin area Message-ID: Alex Thurlow wrote: Anyone else having intermittent issues connecting to google servers from the Austin area? I first noticed google.com/jsapi loading slowly to slow down my website from loading, and I've since seen other sites loading from their ajaxapis and even www.google.com's search results taking upwards of 30 seconds to load. Many times it loads fine, and then it won't. I couldn't find a place to submit this to them, so I thought I'd check with you guys. -Alex From tshortal at umd.edu Wed Mar 17 15:35:56 2010 From: tshortal at umd.edu (Timothy Shortall) Date: Wed, 17 Mar 2010 16:35:56 -0400 Subject: Intermittent Google issues in Austin area Message-ID: Jorge Amodio wrote: No issues 60 miles south (SATX) On Wed, Mar 17, 2010 at 1:29 PM, Alex Thurlow wrote: > Anyone else having intermittent issues connecting to google servers from the > Austin area? I first noticed google.com/jsapi loading slowly to slow down my > website from loading, and I've since seen other sites loading from their > ajaxapis and even www.google.com's search results taking upwards of 30 > seconds to load. Many times it loads fine, and then it won't. I couldn't > find a place to submit this to them, so I thought I'd check with you guys. > > -Alex From brandon.kim at brandontek.com Wed Mar 17 15:36:32 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 17 Mar 2010 16:36:32 -0400 Subject: IPv6 in Education Question In-Reply-To: <97487AA41962C74E83D8ABABD2A90A4905A2C8139C@mail.springnet.local> References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local>, , <97487AA41962C74E83D8ABABD2A90A4905A2C8139C@mail.springnet.local> Message-ID: Todd, I'm sending you a link from something I blogged about on my site regarding IPv6. I'll send it offline so others don't think I'm spamming the list... From: tchristell at springnet.net To: brandon.kim at brandontek.com; nanog at nanog.org Date: Wed, 17 Mar 2010 15:00:51 -0500 Subject: RE: IPv6 in Education Question -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't know what their plans are but I'm NOT very photogenic... It is really a very basic introduction as the audience will have varied experience levels. Current IPv4 addresses, their exhaustion and why NAT is evil. Intro to the structure of an IPv6 address, beginning subnetting, getting a handle around how huge the numbers are, and why NAT64 is evil. Transition mechanisms and the inherent problems. Mostly trying to continue a grass roots effort to get things moving. When I talk to up streams and hardware vendors all I hear is "We aren't getting many requests for v6." So I'm trying to change that by stirring the masses to push IPv6 requirements to the parties in question. Technically accurate, but something that they all can relate to and take home with them. That's mainly why I was looking for a few cool education-centric ideas to help instill some ownership. Todd Todd Christell Manager Network Architecture and Support www.springnet.net 417.831.8688 Key fingerprint = 4F26 A0B4 5AAD 7FCA 48DD 7F40 A57E 9235 5202 D508 - -----Original Message----- From: Brandon Kim [mailto:brandon.kim at brandontek.com] Sent: Wednesday, March 17, 2010 2:28 PM To: nanog at nanog.org Subject: RE: IPv6 in Education Question Will your presentation viewed anywhere like youtube? I'd like to hear or see it..... > From: tchristell at springnet.net > To: nanog at nanog.org > Date: Wed, 17 Mar 2010 13:58:26 -0500 > Subject: IPv6 in Education Question > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So Im giving an introductory talk on IPv6 for a state wide conference for tech coordinators for education. I have the usual catechism of reasons/advantages from the network side but was wondering if there were any good education specific applications of v6. My major goal is to help them understand the situation so that they can make use of the base of educators in our state to help spread the work about IPv6. > > > > Thanks in advance, > > > > Todd > > > > Todd Christell > > Manager Network Architecture and Support > > www.springnet.net > > 417.831.8688 > > > > Key fingerprint = 4F26 A0B4 5AAD 7FCA 48DD 7F40 A57E 9235 5202 D508 > > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: 10.0.1 (Build 4020) > Charset: iso-8859-1 > > wj8DBQFLoSZ1pX6SNVIC1QgRAubmAJ9jCx38cd+jEq3tUYwabyC/o/W2DgCaArb7 > 7BwL9r8E27sGhO2x394FgYE= > =6CqS > -----END PGP SIGNATURE----- > > No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.791 / Virus Database: 271.1.1/2752 - Release Date: 03/17/10 02:33:00 -----BEGIN PGP SIGNATURE----- Version: 10.0.1 (Build 4020) Charset: utf-8 wj8DBQFLoTUVpX6SNVIC1QgRAm+0AJoCiG0gVHo0E/Fnbg/UYxnEhtSKQgCeNqHn B7aK6H4+IXA/QsWT/sIyYuo= =qK3A -----END PGP SIGNATURE----- From brandon.kim at brandontek.com Wed Mar 17 15:40:59 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 17 Mar 2010 16:40:59 -0400 Subject: IPv6 in Education Question In-Reply-To: <87k4tavgxw.fsf@laphroiag.quux.de> References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local>, <87k4tavgxw.fsf@laphroiag.quux.de> Message-ID: Jens: There some ISP's trying to push IPv6. Probably not until the masses really demand it in someway. Or if Google pushes it or some well known company. Perhaps maybe an application that is IPv6 specific.... NAT's and transition protocols seems to extend the life of IPv4. I'm not against them though, they have served us well....hard to let go of things that worked for you for so many years.... > From: lists at quux.de > To: nanog at nanog.org > Subject: Re: IPv6 in Education Question > Date: Wed, 17 Mar 2010 21:20:11 +0100 > > Todd Christell writes: > > > So Im giving an introductory talk on IPv6 for a state wide conference > > for tech coordinators for education. I have the usual catechism of > > reasons/advantages from the network side but was wondering if there were > > any good education specific applications of v6. My major goal is to > > help them understand the situation so that they can make use of the base > > of educators in our state to help spread the work about IPv6. > > It's not a question of if but when IPv6 will be used on large scale in > the interned. So, form the educational side it's beneficial if students > learn about IPv6. > > So much for the theory > > I did quite a number of presentations on IPv6 some of them in at > university in Germany (not as some official talk but some user group / > some students asked me too). Some quotes: > > "We don't' have time for this." > > "Well our network equipment is 14 years old, we don't have a budget for > new stuff." > > "We'll implement IPv6 in 13 years, it's when my colleague retires." > > /me: "Cool. You have IPv6." > Professor: "I configured the tunnel myself. Our network people don't this the > topic." > > Jens > -- > ------------------------------------------------------------------------- > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | > | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | > ------------------------------------------------------------------------- > From tshortal at umd.edu Wed Mar 17 15:42:16 2010 From: tshortal at umd.edu (Timothy Shortall) Date: Wed, 17 Mar 2010 16:42:16 -0400 Subject: IPv6 in Education Question Message-ID: <2ypspk9rfg1ttusx69wxxgpa.1268858548936@email.android.com> Jens Link wrote: Todd Christell writes: > So Im giving an introductory talk on IPv6 for a state wide conference > for tech coordinators for education. I have the usual catechism of > reasons/advantages from the network side but was wondering if there were > any good education specific applications of v6. My major goal is to > help them understand the situation so that they can make use of the base > of educators in our state to help spread the work about IPv6. It's not a question of if but when IPv6 will be used on large scale in the interned. So, form the educational side it's beneficial if students learn about IPv6. So much for the theory I did quite a number of presentations on IPv6 some of them in at university in Germany (not as some official talk but some user group / some students asked me too). Some quotes: "We don't' have time for this." "Well our network equipment is 14 years old, we don't have a budget for new stuff." "We'll implement IPv6 in 13 years, it's when my colleague retires." /me: "Cool. You have IPv6." Professor: "I configured the tunnel myself. Our network people don't this the topic." Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From blake at beamspeed.com Wed Mar 17 16:08:24 2010 From: blake at beamspeed.com (Blake Covarrubias) Date: Wed, 17 Mar 2010 14:08:24 -0700 Subject: ISC DHCP server failover In-Reply-To: <20100317142206.GB4773@dan.olp.net> References: <20100317142206.GB4773@dan.olp.net> Message-ID: <6F26487F-E302-4FC3-A8E5-6CC9EDCA2D0E@beamspeed.com> On Mar 17, 2010, at 7:22 AM, Dan White wrote: > We've experienced two types of problems from time to time: > > The servers stop balancing their addresses, and one server starts to > exhibit 'peer holds all free leases' in its logs, in which case we need to > restart the dhcpd process(es) to force a rebalance. We experience this problem from time to time as well, and I have yet to find its cause. We also 'fix' it by restarting the dhcpd daemon. > > In some cases, and I'm not sure which equipment may be to blame, if one > server goes down then the other server will not hand out addresses to > clients which had originally received addresses from the failed server. > We've dealt with that by balancing our lease times with our MTTR for a > failed server. From the dhcpd.conf man page it seems the solution to this problem is to put the remaining active server into the PARTNER-DOWN state. Aside from the 'peer holds all free leases' error Dan mentioned, ISC DHCP's load balancing and failover has worked very well for us. -- Blake Covarrubias From joe.abley at icann.org Wed Mar 17 16:51:26 2010 From: joe.abley at icann.org (Joe Abley) Date: Wed, 17 Mar 2010 14:51:26 -0700 Subject: Signing of the ARPA zone Message-ID: <52EF417B-49FA-43DA-BD6B-8E6F3C527074@icann.org> Colleagues, This is a follow-up to the operational announcement regarding changes to the ARPA top-level domain that was sent on 2010-03-10. Apologies in advance for duplicates received through different mailing lists. As of 2010-03-17 1630 UTC all the authoritative servers for ARPA are serving a signed ARPA zone. We would like to solicit feedback from the technical community to allow us to identify any operational ill-effects that this change has caused. We will monitor this mailing list for feedback, and I will also distribute any feedback sent to me personally so that it can be considered. If no harmful effects have been identified by 2010-03-21 the trust anchor for the ARPA zone will be published through the IANA ITAR at . Regards, Joe Begin forwarded message: > From: Joe Abley > Date: 10 March 2010 16:13:46 EST > To: Joe Abley > Subject: Signing of the ARPA zone > > Colleagues, > > This is a technical, operational announcement regarding changes to the ARPA top-level domain. Apologies in advance for duplicates received through different mailing lists. > > No specific action is requested of operators. This message is for your information only. > > The ARPA zone is about to be signed using DNSSEC. The technical parameters by which ARPA will be signed are as follows: > > KSK Algorithm and Size: 2048 bit RSA > KSK Rollover: every 2-5 years, scheduled rollover to follow RFC 5011 > KSK Signature Algorithm: SHA-256 > Validity period for signatures made with KSK: 15 days; new signatures published every 10 days > ZSK Algorithm and Size: 1024 bit RSA > ZSK Rollover: every 3 months > ZSK Signature Algorithm: SHA-256 > Authenticated proof of non-existence: NSEC > Validity period for signatures made with ZSK: 7 days; zone generated and re-signed twice per day > > The twelve root server operators [1] will begin to serve a signed ARPA zone instead of the (current) unsigned ARPA zone during a maintenance window which will open at 2010-03-15 0001 UTC and close at 2010-03-17 2359 UTC. Individual root server operators will carry out their maintenance at times within that window according to their own operational preference. > > The trust anchor for the ARPA zone will be published in the ITAR [2], and in the root zone in the form of a DS record once the root zone is signed. > > If you have any concerns or require further information, please let me know. > > Regards, > > > Joe Abley > Director DNS Operations, ICANN > > [1] > [2] From moreiras at nic.br Wed Mar 17 16:53:13 2010 From: moreiras at nic.br (Antonio M. Moreiras) Date: Wed, 17 Mar 2010 18:53:13 -0300 Subject: IPv6 in Education Question In-Reply-To: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> Message-ID: <4BA14F49.9000100@nic.br> It is such a great opportunity. I had chance to give similar speeches in Brazil last year, and choosed to stress the following topics, besides the basic catechism: - IPv6 is inevitable, it is already part of Internet, and will be fully deployed in few years. Its deploying is slow, but the momentum is increasing; - Universities had an important role in IPv6 development some years ago, and should be leading this process now, but they are not; - It is very important to the Internet, that the network engineers learn about IPv6, and use IPv6, inside universities and schools... - Universities could help the national industry to adopt IPv6 in their products, to secure the current market, or to conquer new ones. []s Moreiras Em 17-03-2010 15:58, Todd Christell escreveu: > So Im giving an introductory talk on IPv6 for a state wide conference for tech coordinators for education. I have the usual catechism of reasons/advantages from the network side but was wondering if there were any good education specific applications of v6. My major goal is to help them understand the situation so that they can make use of the base of educators in our state to help spread the work about IPv6. > > > Thanks in advance, > From bpenglase-nanog at SpaceServices.net Wed Mar 17 17:14:32 2010 From: bpenglase-nanog at SpaceServices.net (Brandon Penglase) Date: Wed, 17 Mar 2010 18:14:32 -0400 Subject: IPv6 in Education Question In-Reply-To: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> Message-ID: <20100317181432.31459395@Nereus.wlmsprt.pa.neltia.net> Todd, Cisco is offering a 4 part series of Webcasts about IPv6 for Education. I've watched the first two, and they haven't really been too vendor specific, but some of it has been insightful, especially from an Education standpoint. The first two are up on the web, and the last two are coming, March 30th and April 13th. These last two are on Security and Unified Communications, which may not be as vital to your talk. If you (or anyone else) would like a link to the registration for all of these, hit me off list, as I wasn't sure if it would be considered spamming or not. Brandon Penglase On Wed, 17 Mar 2010 13:58:26 -0500 Todd Christell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So Im giving an introductory talk on IPv6 for a state wide conference > for tech coordinators for education. I have the usual catechism of > reasons/advantages from the network side but was wondering if there > were any good education specific applications of v6. My major goal > is to help them understand the situation so that they can make use of > the base of educators in our state to help spread the work about IPv6. > > > > Thanks in advance, > > > > Todd > > > > Todd Christell > > Manager Network Architecture and Support > > www.springnet.net > > 417.831.8688 > > > > Key fingerprint = 4F26 A0B4 5AAD 7FCA 48DD 7F40 A57E 9235 5202 D508 > > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: 10.0.1 (Build 4020) > Charset: iso-8859-1 > > wj8DBQFLoSZ1pX6SNVIC1QgRAubmAJ9jCx38cd+jEq3tUYwabyC/o/W2DgCaArb7 > 7BwL9r8E27sGhO2x394FgYE= > =6CqS > -----END PGP SIGNATURE----- > > From raymond at prolocation.net Wed Mar 17 17:49:01 2010 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Wed, 17 Mar 2010 23:49:01 +0100 (CET) Subject: ISC DHCP server failover In-Reply-To: References: Message-ID: Hi! > I am wondering if anyone has implemented the failover features of ISC > DHCP? And if so, how successful has failover been in your environment? We run it on various locations and this works pretty well. Student dormitory's, and so on. Bye, Raymond. From mike.lyon at gmail.com Wed Mar 17 18:08:03 2010 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 17 Mar 2010 16:08:03 -0700 Subject: Recommendations for reverse DNS providers Message-ID: <1b5c1c151003171608s45e9b64eg8095b5053a39ff62@mail.gmail.com> Hello, I am curious what folks recommend these days for reverse DNS providers? UltraDNS? FreeDNS? Thank You, Mike From ghicks at hicks-net.net Wed Mar 17 18:11:24 2010 From: ghicks at hicks-net.net (Gregory Hicks) Date: Wed, 17 Mar 2010 16:11:24 -0700 (PDT) Subject: Recommendations for reverse DNS providers Message-ID: <201003172311.o2HNBOLl025213@metis.hicks-net.net> > Date: Wed, 17 Mar 2010 16:08:03 -0700 > From: Mike Lyon > > Hello, > > I am curious what folks recommend these days for reverse DNS > providers? UltraDNS? FreeDNS? BIND No difference between a forward and reverse zone to BIND. Both work well... > > Thank You, > Mike --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton From bruns at 2mbit.com Wed Mar 17 18:19:18 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 17 Mar 2010 23:19:18 +0000 Subject: Recommendations for reverse DNS providers Message-ID: <654498074-1268868010-cardhu_decombobulator_blackberry.rim.net-1691366242-@bda895.bisx.prod.on.blackberry> Same general practices for forward dns apply to reverse as well - you should have a secondary on a separate netblock/provider/connection from the master nameserver. Also depends on what's going to be on the netblocks your hosting rdns for. If its a bunch of mail servers, rdns is kinda important from an anti-abuse perspective. Same with dynamic clients. ------Original Message------ From: Gregory Hicks To: nanog at nanog.org To: mike.lyon at gmail.com ReplyTo: Gregory Hicks Subject: Re: Recommendations for reverse DNS providers Sent: Mar 17, 2010 5:11 PM > Date: Wed, 17 Mar 2010 16:08:03 -0700 > From: Mike Lyon > > Hello, > > I am curious what folks recommend these days for reverse DNS > providers? UltraDNS? FreeDNS? BIND No difference between a forward and reverse zone to BIND. Both work well... > > Thank You, > Mike --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From kauer at biplane.com.au Wed Mar 17 18:21:02 2010 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 18 Mar 2010 10:21:02 +1100 Subject: IPv6 in Education Question In-Reply-To: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> Message-ID: <1268868062.5727.652.camel@karl> On Wed, 2010-03-17 at 13:58 -0500, Todd Christell wrote: > So Im giving an introductory talk on IPv6 for a state wide conference > for tech coordinators for education. I have the usual catechism of > reasons/advantages from the network side but was wondering if there > were any good education specific applications of v6. If implemented properly (i.e., not by using IPv6 to fake all the properties of IPv4, as so many people seem bound and determined to do), then there are several characteristics of IPv6 networks that are of educational interest, though nothing in the protocol is education-specific. First and foremost is that IPv6 is simpler and thus cheaper. Easier to build networks, merge them, expand them, contract them, split them. Every subnet is the right size - no more slicing and dicing subnets, endlessly rearranging too few addresses in new configurations. Design costs go down, admin costs go down, management costs go down, equipment costs go down. Because IPv6 is simpler, security is by definition better and cheaper. Education being perennially penurious, all this has got to be interesting! IPv6 is easier to teach than IPv4. It doesn't have as many edge cases and entrenched workarounds, the notation is cleaner, the protocols are cleaner, and the same set of protocol tools (multicast, ICMPv6, ND etc) is used more consistently. End-to-end transparency means that IPv6 supports peer to peer naturally. That means everyone (students, teachers, parents etc) can talk to each other more easily without having to involve third parties, and can talk to each other from anywhere on the globe. Less mediation, more direct, more distributed. The death of NAT will mean that more and more stuff will be hosted locally - on teaching machines, student laptops, home PCs, mobile phones. I think we will see fragmentation and distribution of things that are now monolithic. Things like Facebook, Twitter, MySpace and so on will be reduced to special purpose indexing services - or will die. Why use them when you can have all your stuff on your mobile phone, accessible 24/7, wherever you are? I'm not sure about the future of VPNs. Mobile IPv6 is effectively a global, standardised, very low-cost, built-in VPN. Students can be inside the school network from home, on the road, overseas.... without special infrastructure outside the home network. So I'd expect to see IPv6 change the face of educational IT - but it will change the face of IT everywhere. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From r.gelobter at limestonenetworks.com Wed Mar 17 18:28:57 2010 From: r.gelobter at limestonenetworks.com (Ryan Gelobter) Date: Wed, 17 Mar 2010 18:28:57 -0500 Subject: IPv6 enabled carriers? In-Reply-To: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> References: <607f1e0a1003101100g4ce6cf8by47c079a586ff3084@mail.gmail.com> Message-ID: <216636937ABE004E8CD94DDB2AD8BAA50190C8FAC37E@lsnexchange.limestonenetworks.com> NTT offers IPv6 Ryan G Limestone Networks, Inc. www.limestonenetworks.com Simple.? Solid.? Superior. -----Original Message----- From: Charles Mills [mailto:w3yni1 at gmail.com] Sent: Wednesday, March 10, 2010 1:01 PM To: NANOG list Subject: IPv6 enabled carriers? Does anyone have a list of carriers who are IPv6 capable today? I would assume this would be rolled out in larger cities first but anything outside of "testbed environments" and "trials" as in Comcast's recent announcement seems to be all that is available. I'm being tasked with coming up with an IPv6 migration plan for a data center. Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business and Qwest are capable as those are the typical ones I deal with. Thanks...Chuck From nathan at youtube.com Wed Mar 17 18:46:49 2010 From: nathan at youtube.com (Nathan Hickson) Date: Wed, 17 Mar 2010 16:46:49 -0700 Subject: Youtube CSIRT - Backbone Security : Runtime Monitoring and Dynamic Reconfiguration for Intrusion Detection Systems In-Reply-To: <7f35cc71003171617u7890895cm295961d865b7bf7d@mail.gmail.com> References: <7f35cc71003171617u7890895cm295961d865b7bf7d@mail.gmail.com> Message-ID: <27a54a111003171646h67b2b0f3kc7d3d66b539a93f3@mail.gmail.com> Hello Mister. Please refer to: http://nanog.org/mailinglist/ Specifically... Acceptable Use Policy "5. Product marketing is prohibited." and "7. Using list as source for private marketing initiatives is prohibited." I don't appreciate you harvesting my email address for the purposes prohibited above. I also don't appreciate 7136k of attachment spam. Sincerely, Mister Pissed. P.S. Nanog consists of females too. Stop calling us all Mister, please. On Wed, Mar 17, 2010 at 4:17 PM, Guillaume FORTAINE wrote: > Dear Nathan, > > Let me introduce myself : Guillaume FORTAINE, Engineer in Computer > Science. Me and my partners, INVEA-TECH (please see the attached file > invea.pdf) [0] and Cognitive Security (please see the attached file > cs.pdf) [1], are currently working on High-Speed Network Security > Solutions. > > By the way, we would greatly appreciate to invite you to a further > reading of the publication entitled "Obeseus ? a lightweight DDOS > detector for big attacks" (please see the attached file obeseus2.pdf) > > The point mentioned: "Would be self-learning with black lists" in this > publication is of particular interest . We think that this last one is > pretty much the core of a system that does big attack detection on > backbones and is driving the new tools in this area according to our > readings. The abilities to be assisted on the learning phase, to > detect and block zero-day attacks. > > That's why we would greatly appreciate to invite you to a further > reading about our methodology (please see the attached files > paper4.pdf, Camnep.pdf and CognitiveSecurity.pdf). > > For a demo : > > http://demo.cognitivesecurity.cz/ > > We look forward to your answer, > > Best Regards, > > Guillaume FORTAINE > Tel : +33(0)631092519 > Mail : gfortaine at gfortaine.biz > Google Wave : gfortaine at googlewave.com > > [0] http://www.invea-tech.com/ > [1] http://www.cognitivesecurity.cz/ > -- Nathan Hickson From gfortaine at live.com Wed Mar 17 19:14:23 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Thu, 18 Mar 2010 01:14:23 +0100 Subject: CSIRT - Backbone Security : Runtime Monitoring and Dynamic Reconfiguration for Intrusion Detection Systems In-Reply-To: <27a54a111003171646h67b2b0f3kc7d3d66b539a93f3@mail.gmail.com> References: <7f35cc71003171617u7890895cm295961d865b7bf7d@mail.gmail.com> <27a54a111003171646h67b2b0f3kc7d3d66b539a93f3@mail.gmail.com> Message-ID: Misses, Misters, Let me introduce myself : Guillaume FORTAINE, Engineer in Computer Science. Me and my partners, INVEA-TECH (please see the attached file invea.pdf) [0] and Cognitive Security (please see the attached file cs.pdf) [1], are currently working on High-Speed Network Security Solutions. By the way, we would greatly appreciate to invite you to a further reading of the publication entitled "Obeseus ? a lightweight DDOS detector for big attacks" (please see the attached file obeseus2.pdf) The point mentioned: "Would be self-learning with black lists" in this publication is of particular interest . We think that this last one is pretty much the core of a system that does big attack detection on backbones and is driving the new tools in this area according to our readings. The abilities to be assisted on the learning phase, to detect and block zero-day attacks. That's why we would greatly appreciate to invite you to a further reading about our methodology (please see the attached files paper4.pdf, Camnep.pdf and CognitiveSecurity.pdf). For a demo : http://demo.cognitivesecurity.cz/ We look forward to your answer, Best Regards, Guillaume FORTAINE Tel : +33(0)631092519 Mail : gfortaine at gfortaine.biz Google Wave : gfortaine at googlewave.com [0] http://www.invea-tech.com/ [1] http://www.cognitivesecurity.cz/ > > > From marka at isc.org Wed Mar 17 19:16:59 2010 From: marka at isc.org (Mark Andrews) Date: Thu, 18 Mar 2010 11:16:59 +1100 Subject: IPv6 in Education Question In-Reply-To: Your message of "Wed, 17 Mar 2010 16:40:59 EDT." References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local>, <87k4tavgxw.fsf@laphroiag.quux.de> Message-ID: <201003180017.o2I0GxNx071333@drugs.dv.isc.org> In message , Brandon Kim writes: > > > Jens: > > There some ISP's trying to push IPv6. Probably not until the masses really = > demand it in someway. > Or if Google pushes it or some well known company. Perhaps maybe an applica= > tion that is IPv6 specific.... Google is pushing it. The problem is the brower vendors still don't support multi-homed sites well despite it being in host requirements for 20+ years. IPv4 + IPv6 give you a multi-homed site. If you have IPv6 connectivity then you can get to google over IPv6, they will even return AAAA records if you register with them. See the browser problem above for why they are taking this route. Mark > dig google.com aaaa ; <<>> DiG 9.3.2 <<>> google.com aaaa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54613 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;google.com. IN AAAA ;; ANSWER SECTION: google.com. 300 IN AAAA 2a00:1450:8006::67 google.com. 300 IN AAAA 2a00:1450:8006::68 google.com. 300 IN AAAA 2a00:1450:8006::69 google.com. 300 IN AAAA 2a00:1450:8006::6a google.com. 300 IN AAAA 2a00:1450:8006::93 google.com. 300 IN AAAA 2a00:1450:8006::63 ;; AUTHORITY SECTION: google.com. 235307 IN NS ns2.google.com. google.com. 235307 IN NS ns3.google.com. google.com. 235307 IN NS ns4.google.com. google.com. 235307 IN NS ns1.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 59146 IN A 216.239.32.10 ns2.google.com. 65481 IN A 216.239.34.10 ns3.google.com. 59146 IN A 216.239.36.10 ns4.google.com. 59146 IN A 216.239.38.10 ;; Query time: 30 msec ;; SERVER: 204.152.184.67#53(204.152.184.67) ;; WHEN: Thu Mar 18 00:08:37 2010 ;; MSG SIZE rcvd: 332 > NAT's and transition protocols seems to extend the life of IPv4. I'm not ag= > ainst them though=2C they have served > us well....hard to let go of things that worked for you for so many years..= > .. > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From charles at knownelement.com Wed Mar 17 19:18:40 2010 From: charles at knownelement.com (charles at knownelement.com) Date: Thu, 18 Mar 2010 00:18:40 +0000 Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems Message-ID: <1661774686-1268871522-cardhu_decombobulator_blackberry.rim.net-556774309-@bda2625.bisx.prod.on.blackberry> Mods, Can we get the spam off the list? Its getting old. ------Original Message------ From: Guillaume FORTAINE To: nanog at nanog.org Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems Sent: Mar 17, 2010 5:14 PM Misses, Misters, Let me introduce myself : Guillaume FORTAINE, Engineer in Computer Science. Me and my partners, INVEA-TECH (please see the attached file invea.pdf) [0] and Cognitive Security (please see the attached file cs.pdf) [1], are currently working on High-Speed Network Security Solutions. By the way, we would greatly appreciate to invite you to a further reading of the publication entitled "Obeseus ? a lightweight DDOS detector for big attacks" (please see the attached file obeseus2.pdf) The point mentioned: "Would be self-learning with black lists" in this publication is of particular interest . We think that this last one is pretty much the core of a system that does big attack detection on backbones and is driving the new tools in this area according to our readings. The abilities to be assisted on the learning phase, to detect and block zero-day attacks. That's why we would greatly appreciate to invite you to a further reading about our methodology (please see the attached files paper4.pdf, Camnep.pdf and CognitiveSecurity.pdf). For a demo : http://demo.cognitivesecurity.cz/ We look forward to your answer, Best Regards, Guillaume FORTAINE Tel : +33(0)631092519 Mail : gfortaine at gfortaine.biz Google Wave : gfortaine at googlewave.com [0] http://www.invea-tech.com/ [1] http://www.cognitivesecurity.cz/ > > > Sent via BlackBerry from T-Mobile From ras at e-gerbil.net Wed Mar 17 19:26:00 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 17 Mar 2010 19:26:00 -0500 Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: <1661774686-1268871522-cardhu_decombobulator_blackberry.rim.net-556774309-@bda2625.bisx.prod.on.blackberry> References: <1661774686-1268871522-cardhu_decombobulator_blackberry.rim.net-556774309-@bda2625.bisx.prod.on.blackberry> Message-ID: <20100318002600.GK75640@gerbil.cluepon.net> On Thu, Mar 18, 2010 at 12:18:40AM +0000, charles at www.knownelement.com wrote: > Mods, > > Can we get the spam off the list? Its getting old. FYI this guy has been spamming individuals and PeeringDB contacts for a couple months now too. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jmamodio at gmail.com Wed Mar 17 19:29:50 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 17 Mar 2010 18:29:50 -0600 Subject: CSIRT - Backbone Security : Runtime Monitoring and Dynamic Reconfiguration for Intrusion Detection Systems In-Reply-To: References: <7f35cc71003171617u7890895cm295961d865b7bf7d@mail.gmail.com> <27a54a111003171646h67b2b0f3kc7d3d66b539a93f3@mail.gmail.com> Message-ID: <202705b1003171729wf6313fay49c6cf4dec3478eb@mail.gmail.com> What happened, the old OEM PowerPC cellphone gig didn't work out ? Seriously the Obeseus document you keep promoting is 100% useless. Cheers Jorge On Wed, Mar 17, 2010 at 6:14 PM, Guillaume FORTAINE wrote: > Misses, Misters, > > Let me introduce myself : Guillaume FORTAINE, Engineer in Computer > Science. Me and my partners, INVEA-TECH (please see the attached file > invea.pdf) [0] and Cognitive Security (please see the attached file > cs.pdf) [1], are currently working on High-Speed Network Security > Solutions. From LarrySheldon at cox.net Wed Mar 17 19:53:27 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 17 Mar 2010 19:53:27 -0500 Subject: CSIRT - Backbone Security : Runtime Monitoring and Dynamic Reconfiguration for Intrusion Detection Systems In-Reply-To: <202705b1003171729wf6313fay49c6cf4dec3478eb@mail.gmail.com> References: <7f35cc71003171617u7890895cm295961d865b7bf7d@mail.gmail.com> <27a54a111003171646h67b2b0f3kc7d3d66b539a93f3@mail.gmail.com> <202705b1003171729wf6313fay49c6cf4dec3478eb@mail.gmail.com> Message-ID: <4BA17987.10708@cox.net> [bagged and tagged] Yes the spam is annoying. It is annoying that the moderators have let go on a lot longer than they have some operational discussions. But what is REALLY annoying is the people who quote the crap around my filters after I have had to take local action to staunch the flow. And changing the subject line to defeat the filters is an especially annoying touch. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From bruns at 2mbit.com Wed Mar 17 19:58:57 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 17 Mar 2010 17:58:57 -0700 Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: <20100318002600.GK75640@gerbil.cluepon.net> References: <1661774686-1268871522-cardhu_decombobulator_blackberry.rim.net-556774309-@bda2625.bisx.prod.on.blackberry> <20100318002600.GK75640@gerbil.cluepon.net> Message-ID: <4BA17AD1.2000803@2mbit.com> On 3/17/10 5:26 PM, Richard A Steenbergen wrote: > On Thu, Mar 18, 2010 at 12:18:40AM +0000, charles at www.knownelement.com wrote: >> Mods, >> >> Can we get the spam off the list? Its getting old. > > FYI this guy has been spamming individuals and PeeringDB contacts for a > couple months now too. > My spammy sense is going nuts just at the whole ALL CAPS of this guy's last name. I've thrown his personal domain in the AHBL, but given he uses live.com to send his spew, its not going to help. *sigh* -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From msokolov at ivan.Harhan.ORG Wed Mar 17 20:09:49 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Thu, 18 Mar 2010 01:09:49 GMT Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems Message-ID: <1003180109.AA26859@ivan.Harhan.ORG> > My spammy sense is going nuts just at the whole ALL CAPS of this guy's > last name. I thought all-uppercase last names were a traditional French convention... This guy is French, isn't he? - judging by his name. His habit of addressing everyone as "Mister" is peculiar indeed, but maybe he is really just very new to the customs and conventions of the Anglophone Internet community? Just wondering... MS From bruns at 2mbit.com Wed Mar 17 20:20:12 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 17 Mar 2010 18:20:12 -0700 Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: <1003180109.AA26859@ivan.Harhan.ORG> References: <1003180109.AA26859@ivan.Harhan.ORG> Message-ID: <4BA17FCC.4080209@2mbit.com> On 3/17/10 6:09 PM, Michael Sokolov wrote: >> My spammy sense is going nuts just at the whole ALL CAPS of this guy's >> last name. > > I thought all-uppercase last names were a traditional French convention... > This guy is French, isn't he? - judging by his name. > > His habit of addressing everyone as "Mister" is peculiar indeed, but > maybe he is really just very new to the customs and conventions of the > Anglophone Internet community? > > Just wondering... > > MS > I'm not sure of conventions, but he just referred to me as Mister Bruns in private e-mail. Not a good way to get on my good side, given Brielle is a French name that means 'exalted goddess'. :-) Though he seems highly optimistic that I should develop for him. *rolls eyes* -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From gfortaine at live.com Wed Mar 17 20:32:21 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Thu, 18 Mar 2010 02:32:21 +0100 Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: <1003180109.AA26859@ivan.Harhan.ORG> References: <1003180109.AA26859@ivan.Harhan.ORG> Message-ID: Misses, Misters, I have read with interest what everybody told in this thread and it seems that they consider everything new as spam. My conclusion is that they fear what it is new. Best Regards, Guillaume FORTAINE On 03/18/2010 02:09 AM, Michael Sokolov wrote: >> My spammy sense is going nuts just at the whole ALL CAPS of this guy's >> last name. >> > I thought all-uppercase last names were a traditional French convention... > This guy is French, isn't he? - judging by his name. > > His habit of addressing everyone as "Mister" is peculiar indeed, but > maybe he is really just very new to the customs and conventions of the > Anglophone Internet community? > > Just wondering... > > MS > > > > From nanog at armorfirewall.com Wed Mar 17 21:01:43 2010 From: nanog at armorfirewall.com (George Imburgia) Date: Wed, 17 Mar 2010 21:01:43 -0500 (EST) Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: <1003180109.AA26859@ivan.Harhan.ORG> References: <1003180109.AA26859@ivan.Harhan.ORG> Message-ID: On Thu, 18 Mar 2010, Michael Sokolov wrote: > His habit of addressing everyone as "Mister" is peculiar indeed, but > maybe he is really just very new to the customs and conventions of the > Anglophone Internet community? Probably not. He has been trolling techie lists for a few years. Some of his previous vaporware projects included designing a new cell phone, and a "secure OS". Not sure what his motivation is. He usually wants people to donate knowledge and time to his projects, which never go anywhere. From nanog at daork.net Wed Mar 17 20:34:26 2010 From: nanog at daork.net (Nathan Ward) Date: Thu, 18 Mar 2010 14:34:26 +1300 Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: References: <1003180109.AA26859@ivan.Harhan.ORG> Message-ID: Dig up. On 18/03/2010, at 2:32 PM, Guillaume FORTAINE wrote: > Misses, Misters, > > I have read with interest what everybody told in this thread and it seems that they consider everything new as spam. > > My conclusion is that they fear what it is new. > > Best Regards, > > Guillaume FORTAINE > > > On 03/18/2010 02:09 AM, Michael Sokolov wrote: >>> My spammy sense is going nuts just at the whole ALL CAPS of this guy's >>> last name. >>> >> I thought all-uppercase last names were a traditional French convention... >> This guy is French, isn't he? - judging by his name. >> >> His habit of addressing everyone as "Mister" is peculiar indeed, but >> maybe he is really just very new to the customs and conventions of the >> Anglophone Internet community? >> >> Just wondering... >> >> MS >> >> >> >> > > > > !DSPAM:22,4ba182fd13889398512228! > > From msokolov at ivan.Harhan.ORG Wed Mar 17 20:43:38 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Thu, 18 Mar 2010 01:43:38 GMT Subject: Any old Nokia DSLAMs gathering dust? Message-ID: <1003180143.AA27024@ivan.Harhan.ORG> Hello NANOGers, I wonder, would anyone here happen to have an unused Nokia / Diamond Lane Speedlink DSLAM chassis that's laying around gathering dust and which you wouldn't mind donating to an open source xDSL CPE project? Just wondering if anyone here might perchance have one they are trying to get rid of - after all, one man's garbage is another man's treasure... MS From gfortaine at live.com Wed Mar 17 20:53:38 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Thu, 18 Mar 2010 02:53:38 +0100 Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: References: <1003180109.AA26859@ivan.Harhan.ORG> Message-ID: Misses, Misters, There are people who know my name but theirs isn't familiar to me. Especially, they are mentioning really old stuff. I am asking myself : a) Why do they remember me ? b) How do you remember me ? My new "vaporware" is there my friend : http://www.invea-tech.com http://www.cognitivesecurity.cz Sponsored by the US Army, 10 years of R&D ;) ! Best Regards, Guillaume FORTAINE On 03/18/2010 03:01 AM, George Imburgia wrote: > > > On Thu, 18 Mar 2010, Michael Sokolov wrote: > > >> His habit of addressing everyone as "Mister" is peculiar indeed, but >> maybe he is really just very new to the customs and conventions of the >> Anglophone Internet community? > > Probably not. He has been trolling techie lists for a few years. Some > of his previous vaporware projects included designing a new cell > phone, and a "secure OS". > > Not sure what his motivation is. He usually wants people to donate > knowledge and time to his projects, which never go anywhere. > > > From jmamodio at gmail.com Wed Mar 17 21:02:37 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 17 Mar 2010 20:02:37 -0600 Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: References: <1003180109.AA26859@ivan.Harhan.ORG> Message-ID: <202705b1003171902y3b5bc80cvda4008af4edeaad5@mail.gmail.com> Lets do something, here is somebody that can help you with your projects. Call INEG INC at 214-244-4827 and ask for Jeffrey, he is the CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. I'm almost sure he will be a perfect match for what you are looking for. Cheers Jorge On Wed, Mar 17, 2010 at 7:53 PM, Guillaume FORTAINE wrote: > Misses, Misters, > > There are people who know my name but theirs isn't familiar to me. > Especially, they are mentioning ?really old stuff. I am asking myself : > > a) Why do they remember me ? > > b) How do you remember me ? > > My new "vaporware" is there my friend : > > http://www.invea-tech.com > > http://www.cognitivesecurity.cz > > Sponsored by the US Army, 10 years of R&D ;) ! > > Best Regards, > > Guillaume FORTAINE From jbfixurpc at gmail.com Wed Mar 17 21:11:07 2010 From: jbfixurpc at gmail.com (Joe) Date: Wed, 17 Mar 2010 22:11:07 -0400 Subject: CSIRT - Backbone Security : Runtime Monitoringand DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: Message-ID: <000a01cac640$465802a0$4401a8c0@jgbpc> Ok, off topic, but hey, its St.Patricks day gotta have a laugh. His responses remind me of this fellow in Nigeria. He (Prince Tatobany) really needed my help, and thankfully I was there to lend a hand. Hopefully someone will help him out with his endeavors and his spam ^h^h^h^h information. Regards, -Joe -----Original Message----- From: Guillaume FORTAINE [mailto:gfortaine at live.com] Sent: Wednesday, March 17, 2010 9:54 PM To: nanog at nanog.org Subject: Re: CSIRT - Backbone Security : Runtime Monitoringand DynamicReconfiguration for Intrusion Detection Systems Misses, Misters, There are people who know my name but theirs isn't familiar to me. Especially, they are mentioning really old stuff. I am asking myself : a) Why do they remember me ? b) How do you remember me ? My new "vaporware" is there my friend : http://www.invea-tech.com http://www.cognitivesecurity.cz Sponsored by the US Army, 10 years of R&D ;) ! Best Regards, Guillaume FORTAINE On 03/18/2010 03:01 AM, George Imburgia wrote: > > > On Thu, 18 Mar 2010, Michael Sokolov wrote: > > >> His habit of addressing everyone as "Mister" is peculiar indeed, but >> maybe he is really just very new to the customs and conventions of >> the Anglophone Internet community? > > Probably not. He has been trolling techie lists for a few years. Some > of his previous vaporware projects included designing a new cell > phone, and a "secure OS". > > Not sure what his motivation is. He usually wants people to donate > knowledge and time to his projects, which never go anywhere. > > > From gfortaine at live.com Wed Mar 17 21:44:56 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Thu, 18 Mar 2010 03:44:56 +0100 Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: <202705b1003171902y3b5bc80cvda4008af4edeaad5@mail.gmail.com> References: <1003180109.AA26859@ivan.Harhan.ORG> <202705b1003171902y3b5bc80cvda4008af4edeaad5@mail.gmail.com> Message-ID: Dear Mister Amodio, Thank you for your reply. http://66.102.9.132/search?q=cache:uh4LLvF7vGUJ:www.gtld-mou.org/gtld-discuss/mail-archive/08015.html+"Information+Network+Engineering+Group"&cd=3&hl=en&ct=clnk Jeff Williams' FAQ. (99/01) -- 1. Who is Jeff Williams? Jeffrey A. Williams, , has claimed in postings to various lists: -- to be the Chief Executive Officer and the Co-Founder of the 4.8 billion dollar privately held employee owned INEG. INC -- to be the Director of Internet Network Engineering and Senior Java/CORBA Engineer for the Information Network Engineering Group, INEG INC. -- to be an ex-IBM Fellow, -- to have to have graduated from UTD and to have a law degree from SMU Law School -- to have three degrees, MBA, Masters in Computer Science and Engineering, and Law -- to have served as a judge for 7 years -- to be a member of the IETF -- to serve on several medium sized business boards and on the boards of several banks -- to be the author of two books and is working on a third -- to own 3 ISPs, including Frisco net, Deltanet and Wiltel, with 1.6 million users -- to have been a fighter pilot with USMC, flying missions in Chile and for the DEA, as a reserve pilot in the USMC, stationed out of Grand Prairie air station just south of Dallas -- to have been acting squadron commander of the Marine combat F4 squadron VMF214 (Black Sheep) at Tan Son Nhut during the Viet Nam war -- to have spent several years in NIS (Naval Investigative Service) -- Graduate of Naval Staff & War College -- Retired Colonel, United States Marine Corps -- to own 8% of eBay However, -- Jeff's 'INEG. INC' does not exist except as a fantasy in Jeff Williams' mind. -- Jeff changed the name of the company in his .sig, in Jan 1998, from 'Information Eng. Group' to Information Network Eng. Group. INEG. INC., when the real Information Engineering Group , became aware of Jeff's use of their name. -- SMU Law School Registrar's office, (214) 768-2618, disclaims all knowledge of Jeff. Jeffrey A. Williams is a fake and an imposter. -- 2. Why should I take care in sending private email to Jeff Williams? He may post it to the list. Ironically, in his postings of others' private email so far the content has been counter-productive to his reputation and credibility. You should presume any email to him will posted to the list. -- 3. Is there other material available on Jeff Williams? http://www.gtld-mou.org/gtld-discuss/mail-archive/03504.html http://www.gtld-mou.org/gtld-discuss/mail-archive/05347.html http://www.gtld-mou.org/gtld-discuss/mail-archive/05398.html http://www.gtld-mou.org/gtld-discuss/mail-archive/05525.html http://www.gtld-mou.org/gtld-discuss/mail-archive/08015.html Best Regards, Guillaume FORTAINE On 03/18/2010 03:02 AM, Jorge Amodio wrote: > Lets do something, here is somebody that can help you with your projects. > > Call INEG INC at 214-244-4827 and ask for Jeffrey, he is the CSO/DIR. > Internet Network Eng. SR. Eng. Network data security IDNS. div. of > Information Network Eng. > > I'm almost sure he will be a perfect match for what you are looking for. > > Cheers > Jorge > > On Wed, Mar 17, 2010 at 7:53 PM, Guillaume FORTAINE wrote: > >> Misses, Misters, >> >> There are people who know my name but theirs isn't familiar to me. >> Especially, they are mentioning really old stuff. I am asking myself : >> >> a) Why do they remember me ? >> >> b) How do you remember me ? >> >> My new "vaporware" is there my friend : >> >> http://www.invea-tech.com >> >> http://www.cognitivesecurity.cz >> >> Sponsored by the US Army, 10 years of R&D ;) ! >> >> Best Regards, >> >> Guillaume FORTAINE >> > > From gfortaine at live.com Wed Mar 17 21:51:18 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Thu, 18 Mar 2010 03:51:18 +0100 Subject: CSIRT - Backbone Security : Runtime Monitoringand DynamicReconfiguration for Intrusion Detection Systems Message-ID: This is really not funny. Especially coming from a monkey with a "fixurpc" pattern in his email address. My friend, I believe that I can give you a serious course in Computer Architecture ;) ! Best Regards, Guillaume FORTAINE On 03/18/2010 03:11 AM, Joe wrote: > Ok, off topic, but hey, its St.Patricks day gotta have a laugh. > > > His responses remind me of this fellow in Nigeria. He (Prince Tatobany) > really needed my help, and thankfully I was there to lend a hand. Hopefully > someone will help him out with his endeavors and his spam ^h^h^h^h > information. > > > Regards, > -Joe > > > -----Original Message----- > From: Guillaume FORTAINE [mailto:gfortaine at live.com] > Sent: Wednesday, March 17, 2010 9:54 PM > To: nanog at nanog.org > Subject: Re: CSIRT - Backbone Security : Runtime Monitoringand > DynamicReconfiguration for Intrusion Detection Systems > > > Misses, Misters, > > There are people who know my name but theirs isn't familiar to me. > Especially, they are mentioning really old stuff. I am asking myself : > > a) Why do they remember me ? > > b) How do you remember me ? > > My new "vaporware" is there my friend : > > http://www.invea-tech.com > > http://www.cognitivesecurity.cz > > Sponsored by the US Army, 10 years of R&D ;) ! > > Best Regards, > > Guillaume FORTAINE > > > > On 03/18/2010 03:01 AM, George Imburgia wrote: > >> >> On Thu, 18 Mar 2010, Michael Sokolov wrote: >> >> >> >>> His habit of addressing everyone as "Mister" is peculiar indeed, but >>> maybe he is really just very new to the customs and conventions of >>> the Anglophone Internet community? >>> >> Probably not. He has been trolling techie lists for a few years. Some >> of his previous vaporware projects included designing a new cell >> phone, and a "secure OS". >> >> Not sure what his motivation is. He usually wants people to donate >> knowledge and time to his projects, which never go anywhere. >> >> >> >> > > > > From gfortaine at live.com Wed Mar 17 21:58:08 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Thu, 18 Mar 2010 03:58:08 +0100 Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: <290EF89F13F04F4E924BB235A46D18F109FE37F221@MLBMXUS2.cs.myharris.net> References: <290EF89F13F04F4E924BB235A46D18F109FE37F221@MLBMXUS2.cs.myharris.net> Message-ID: Do you have any concern against fat dudes ? Best Regards, Guillaume FORTAINE ---------------------------------------- > From: Charles.Church at harris.com > To: charles at knownelement.com; gfortaine at live.com; nanog at nanog.org > Date: Wed, 17 Mar 2010 20:42:49 -0400 > Subject: Re: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems > > isn't Obeseus the greek god of fat dudes? > > ----- Original Message ----- > From: charles at knownelement.com > To: Guillaume FORTAINE ; nanog at nanog.org > Sent: Wed Mar 17 20:18:40 2010 > Subject: Re: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems > > Mods, > > Can we get the spam off the list? Its getting old. > > > ------Original Message------ > From: Guillaume FORTAINE > To: nanog at nanog.org > Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems > Sent: Mar 17, 2010 5:14 PM > > Misses, Misters, > > Let me introduce myself : Guillaume FORTAINE, Engineer in Computer > Science. Me and my partners, INVEA-TECH (please see the attached file > invea.pdf) [0] and Cognitive Security (please see the attached file > cs.pdf) [1], are currently working on High-Speed Network Security > Solutions. > > By the way, we would greatly appreciate to invite you to a further > reading of the publication entitled "Obeseus ? a lightweight DDOS > detector for big attacks" (please see the attached file obeseus2.pdf) > > The point mentioned: "Would be self-learning with black lists" in this > publication is of particular interest . We think that this last one is > pretty much the core of a system that does big attack detection on > backbones and is driving the new tools in this area according to our > readings. The abilities to be assisted on the learning phase, to > detect and block zero-day attacks. > > That's why we would greatly appreciate to invite you to a further > reading about our methodology (please see the attached files > paper4.pdf, Camnep.pdf and CognitiveSecurity.pdf). > > For a demo : > > http://demo.cognitivesecurity.cz/ > > We look forward to your answer, > > Best Regards, > > Guillaume FORTAINE > Tel : +33(0)631092519 > Mail : gfortaine at gfortaine.biz > Google Wave : gfortaine at googlewave.com > > [0] http://www.invea-tech.com/ > [1] http://www.cognitivesecurity.cz/ > >> >> >> > > > > > Sent via BlackBerry from T-Mobile _________________________________________________________________ Hotmail: Trusted email with Microsoft?s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 From tammy-lists at wiztech.biz Wed Mar 17 22:01:45 2010 From: tammy-lists at wiztech.biz (Tammy A. Wisdom) Date: Wed, 17 Mar 2010 21:01:45 -0600 (MDT) Subject: CSIRT - Backbone Security : Runtime Monitoringand DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: Message-ID: <1351556214.22.1268881305002.JavaMail.root@lordsofacid.wiztech.biz> do you have brain damage or something? did you eat lead paint chips as a kid? parents drop you too much? I swear take a f***ing hint idiot. PS welcome to my killfile and the AHBL GO AWAY!!!!!!! --Tammy ----- "Guillaume FORTAINE" wrote: > This is really not funny. > > Especially coming from a monkey with a "fixurpc" pattern in his email > address. My friend, I believe that I can give you a serious course in > Computer Architecture ;) ! > > Best Regards, > > Guillaume FORTAINE > > On 03/18/2010 03:11 AM, Joe wrote: > > Ok, off topic, but hey, its St.Patricks day gotta have a laugh. > > > > > > His responses remind me of this fellow in Nigeria. He (Prince > Tatobany) > > really needed my help, and thankfully I was there to lend a hand. > Hopefully > > someone will help him out with his endeavors and his spam ^h^h^h^h > > information. > > > > > > Regards, > > -Joe > > > > > > -----Original Message----- > > From: Guillaume FORTAINE [mailto:gfortaine at live.com] > > Sent: Wednesday, March 17, 2010 9:54 PM > > To: nanog at nanog.org > > Subject: Re: CSIRT - Backbone Security : Runtime Monitoringand > > DynamicReconfiguration for Intrusion Detection Systems > > > > > > Misses, Misters, > > > > There are people who know my name but theirs isn't familiar to me. > > Especially, they are mentioning really old stuff. I am asking > myself : > > > > a) Why do they remember me ? > > > > b) How do you remember me ? > > > > My new "vaporware" is there my friend : > > > > http://www.invea-tech.com > > > > http://www.cognitivesecurity.cz > > > > Sponsored by the US Army, 10 years of R&D ;) ! > > > > Best Regards, > > > > Guillaume FORTAINE > > > > > > > > On 03/18/2010 03:01 AM, George Imburgia wrote: > > > >> > >> On Thu, 18 Mar 2010, Michael Sokolov wrote: > >> > >> > >> > >>> His habit of addressing everyone as "Mister" is peculiar indeed, > but > >>> maybe he is really just very new to the customs and conventions > of > >>> the Anglophone Internet community? > >>> > >> Probably not. He has been trolling techie lists for a few years. > Some > >> of his previous vaporware projects included designing a new cell > >> phone, and a "secure OS". > >> > >> Not sure what his motivation is. He usually wants people to > donate > >> knowledge and time to his projects, which never go anywhere. > >> > >> > >> > >> > > > > > > > > ****************************************************************************** Disclaimer: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. ****************************************************************************** From rgolodner at infratection.com Wed Mar 17 22:01:56 2010 From: rgolodner at infratection.com (Richard Golodner) Date: Wed, 17 Mar 2010 22:01:56 -0500 Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems In-Reply-To: References: <290EF89F13F04F4E924BB235A46D18F109FE37F221@MLBMXUS2.cs.myharris.net> Message-ID: <1268881316.13266.55.camel@Andromeda> Move this to FD, please. On Thu, 2010-03-18 at 03:58 +0100, Guillaume FORTAINE wrote: > Do you have any concern against fat dudes ? > Best Regards, > Guillaume FORTAINE > > ---------------------------------------- > > From: Charles.Church at harris.com > > To: charles at knownelement.com; gfortaine at live.com; nanog at nanog.org > > Date: Wed, 17 Mar 2010 20:42:49 -0400 > > Subject: Re: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems > > > > isn't Obeseus the greek god of fat dudes? > > > > ----- Original Message ----- > > From: charles at knownelement.com > > To: Guillaume FORTAINE ; nanog at nanog.org > > Sent: Wed Mar 17 20:18:40 2010 > > Subject: Re: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems > > > > Mods, > > > > Can we get the spam off the list? Its getting old. > > > > > > ------Original Message------ > > From: Guillaume FORTAINE > > To: nanog at nanog.org > > Subject: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems > > Sent: Mar 17, 2010 5:14 PM > > > > Misses, Misters, > > > > Let me introduce myself : Guillaume FORTAINE, Engineer in Computer > > Science. Me and my partners, INVEA-TECH (please see the attached file > > invea.pdf) [0] and Cognitive Security (please see the attached file > > cs.pdf) [1], are currently working on High-Speed Network Security > > Solutions. > > > > By the way, we would greatly appreciate to invite you to a further > > reading of the publication entitled "Obeseus ? a lightweight DDOS > > detector for big attacks" (please see the attached file obeseus2.pdf) > > > > The point mentioned: "Would be self-learning with black lists" in this > > publication is of particular interest . We think that this last one is > > pretty much the core of a system that does big attack detection on > > backbones and is driving the new tools in this area according to our > > readings. The abilities to be assisted on the learning phase, to > > detect and block zero-day attacks. > > > > That's why we would greatly appreciate to invite you to a further > > reading about our methodology (please see the attached files > > paper4.pdf, Camnep.pdf and CognitiveSecurity.pdf). > > > > For a demo : > > > > http://demo.cognitivesecurity.cz/ > > > > We look forward to your answer, > > > > Best Regards, > > > > Guillaume FORTAINE > > Tel : +33(0)631092519 > > Mail : gfortaine at gfortaine.biz > > Google Wave : gfortaine at googlewave.com > > > > [0] http://www.invea-tech.com/ > > [1] http://www.cognitivesecurity.cz/ > > > >> > >> > >> > > > > > > > > > > Sent via BlackBerry from T-Mobile > > _________________________________________________________________ > Hotmail: Trusted email with Microsoft?s powerful SPAM protection. > https://signup.live.com/signup.aspx?id=60969 > From xleonzhao at gmail.com Wed Mar 17 22:39:54 2010 From: xleonzhao at gmail.com (Xiaoliang Zhao) Date: Thu, 18 Mar 2010 11:39:54 +0800 Subject: IPv6 in Education Question In-Reply-To: <1268868062.5727.652.camel@karl> References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> <1268868062.5727.652.camel@karl> Message-ID: <4e913c5d1003172039id15ba75k2fa5fb85be3f26e3@mail.gmail.com> > End-to-end transparency means that IPv6 supports peer to peer naturally. > That means everyone (students, teachers, parents etc) can talk to each > other more easily without having to involve third parties, and can talk > to each other from anywhere on the globe. Less mediation, more direct, > more distributed. > > The death of NAT will mean that more and more stuff will be hosted > locally - on teaching machines, student laptops, home PCs, mobile > phones. I think we will see fragmentation and distribution of things > that are now monolithic. Things like Facebook, Twitter, MySpace and so > on will be reduced to special purpose indexing services - or will die. > Why use them when you can have all your stuff on your mobile phone, > accessible 24/7, wherever you are? Good points. Leon CERNET2 network engineer http://www.cernet2.edu.cn/index_en.htm From kowsik at gmail.com Wed Mar 17 23:27:11 2010 From: kowsik at gmail.com (kowsik) Date: Wed, 17 Mar 2010 21:27:11 -0700 Subject: Announcing: Ruby API for xtractr Message-ID: <7db9abd31003172127w69125a67s8e3154a4cf9aeb30@mail.gmail.com> What started off as a way to unit test the RESTful API for xtractr has now turned into a Ruby gem that we are releasing as open source. First xtractr, then nuggets and now a gem. We are happy to announce a Ruby gem for xtractr which takes all the goodness of Ruby and interacts RESTfully with xtractr for oh-so-fun network forensics and troubleshooting all from within IRB, the interactive Ruby shell. Blog: http://bit.ly/baW3zZ Code: http://code.google.com/p/pcapr/ Thanks, K. --- http://www.pcapr.net/ http://www.mudynamics.com http://labs.mudynamics.com http://twitter.com/pcapr From kowsik at gmail.com Wed Mar 17 23:32:53 2010 From: kowsik at gmail.com (kowsik) Date: Wed, 17 Mar 2010 21:32:53 -0700 Subject: anti-ddos test solutions ? In-Reply-To: <005001cac5ff$96a55370$c3effa50$@net> References: <4BA07A6F.4010104@yahoo.fr> <1268817124.2479.3.camel@localhost> <4BA11C48.6000506@knownelement.com> <005001cac5ff$96a55370$c3effa50$@net> Message-ID: <7db9abd31003172132l3d94fe2du7e9e8c9a05775df6@mail.gmail.com> http://labs.mudynamics.com/2009/04/10/ddos-testing-network-applications/ http://www.pcapr.net/dos YMMV, but mudos converts *any* IP packet into a DoS generator (it's free). K. --- http://www.pcapr.net http://labs.mudynamics.com http://twitter.com/pcapr On Wed, Mar 17, 2010 at 11:28 AM, Stefan Fouant wrote: >> -----Original Message----- >> From: Charles N Wyble [mailto:charles at knownelement.com] >> Sent: Wednesday, March 17, 2010 12:16 PM >> To: nanog at nanog.org >> Subject: Re: anti-ddos test solutions ? >> >> bit gossip wrote: >> > Nessus is a vulnerability scanner: >> > >> > http://www.nessus.org/nessus/ >> > >> > Ixia provides a full Nessus implementation in one of its platform. >> > >> >> Well these days I would use http://www.openvas.org and >> http://www.metasploit.org >> for vulnerability scanning and analysis. >> >> However that wouldn't be a DDoS, but could certainly lead to DOS. > > If you can get your hands on a PCAP from a previous attack, you could also use something like Bit-Twist which will allow you to manipulate things like the destination IP and also the transmission rate, etc. ?Pretty useful tool to include in the DDoS simulation toolbox. > > http://bittwist.sourceforge.net/ > > Stefan Fouant, CISSP, JNCIE-M/T > www.shortestpathfirst.net > GPG Key ID: 0xB5E3803D > > > From dawood_iqbal at hotmail.com Thu Mar 18 05:17:23 2010 From: dawood_iqbal at hotmail.com (Dawood Iqbal) Date: Thu, 18 Mar 2010 10:17:23 +0000 Subject: Best VPN Appliance In-Reply-To: <90DF793301873F469B0B7878B4CFD4F4015A4B38BDC9@EXMAIL.bullseyetelecom.com> References: , <90DF793301873F469B0B7878B4CFD4F4015A4B38BDC9@EXMAIL.bullseyetelecom.com> Message-ID: Hello All, Thank-you all for reply and sugessting the VPN Box. I'm in the process of evaluating different boxes and they are; SA4500 SSL VPN Appliance http://www.juniper.net/us/en/products-services/security/sa-series/sa4500/ Barracuda SSL VPN http://www.barracudanetworks.com/ns/products/sslvpn_overview.php F5 FirePass SSL VPN http://www.f5.com/products/firepass/ The problem i'm facing so far is MAC OS X compatibility. The demo box i had for Juniper was not able to run Network Connect on MAC OS 10.5.8. From your experience from F5, Juniper and Barracuda, which one will be best in terms of; 1) Support 2) Resiliency 3) Security 4) Scalability 5) Manageability Thanks for all your help. Regards, Dawood Iqbal _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 From drew.weaver at thenap.com Thu Mar 18 08:05:32 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 18 Mar 2010 09:05:32 -0400 Subject: anti-ddos test solutions ? In-Reply-To: <7db9abd31003172132l3d94fe2du7e9e8c9a05775df6@mail.gmail.com> References: <4BA07A6F.4010104@yahoo.fr> <1268817124.2479.3.camel@localhost> <4BA11C48.6000506@knownelement.com> <005001cac5ff$96a55370$c3effa50$@net> <7db9abd31003172132l3d94fe2du7e9e8c9a05775df6@mail.gmail.com> Message-ID: On a similar note but slightly unrelated note, Not to thread hijack, but does anyone have any useful recipes for generating any basic baseline data (top talkers, SSH brute forcing, SMTP brute forcing, 445,etc) via any of the open source netflow collectors (Flow-Tools, nfdump)? I've had mixed success getting these packages to produce any useful information after getting them to collect the flow data. Thanks, -Drew -----Original Message----- From: kowsik [mailto:kowsik at gmail.com] Sent: Thursday, March 18, 2010 12:33 AM To: Stefan Fouant Cc: nanog at nanog.org Subject: Re: anti-ddos test solutions ? http://labs.mudynamics.com/2009/04/10/ddos-testing-network-applications/ http://www.pcapr.net/dos YMMV, but mudos converts *any* IP packet into a DoS generator (it's free). K. --- http://www.pcapr.net http://labs.mudynamics.com http://twitter.com/pcapr On Wed, Mar 17, 2010 at 11:28 AM, Stefan Fouant wrote: >> -----Original Message----- >> From: Charles N Wyble [mailto:charles at knownelement.com] >> Sent: Wednesday, March 17, 2010 12:16 PM >> To: nanog at nanog.org >> Subject: Re: anti-ddos test solutions ? >> >> bit gossip wrote: >> > Nessus is a vulnerability scanner: >> > >> > http://www.nessus.org/nessus/ >> > >> > Ixia provides a full Nessus implementation in one of its platform. >> > >> >> Well these days I would use http://www.openvas.org and >> http://www.metasploit.org >> for vulnerability scanning and analysis. >> >> However that wouldn't be a DDoS, but could certainly lead to DOS. > > If you can get your hands on a PCAP from a previous attack, you could also use something like Bit-Twist which will allow you to manipulate things like the destination IP and also the transmission rate, etc. ?Pretty useful tool to include in the DDoS simulation toolbox. > > http://bittwist.sourceforge.net/ > > Stefan Fouant, CISSP, JNCIE-M/T > www.shortestpathfirst.net > GPG Key ID: 0xB5E3803D > > > From Joe.Goldberg at falconstor.com Thu Mar 18 09:13:34 2010 From: Joe.Goldberg at falconstor.com (Joe Goldberg) Date: Thu, 18 Mar 2010 10:13:34 -0400 Subject: Best VPN Appliance References: , <90DF793301873F469B0B7878B4CFD4F4015A4B38BDC9@EXMAIL.bullseyetelecom.com> Message-ID: <629000C394462748817B16908F1AC93E59CDE3@CORPEXCH04.FalconStor.Net> For the Juniper box, make sure you are running the 6.5R3 version of code to get the MAC to work. They put a fix in for it. It is working well for us here. http://kb.juniper.net/index?page=content&id=KB16134&actp=search&searchid=1268921120591 I have no experience with either F5 or Barracuda, but we have found the Juniper SSL to be extremely reliable and flexible to suit all of our needs. We have several 2500's deployed. Joe -----Original Message----- From: Dawood Iqbal [mailto:dawood_iqbal at hotmail.com] Sent: Thursday, March 18, 2010 6:17 AM To: nanog at nanog.org Subject: RE: Best VPN Appliance Hello All, Thank-you all for reply and sugessting the VPN Box. I'm in the process of evaluating different boxes and they are; SA4500 SSL VPN Appliance http://www.juniper.net/us/en/products-services/security/sa-series/sa4500/ Barracuda SSL VPN http://www.barracudanetworks.com/ns/products/sslvpn_overview.php F5 FirePass SSL VPN http://www.f5.com/products/firepass/ The problem i'm facing so far is MAC OS X compatibility. The demo box i had for Juniper was not able to run Network Connect on MAC OS 10.5.8. From your experience from F5, Juniper and Barracuda, which one will be best in terms of; 1) Support 2) Resiliency 3) Security 4) Scalability 5) Manageability Thanks for all your help. Regards, Dawood Iqbal _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 From nanog at mattelmore.com Thu Mar 18 09:25:05 2010 From: nanog at mattelmore.com (Matthew Elmore) Date: Thu, 18 Mar 2010 09:25:05 -0500 Subject: Best VPN Appliance In-Reply-To: References: <90DF793301873F469B0B7878B4CFD4F4015A4B38BDC9@EXMAIL.bullseyetelecom.com> Message-ID: On Mar 18, 2010, at 5:17 AM, Dawood Iqbal wrote: The problem i'm facing so far is MAC OS X compatibility. The demo box i had > for Juniper was not able to run Network Connect on MAC OS 10.5.8. We use an SA700 (lowest-end model) and I use NC regularly form my Mac, but I am running 10.6.2. I did not have trouble running NC when I was on 10.5 however, but that was several months ago. The biggest trick on the Mac is figuring out how to use a client-side certificate properly... >From your experience from F5, Juniper and Barracuda, which one will be best > in terms of; Speaking only from my experience with the Juniper product: 1) Support When dealing with configuring and troubleshooting the appliance itself, JTAC has been pretty helpful when I've had to call on them. However, it has been hard getting help when dealing with client issues (Bob's PC won't establish tunnel properly, host checker issues, etc.). 2) Resiliency We don't do HA as we only have a handful of users, so I can't speak to this. 3) Security It's good enough for us, and we have lots of rules we have to follow (financial institution). Authentication is hooked into our Active Directory, so passwords are managed from there. We require a client-side certificate issued from a private CA, which works well, even recognizes and enforces certificate revocation lists. 4) Scalability See #2. We have a max of maybe five concurrent users, and that's a rare occurrence. 5) Manageability Set it and forget it. Only thing I have to do is load ESAP updates occasionally (host checker engine definitions). There are a couple useful SNMP oid's but they're not documented very well. From dennis-lists at thenose.net Thu Mar 18 09:56:16 2010 From: dennis-lists at thenose.net (Dennis Dayman) Date: Thu, 18 Mar 2010 09:56:16 -0500 Subject: Latency quesstion Message-ID: have a friend who has 21 floors of a building in DFW, multiple switches, etc and they started to have latency issues this weekend where half if not all packet are being dropped to folder shares, printers, etc. Suggestions on how they can troubleshoot that? call in a company to help identify it? -Dennis From w3yni1 at gmail.com Thu Mar 18 10:04:16 2010 From: w3yni1 at gmail.com (Charles Mills) Date: Thu, 18 Mar 2010 11:04:16 -0400 Subject: Latency quesstion In-Reply-To: References: Message-ID: <607f1e0a1003180804r64e943c6s2e73ffe46cb914b8@mail.gmail.com> That could be a lot of things. Without a network drawing and access to the devices to dig further it is difficult to say. On Thu, Mar 18, 2010 at 10:56 AM, Dennis Dayman wrote: > have a friend who has 21 floors of a building in DFW, multiple switches, etc and they started to have latency issues this weekend where half if not all packet are being dropped to folder shares, printers, etc. Suggestions on how they can troubleshoot that? call in a company to help identify it? > > -Dennis > > > > > From edgargvaldes at gmail.com Thu Mar 18 10:06:23 2010 From: edgargvaldes at gmail.com (Edgar Valdes) Date: Thu, 18 Mar 2010 08:06:23 -0700 Subject: Latency quesstion In-Reply-To: References: Message-ID: <3aa62fb01003180806y70927929pce25d65dd3b75d47@mail.gmail.com> Simplest would be to do a trace route from different sources or loop back interfaces to the servers/computers in question and see where latency starts spiking. this will at the very least point you to what device or devices are possibly over utilized. On Thu, Mar 18, 2010 at 7:56 AM, Dennis Dayman wrote: > have a friend who has 21 floors of a building in DFW, multiple switches, > etc and they started to have latency issues this weekend where half if not > all packet are being dropped to folder shares, printers, etc. Suggestions on > how they can troubleshoot that? call in a company to help identify it? > > -Dennis > > > > > From sob at academ.com Thu Mar 18 10:07:25 2010 From: sob at academ.com (Stan Barber) Date: Thu, 18 Mar 2010 10:07:25 -0500 Subject: IP4 Space In-Reply-To: <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> Message-ID: <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> I was not trying to say there would be a reduction in multihoming. I was trying to say that the rate of increase in non-NATed single-homing would increase faster than multihoming. I guess I was not very clear. Here is the basis for my assumptions since they are not clear: 1. Almost all home users (not businesses) that are connected to the Internet today via IPv4 are behind some kind of NAT box. In some cases, two NATs (one provided by the home user's router and one provided by some kind of ISP). There is no need for this using IPv6 to communicate with other IPv6 sites. 2. Almost all home users referenced above are not multi-homed today on IPv4. I am having a hard time believing that they will want to change that under IPv6. However, someone may have a case I have not thought about. Ergo, I believe their will be an increase in non-multihomed non-NATed endpoints as IPv6 becomes the standard way folks connect. Now, one thing that could negatively impact this would be providers that insist on providing some kind of IPv6/IPv6 NAT. Creating that kind of walled garden for IPv6 in the long term does not make alot of sense to me, but I am very interested in other points of view on that. On Mar 5, 2010, at 7:24 AM, William Herrin wrote: > On Thu, Mar 4, 2010 at 11:15 PM, David Conrad wrote: >> On Mar 4, 2010, at 2:30 PM, William Herrin wrote: >>> Because we expect far fewer end users to multihome tomorrow than do today? >> >> We do? >> >> Why do we expect this? > > David, > > Well, I don't know that "we" do, but Joel made a remarkable assertion > that non-aggregable assignments to end users, the ones still needed > for multihoming, would go down under IPv6. I wondered about his > reasoning. Stan then offered the surprising clarification that a > reduction in the use of NAT would naturally result in a reduction of > multihoming. > > Regards, > Bill > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From sfischer1967 at gmail.com Thu Mar 18 10:11:12 2010 From: sfischer1967 at gmail.com (Steven Fischer) Date: Thu, 18 Mar 2010 11:11:12 -0400 Subject: Latency quesstion In-Reply-To: References: Message-ID: <500ffb691003180811q43b28f8dx454e60e7e54440d9@mail.gmail.com> on of the first things I'd do is check interface statistics from the inter-connecting interfaces for errors. On Cisco switches, the command is fairly straight forward - show interface counters errors. All of the numbers should be low if things are operating well...if you see more than 100 errors on any given port, it is probably worth investigating. Question - are the floors connected by fiber or by copper? On Thu, Mar 18, 2010 at 10:56 AM, Dennis Dayman wrote: > have a friend who has 21 floors of a building in DFW, multiple switches, > etc and they started to have latency issues this weekend where half if not > all packet are being dropped to folder shares, printers, etc. Suggestions on > how they can troubleshoot that? call in a company to help identify it? > > -Dennis > > > > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From jason at biel-tech.com Thu Mar 18 10:13:21 2010 From: jason at biel-tech.com (Jason Biel) Date: Thu, 18 Mar 2010 10:13:21 -0500 Subject: Latency quesstion In-Reply-To: <3aa62fb01003180806y70927929pce25d65dd3b75d47@mail.gmail.com> References: <3aa62fb01003180806y70927929pce25d65dd3b75d47@mail.gmail.com> Message-ID: Check CPU levels on each switch, pull traffic logs of trunk ports, check syslogs for flapping ports or weird errors. I'd guess someone plugged something underneath their desk they shouldn't have. Jason On Thu, Mar 18, 2010 at 10:06 AM, Edgar Valdes wrote: > Simplest would be to do a trace route from different sources or loop back > interfaces to the servers/computers in question and see where latency > starts spiking. this will at the very least point you to what device or > devices are possibly over utilized. > > On Thu, Mar 18, 2010 at 7:56 AM, Dennis Dayman >wrote: > > > have a friend who has 21 floors of a building in DFW, multiple switches, > > etc and they started to have latency issues this weekend where half if > not > > all packet are being dropped to folder shares, printers, etc. Suggestions > on > > how they can troubleshoot that? call in a company to help identify it? > > > > -Dennis > > > > > > > > > > > -- Jason Biel From bruns at 2mbit.com Thu Mar 18 10:12:59 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 18 Mar 2010 15:12:59 +0000 Subject: Latency quesstion Message-ID: <2116781330-1268925231-cardhu_decombobulator_blackberry.rim.net-426036773-@bda895.bisx.prod.on.blackberry> Dennis, In large installations, I've always found it helpful when diagnosing LAN issues to isolate floors and departments first - using routers or with devices that can do transparent bridging. That way, you can walk through each dept/floor testing for the issues, and hopefully find only one location its still affecting. Its entirely likely that there's either a loop of some sort or a switch has gone off the deep end. If you'd like, let him know if he wants to drop me a mail, I can walk through details about the situation and hopefully help him narrow it down. ------Original Message------ From: Dennis Dayman To: nanog at nanog.org Subject: Latency quesstion Sent: Mar 18, 2010 7:56 AM have a friend who has 21 floors of a building in DFW, multiple switches, etc and they started to have latency issues this weekend where half if not all packet are being dropped to folder shares, printers, etc. Suggestions on how they can troubleshoot that? call in a company to help identify it? -Dennis -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From DStaal at usa.net Thu Mar 18 10:14:08 2010 From: DStaal at usa.net (Daniel Staal) Date: Thu, 18 Mar 2010 11:14:08 -0400 Subject: Hotmail/MSN email admin Message-ID: <323daf2ac9a202dc1feff1904a34b4eb.squirrel@www.magehandbook.com> If there are any Hotmail/MSN email admins on this list, could you please contact me offlist at Daniel.T.Staal at uscg.dhs.gov Thanks. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From Joel.Snyder at Opus1.COM Thu Mar 18 10:14:25 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Thu, 18 Mar 2010 08:14:25 -0700 Subject: Best VPN Appliance In-Reply-To: References: Message-ID: <4BA24351.7060700@opus1.com> > > Thank-you all for reply and sugessting the VPN Box.?? > I'm in the process of evaluating different boxes and they are;?? > > SA4500 SSL VPN Appliance? > http://www.juniper.net/us/en/products-services/security/sa-series/sa4500/?? > > Barracuda SSL VPN? > http://www.barracudanetworks.com/ns/products/sslvpn_overview.php > > F5 ??FirePass SSL VPN > ?http://www.f5.com/products/firepass/ > > The problem i'm facing so far is MAC OS X compatibility. The demo box i had for Juniper was not able to run Network Connect on MAC OS 10.5.8. The Juniper SSL VPN works great with Mac 10.6 (and prior versions going back about 5 years). I'm not sure what issue you might be seeing, but Network Connect is very solid in that environment. Secure Meeting also works fine on the Mac. The place where you will have compatibility issues is the end-point security checking, but this is common to all OS X. If you're not doing EPS checking, you don't care. If you are, you already know that Macs have a different set of software & vocabulary than Windows platforms. >>From your experience from F5, Juniper and Barracuda, which one will be best in terms of; > > 1) Support > 2) Resiliency > 3) Security > 4) Scalability > 5) Manageability The Barracuda box is very new and I haven't looked at it, but certainly the Juniper and F5 boxes are top contenders; you should also be looking at SonicWALL (which used to be Aventail). Your laundry list above is fairly vague, since you don't list YOUR requirements. However, I did a very extensive test of SSL VPN devices a few years ago which is still VERY applicable to the products that were in it. This is considered a fairly mature market, and the F5 box of today is not very different from the one of three years ago. You might consider figuring out what you want to do with the box, and then measuring the contenders against that, rather than asking "which is the most scalable," since in the NANOG context that could mean anything from "two-node active/active cluster" to "geographic clustering in 40 data centers." (Nick will at this point chime in with his now-famous "string analogy") Try reading this: http://www.networkworld.com/reviews/2005/121905-ssl-test-intro.html?rl It's dated 2005, so you can assume that annoying bugs are fixed, but product feature sets are very similar. There's also some more recent SSL VPN testing I've done in Network World, such as the Netgear box (not designed for the enterprise) and just last week the Microsoft one. Note that Network World writes for enterprises, and NANOG is a service provider mailing list, so depending on why you're asking for this, my results may or may not be applicable. For example, features like delegated and partitioned management, which are SP-critical but often ignored in the enterprise, weren't really part of my evaluation. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From mvh at hosteurope.de Thu Mar 18 10:15:20 2010 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Thu, 18 Mar 2010 16:15:20 +0100 Subject: Latency quesstion In-Reply-To: References: Message-ID: <4BA24388.1030301@hosteurope.de> Hi, Am 18.03.10 15:56 schrieb Dennis Dayman: > call in a company to help identify it? yes. Regards, Malte -- Malte von dem Hagen Teamleitung Network Engineering & Operation Abteilung Technik ----------------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de Welserstra?e 14 - 51149 K?ln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht K?ln - USt-IdNr.: DE187370678 Gesch?ftsf?hrer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulverm?ller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From LarrySheldon at cox.net Thu Mar 18 10:32:07 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Mar 2010 10:32:07 -0500 Subject: Latency quesstion In-Reply-To: <4BA241A2.3090406@cox.net> References: <4BA241A2.3090406@cox.net> Message-ID: <4BA24777.10004@cox.net> On 3/18/2010 10:07, Larry Sheldon wrote: > On 3/18/2010 09:56, Dennis Dayman wrote: >> have a friend who has 21 floors of a building in DFW, multiple >> switches, etc and they started to have latency issues this weekend >> where half if not all packet are being dropped to folder shares, >> printers, etc. Suggestions on how they can troubleshoot that? call in >> a company to help identify it? > > I'd start with a map of the network mark the routes (paths) that work. > > Then redraw the map without those paths and mark which stations talk to > which other stations. > > If that exercise discloses which equipment is broken, fix or replace it > and start over. > > If it does not, and no other you-can-do-it-yourself tests or analyses > come to mind, call for expensive help. > > (If they are competent, they will use an orderly analysis--that one is > my favorite--I call it sectionalization. I'm not bright enough to deal > with 21 floors. I have to sectionalize it to a particular horizontal or > vertical before I can figure where to start.) Have I been banned? -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From brandon.kim at brandontek.com Thu Mar 18 10:34:41 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 18 Mar 2010 11:34:41 -0400 Subject: Latency quesstion In-Reply-To: <2116781330-1268925231-cardhu_decombobulator_blackberry.rim.net-426036773-@bda895.bisx.prod.on.blackberry> References: <2116781330-1268925231-cardhu_decombobulator_blackberry.rim.net-426036773-@bda895.bisx.prod.on.blackberry> Message-ID: Dennis, You have a massive spanning tree issue....just kidding....check for that though.... Please update us more on your situation and if the other suggestions on the list helped. Or we can communicate privately, I love troubleshooting situations like this.... > To: nanog at nanog.org > Subject: Re: Latency quesstion > From: bruns at 2mbit.com > Date: Thu, 18 Mar 2010 15:12:59 +0000 > > Dennis, > > In large installations, I've always found it helpful when diagnosing LAN issues to isolate floors and departments first - using routers or with devices that can do transparent bridging. That way, you can walk through each dept/floor testing for the issues, and hopefully find only one location its still affecting. > > Its entirely likely that there's either a loop of some sort or a switch has gone off the deep end. > > If you'd like, let him know if he wants to drop me a mail, I can walk through details about the situation and hopefully help him narrow it down. > ------Original Message------ > From: Dennis Dayman > To: nanog at nanog.org > Subject: Latency quesstion > Sent: Mar 18, 2010 7:56 AM > > have a friend who has 21 floors of a building in DFW, multiple switches, etc and they started to have latency issues this weekend where half if not all packet are being dropped to folder shares, printers, etc. Suggestions on how they can troubleshoot that? call in a company to help identify it? > > -Dennis > > > > > > > -- > Brielle Bruns > http://www.sosdg.org / http://www.ahbl.org From dennis-lists at thenose.net Thu Mar 18 10:50:20 2010 From: dennis-lists at thenose.net (Dennis Dayman) Date: Thu, 18 Mar 2010 10:50:20 -0500 Subject: Latency quesstion In-Reply-To: References: Message-ID: Found a MAC address spewing stuff. looks like we have our culprit. thanks EVERYONE! -Dennis On Mar 18, 2010, at 9:56 AM, Dennis Dayman wrote: > have a friend who has 21 floors of a building in DFW, multiple switches, etc and they started to have latency issues this weekend where half if not all packet are being dropped to folder shares, printers, etc. Suggestions on how they can troubleshoot that? call in a company to help identify it? > > -Dennis > > > > > From jarenangerbauer at gmail.com Thu Mar 18 10:52:20 2010 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Thu, 18 Mar 2010 09:52:20 -0600 Subject: Using private APNIC range in US Message-ID: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Hi all, I have a client here in the US, that I just discovered is using a host of private IPs that (as I understand) belong to APNIC (i.e. 1.7.154.70, 1.7.154.00-99, etc.) for their web servers. I'm assuming that the addresses probably nat to a [US] public IP. I'm not familiar enough with the use of private address space outside of ARIN (i.e. 192.0.0.0, 10.0.0.0, etc) but I figure if their sites are up and accessible it must be working for them. I'm just wondering if there is any recommendation or practice around this -- using private IP ranges from another country. Thanks. --Jaren From brandon.kim at brandontek.com Thu Mar 18 11:00:05 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 18 Mar 2010 12:00:05 -0400 Subject: Latency quesstion In-Reply-To: References: , Message-ID: That was pretty quick. But what do you mean by spewing stuff? It would help the rest of us understand for possible future issues we may run into ourselves..... > Subject: Re: Latency quesstion > From: dennis-lists at thenose.net > Date: Thu, 18 Mar 2010 10:50:20 -0500 > To: nanog at nanog.org > > Found a MAC address spewing stuff. looks like we have our culprit. thanks EVERYONE! > > -Dennis > > On Mar 18, 2010, at 9:56 AM, Dennis Dayman wrote: > > > have a friend who has 21 floors of a building in DFW, multiple switches, etc and they started to have latency issues this weekend where half if not all packet are being dropped to folder shares, printers, etc. Suggestions on how they can troubleshoot that? call in a company to help identify it? > > > > -Dennis > > > > > > > > > > > > > From bfeeny at mac.com Thu Mar 18 11:03:49 2010 From: bfeeny at mac.com (Brian Feeny) Date: Thu, 18 Mar 2010 12:03:49 -0400 Subject: Latency quesstion In-Reply-To: <2116781330-1268925231-cardhu_decombobulator_blackberry.rim.net-426036773-@bda895.bisx.prod.on.blackberry> References: <2116781330-1268925231-cardhu_decombobulator_blackberry.rim.net-426036773-@bda895.bisx.prod.on.blackberry> Message-ID: <0A2BE2F7-025E-497A-9AC3-140DDED0BDAB@mac.com> Its also possible there are STP issues, so check where you roots are for the vlans and make sure they are deterministically set. Brian On Mar 18, 2010, at 11:12 AM, Brielle Bruns wrote: > Dennis, > > In large installations, I've always found it helpful when diagnosing LAN issues to isolate floors and departments first - using routers or with devices that can do transparent bridging. That way, you can walk through each dept/floor testing for the issues, and hopefully find only one location its still affecting. > > Its entirely likely that there's either a loop of some sort or a switch has gone off the deep end. > > If you'd like, let him know if he wants to drop me a mail, I can walk through details about the situation and hopefully help him narrow it down. > ------Original Message------ > From: Dennis Dayman > To: nanog at nanog.org > Subject: Latency quesstion > Sent: Mar 18, 2010 7:56 AM > > have a friend who has 21 floors of a building in DFW, multiple switches, etc and they started to have latency issues this weekend where half if not all packet are being dropped to folder shares, printers, etc. Suggestions on how they can troubleshoot that? call in a company to help identify it? > > -Dennis > > > > > > > -- > Brielle Bruns > http://www.sosdg.org / http://www.ahbl.org From michael.holstein at csuohio.edu Thu Mar 18 11:04:56 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 18 Mar 2010 12:04:56 -0400 Subject: Using private APNIC range in US In-Reply-To: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: <4BA24F28.9020804@csuohio.edu> > I have a client here in the US, that I just discovered is using a host > of private IPs that (as I understand) belong to APNIC (i.e. > 1.7.154.70, 1.7.154.00-99, etc.) for their web servers. Those aren't "private" IPs .. (in the RFC1918 sense) .. those are public IPs. They just weren't assigned until recently. > accessible it must be working for them. I'm just wondering if there > is any recommendation or practice around this -- using private IP > ranges from another country. Thanks. > > Since they're already using NAT, it shouldn't be hard to renumber them into the appropriate RFC1918 space. Cheers, Michael Holstein Cleveland State University From LarrySheldon at cox.net Thu Mar 18 11:11:09 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Mar 2010 11:11:09 -0500 Subject: Latency question In-Reply-To: References: , Message-ID: <4BA2509D.5020003@cox.net> On 3/18/2010 11:00, Brandon Kim wrote: > > That was pretty quick. > > > But what do you mean by spewing stuff? It would help the rest of us > understand for possible future issues we may run into ourselves..... Good question. Without thinking about it I saw in my mind's eye a situation we used to see at $EX-EMPLOYER (who was fond of the absolute smallest-dollar-amount-per-immediate-problem "solutions") who bout toy 4-port hubs by the pallet-load. These little gems had the endearing habit of spewing random bits onto the wire whenever the wall-wart failed--which they frequently did. I had MRTG graphs of every switch and router port so I could quickly determine which leg the current culprit was on. Never solved the problem of having two or three go bad, which, believe it or not, complicates the issue. But the graphs did allow me to identify the port and shut it down saving the rest of the network. > > > > >> Subject: Re: Latency quesstion From: dennis-lists at thenose.net Date: >> Thu, 18 Mar 2010 10:50:20 -0500 To: nanog at nanog.org >> >> Found a MAC address spewing stuff. looks like we have our culprit. >> thanks EVERYONE! >> >> -Dennis >> >> On Mar 18, 2010, at 9:56 AM, Dennis Dayman wrote: >> >>> have a friend who has 21 floors of a building in DFW, multiple >>> switches, etc and they started to have latency issues this >>> weekend where half if not all packet are being dropped to folder >>> shares, printers, etc. Suggestions on how they can troubleshoot >>> that? call in a company to help identify it? >>> >>> -Dennis >>> >>> >>> >>> >>> >> >> >> > -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From owen at delong.com Thu Mar 18 11:12:07 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Mar 2010 09:12:07 -0700 Subject: Using private APNIC range in US In-Reply-To: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: 1.0.0.0/8 is NOT private address space and never was. It was an arbitrary mis-use by your customer of space which is now part of the APNIC pool of addresses to issue in response to requests for new globally unique addresses. The result for your customer is that they've gotten away with treating it like RFC-1918 space (10/8, 172.16/12, 192.168/16) so far because there was no legitimate external use of that address. RFC-1918 in ARIN is the same as everywhere else. There is no region- specific aspect of it. What will happen if your customer does not renumber out of 1/8 is that there will be a portion of the internet rightfully using 1/8 that will be unreachable from your customer's internal systems and any requests to those legitimate hosts in 1/8 will be erroneously routed within your customer's premises. There are other possible issues if your cusotmer leaks DNS entries containing A records pointed towards 1/8 hosts as well. Hope that helps. Owen On Mar 18, 2010, at 8:52 AM, Jaren Angerbauer wrote: > Hi all, > > I have a client here in the US, that I just discovered is using a host > of private IPs that (as I understand) belong to APNIC (i.e. > 1.7.154.70, 1.7.154.00-99, etc.) for their web servers. I'm assuming > that the addresses probably nat to a [US] public IP. I'm not familiar > enough with the use of private address space outside of ARIN (i.e. > 192.0.0.0, 10.0.0.0, etc) but I figure if their sites are up and > accessible it must be working for them. I'm just wondering if there > is any recommendation or practice around this -- using private IP > ranges from another country. Thanks. > > --Jaren From dennis-lists at thenose.net Thu Mar 18 11:21:15 2010 From: dennis-lists at thenose.net (Dennis Dayman) Date: Thu, 18 Mar 2010 11:21:15 -0500 Subject: Latency quesstion In-Reply-To: References: , Message-ID: <709C4463-4548-499B-9BB8-B8A017E68E2A@thenose.net> yea, I'm working on that. will get back to you once he answers my IM I too would be interested for my own companies. -Dennis On Mar 18, 2010, at 11:00 AM, Brandon Kim wrote: > That was pretty quick. > > > But what do you mean by spewing stuff? It would help the rest of us understand for possible > future issues we may run into ourselves..... > > > > > > Subject: Re: Latency quesstion > > From: dennis-lists at thenose.net > > Date: Thu, 18 Mar 2010 10:50:20 -0500 > > To: nanog at nanog.org > > > > Found a MAC address spewing stuff. looks like we have our culprit. thanks EVERYONE! > > > > -Dennis > > > > On Mar 18, 2010, at 9:56 AM, Dennis Dayman wrote: > > > > > have a friend who has 21 floors of a building in DFW, multiple switches, etc and they started to have latency issues this weekend where half if not all packet are being dropped to folder shares, printers, etc. Suggestions on how they can troubleshoot that? call in a company to help identify it? > > > > > > -Dennis > > > > > > > > > > > > > > > > > > > > > From jarenangerbauer at gmail.com Thu Mar 18 11:22:40 2010 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Thu, 18 Mar 2010 10:22:40 -0600 Subject: Using private APNIC range in US In-Reply-To: References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: <4c6b8c911003180922j426f6e94g37eb772210a249f8@mail.gmail.com> Thanks all for the on / off list responses on this. I acknowledge I'm playing in territory I'm not familiar with, and was a bad idea to jump to the conclusion that this range was private. I made that assumption originally because the entire /8 was owned by APNIC, and just figured since the registrar owned them, it must have been a private range. :S It sounds like this range was just recently assigned -- is there any document (RFC?) or source I could look through to learn more about this, and/or provide evidence to my client? Thanks, Jaren From LarrySheldon at cox.net Thu Mar 18 11:03:03 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Mar 2010 11:03:03 -0500 Subject: Using private APNIC range in US In-Reply-To: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: <4BA24EB7.3060807@cox.net> On 3/18/2010 10:52, Jaren Angerbauer wrote: > Hi all, > > I have a client here in the US, that I just discovered is using a host > of private IPs that (as I understand) belong to APNIC (i.e. > 1.7.154.70, 1.7.154.00-99, etc.) for their web servers. I'm assuming > that the addresses probably nat to a [US] public IP. I'm not familiar > enough with the use of private address space outside of ARIN (i.e. > 192.0.0.0, 10.0.0.0, etc) but I figure if their sites are up and > accessible it must be working for them. I'm just wondering if there > is any recommendation or practice around this -- using private IP > ranges from another country. Thanks. I think the correct term is "pirated addresses" or maybe "Hijacked addresses". RFC 1918 applies world wide. I don'r ever advocate any kind of antisocial behaviour. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Thu Mar 18 11:30:55 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Mar 2010 11:30:55 -0500 Subject: Using private APNIC range in US In-Reply-To: <4c6b8c911003180922j426f6e94g37eb772210a249f8@mail.gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <4c6b8c911003180922j426f6e94g37eb772210a249f8@mail.gmail.com> Message-ID: <4BA2553F.9070500@cox.net> On 3/18/2010 11:22, Jaren Angerbauer wrote: > It sounds like this range was just recently assigned -- is there any > document (RFC?) or source I could look through to learn more about > this, and/or provide evidence to my client? See related traffic on this list, for openers. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From brandon.kim at brandontek.com Thu Mar 18 11:30:55 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 18 Mar 2010 12:30:55 -0400 Subject: Latency question In-Reply-To: <4BA2509D.5020003@cox.net> References: , , , , <4BA2509D.5020003@cox.net> Message-ID: Isn't it amazing that one can be so cheap it ends up biting them in the arse? There's a difference between frugal and cheap. Being cheap comes back to you, it's like Karma.... > Date: Thu, 18 Mar 2010 11:11:09 -0500 > From: LarrySheldon at cox.net > To: nanog at nanog.org > Subject: Re: Latency question > > On 3/18/2010 11:00, Brandon Kim wrote: > > > > That was pretty quick. > > > > > > But what do you mean by spewing stuff? It would help the rest of us > > understand for possible future issues we may run into ourselves..... > > Good question. Without thinking about it I saw in my mind's eye a > situation we used to see at $EX-EMPLOYER (who was fond of the absolute > smallest-dollar-amount-per-immediate-problem "solutions") who bout toy > 4-port hubs by the pallet-load. > > These little gems had the endearing habit of spewing random bits onto > the wire whenever the wall-wart failed--which they frequently did. > > I had MRTG graphs of every switch and router port so I could quickly > determine which leg the current culprit was on. > > Never solved the problem of having two or three go bad, which, believe > it or not, complicates the issue. > > But the graphs did allow me to identify the port and shut it down saving > the rest of the network. > > > > > > > > > >> Subject: Re: Latency quesstion From: dennis-lists at thenose.net Date: > >> Thu, 18 Mar 2010 10:50:20 -0500 To: nanog at nanog.org > >> > >> Found a MAC address spewing stuff. looks like we have our culprit. > >> thanks EVERYONE! > >> > >> -Dennis > >> > >> On Mar 18, 2010, at 9:56 AM, Dennis Dayman wrote: > >> > >>> have a friend who has 21 floors of a building in DFW, multiple > >>> switches, etc and they started to have latency issues this > >>> weekend where half if not all packet are being dropped to folder > >>> shares, printers, etc. Suggestions on how they can troubleshoot > >>> that? call in a company to help identify it? > >>> > >>> -Dennis > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > > -- > Democracy: Three wolves and a sheep voting on the dinner menu. > (A republic, using parliamentary law, protects the minority.) > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > From fred at cisco.com Thu Mar 18 11:34:47 2010 From: fred at cisco.com (Fred Baker) Date: Thu, 18 Mar 2010 09:34:47 -0700 Subject: Using private APNIC range in US In-Reply-To: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: Are they using them only within their domain(s), and ARIN addresses outside, or are they advertising them to their upstream(s) to be readvertised into the backbone? If they are using them internally and NAT'ing to the outside, they're not hurting themselves or anyone else. I would personally let them alone. If they are advertising them outside, it adds a small prefix in the ARIN domain that doesn't get aggregated by the upstream. Among 300K such prefixes it is probably noise, but gently suggesting that they use something aggregatable into their upstream's allocation would help a little bit in that regard. What they are most likely hurting is themselves, really; a datagram sent to the address from an ISP outside themselves probably travels via Australia or an Australian ISP. On Mar 18, 2010, at 8:52 AM, Jaren Angerbauer wrote: > Hi all, > > I have a client here in the US, that I just discovered is using a host > of private IPs that (as I understand) belong to APNIC (i.e. > 1.7.154.70, 1.7.154.00-99, etc.) for their web servers. I'm assuming > that the addresses probably nat to a [US] public IP. I'm not familiar > enough with the use of private address space outside of ARIN (i.e. > 192.0.0.0, 10.0.0.0, etc) but I figure if their sites are up and > accessible it must be working for them. I'm just wondering if there > is any recommendation or practice around this -- using private IP > ranges from another country. Thanks. > > --Jaren > http://www.ipinc.net/IPv4.GIF From brandon.kim at brandontek.com Thu Mar 18 11:39:02 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 18 Mar 2010 12:39:02 -0400 Subject: Latency quesstion In-Reply-To: <709C4463-4548-499B-9BB8-B8A017E68E2A@thenose.net> References: , , <709C4463-4548-499B-9BB8-B8A017E68E2A@thenose.net> Message-ID: Great! looking forward to it...... Subject: Re: Latency quesstion From: dennis-lists at thenose.net Date: Thu, 18 Mar 2010 11:21:15 -0500 CC: nanog at nanog.org To: brandon.kim at brandontek.com yea, I'm working on that. will get back to you once he answers my IM I too would be interested for my own companies. -Dennis On Mar 18, 2010, at 11:00 AM, Brandon Kim wrote:That was pretty quick. But what do you mean by spewing stuff? It would help the rest of us understand for possible future issues we may run into ourselves..... > Subject: Re: Latency quesstion > From: dennis-lists at thenose.net > Date: Thu, 18 Mar 2010 10:50:20 -0500 > To: nanog at nanog.org > > Found a MAC address spewing stuff. looks like we have our culprit. thanks EVERYONE! > > -Dennis > > On Mar 18, 2010, at 9:56 AM, Dennis Dayman wrote: > > > have a friend who has 21 floors of a building in DFW, multiple switches, etc and they started to have latency issues this weekend where half if not all packet are being dropped to folder shares, printers, etc. Suggestions on how they can troubleshoot that? call in a company to help identify it? > > > > -Dennis > > > > > > > > > > > > > From cian.brennan at redbrick.dcu.ie Thu Mar 18 11:42:53 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Thu, 18 Mar 2010 16:42:53 +0000 Subject: Using private APNIC range in US In-Reply-To: References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: <20100318164253.GA1768@minerva.redbrick.dcu.ie> On Thu, Mar 18, 2010 at 09:34:47AM -0700, Fred Baker wrote: > Are they using them only within their domain(s), and ARIN addresses outside, or are they advertising them to their upstream(s) to be readvertised into the backbone? > > If they are using them internally and NAT'ing to the outside, they're not hurting themselves or anyone else. I would personally let them alone. > Right up until someone actually starts *using* 1/8, in which case they're hurting both themslves, and who ever gets stuck with it. > If they are advertising them outside, it adds a small prefix in the ARIN domain that doesn't get aggregated by the upstream. Among 300K such prefixes it is probably noise, but gently suggesting that they use something aggregatable into their upstream's allocation would help a little bit in that regard. What they are most likely hurting is themselves, really; a datagram sent to the address from an ISP outside themselves probably travels via Australia or an Australian ISP. > > On Mar 18, 2010, at 8:52 AM, Jaren Angerbauer wrote: > > > Hi all, > > > > I have a client here in the US, that I just discovered is using a host > > of private IPs that (as I understand) belong to APNIC (i.e. > > 1.7.154.70, 1.7.154.00-99, etc.) for their web servers. I'm assuming > > that the addresses probably nat to a [US] public IP. I'm not familiar > > enough with the use of private address space outside of ARIN (i.e. > > 192.0.0.0, 10.0.0.0, etc) but I figure if their sites are up and > > accessible it must be working for them. I'm just wondering if there > > is any recommendation or practice around this -- using private IP > > ranges from another country. Thanks. > > > > --Jaren > > > > http://www.ipinc.net/IPv4.GIF > > > -- -- From LarrySheldon at cox.net Thu Mar 18 10:07:14 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Mar 2010 10:07:14 -0500 Subject: Latency quesstion In-Reply-To: References: Message-ID: <4BA241A2.3090406@cox.net> On 3/18/2010 09:56, Dennis Dayman wrote: > have a friend who has 21 floors of a building in DFW, multiple > switches, etc and they started to have latency issues this weekend > where half if not all packet are being dropped to folder shares, > printers, etc. Suggestions on how they can troubleshoot that? call in > a company to help identify it? I'd start with a map of the network mark the routes (paths) that work. Then redraw the map without those paths and mark which stations talk to which other stations. If that exercise discloses which equipment is broken, fix or replace it and start over. If it does not, and no other you-can-do-it-yourself tests or analyses come to mind, call for expensive help. (If they are competent, they will use an orderly analysis--that one is my favorite--I call it sectionalization. I'm not bright enough to deal with 21 floors. I have to sectionalize it to a particular horizontal or vertical before I can figure where to start.) -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Thu Mar 18 11:48:31 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Mar 2010 11:48:31 -0500 Subject: Latency quesstion In-Reply-To: <4BA241A2.3090406@cox.net> References: <4BA241A2.3090406@cox.net> Message-ID: <4BA2595F.4070801@cox.net> On 3/18/2010 10:07, Larry Sheldon wrote: > On 3/18/2010 09:56, Dennis Dayman wrote: >> have a friend who has 21 floors of a building in DFW, multiple >> switches, etc and they started to have latency issues this weekend >> where half if not all packet are being dropped to folder shares, >> printers, etc. Suggestions on how they can troubleshoot that? call in >> a company to help identify it? > > I'd start with a map of the network mark the routes (paths) that work. It would be interesting to know where this message has been for an hour and a half. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From tom.ammon at utah.edu Thu Mar 18 11:48:52 2010 From: tom.ammon at utah.edu (Tom Ammon) Date: Thu, 18 Mar 2010 10:48:52 -0600 Subject: Using private APNIC range in US In-Reply-To: <4c6b8c911003180922j426f6e94g37eb772210a249f8@mail.gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <4c6b8c911003180922j426f6e94g37eb772210a249f8@mail.gmail.com> Message-ID: <4BA25974.9060504@utah.edu> RFC1918 is a good place to start ;) On 3/18/2010 10:22 AM, Jaren Angerbauer wrote: > Thanks all for the on / off list responses on this. I acknowledge I'm > playing in territory I'm not familiar with, and was a bad idea to jump > to the conclusion that this range was private. I made that assumption > originally because the entire /8 was owned by APNIC, and just figured > since the registrar owned them, it must have been a private range. :S > > It sounds like this range was just recently assigned -- is there any > document (RFC?) or source I could look through to learn more about > this, and/or provide evidence to my client? > > Thanks, > > Jaren > > -- -------------------------------------------------------------------- Tom Ammon Network Engineer Office: 801.587.0976 Mobile: 801.674.9273 Center for High Performance Computing University of Utah http://www.chpc.utah.edu From ravi at cow.org Thu Mar 18 11:59:21 2010 From: ravi at cow.org (Ravi Pina) Date: Thu, 18 Mar 2010 12:59:21 -0400 Subject: Latency quesstion In-Reply-To: <4BA2595F.4070801@cox.net> References: <4BA241A2.3090406@cox.net> <4BA2595F.4070801@cox.net> Message-ID: <20100318165921.GT69741@neu.cow.org> On Thu, Mar 18, 2010 at 11:48:31AM -0500, Larry Sheldon wrote: > It would be interesting to know where this message has been for an hour > and a half. Stuck in the NSA's queues? -r From dwhite at olp.net Thu Mar 18 12:06:26 2010 From: dwhite at olp.net (Dan White) Date: Thu, 18 Mar 2010 12:06:26 -0500 Subject: Latency quesstion In-Reply-To: <4BA2595F.4070801@cox.net> References: <4BA241A2.3090406@cox.net> <4BA2595F.4070801@cox.net> Message-ID: <20100318170625.GE4916@dan.olp.net> On 18/03/10?11:48?-0500, Larry Sheldon wrote: >On 3/18/2010 10:07, Larry Sheldon wrote: >> On 3/18/2010 09:56, Dennis Dayman wrote: >>> have a friend who has 21 floors of a building in DFW, multiple >>> switches, etc and they started to have latency issues this weekend >>> where half if not all packet are being dropped to folder shares, >>> printers, etc. Suggestions on how they can troubleshoot that? call in >>> a company to help identify it? >> >> I'd start with a map of the network mark the routes (paths) that work. > >It would be interesting to know where this message has been for an hour >and a half. Received: from localhost ([::1] helo=s0.nanog.org) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NsIqy-0007si-VK; Thu, 18 Mar 2010 16:45:49 +0000 Received: from eastrmpop110.cox.net ([68.230.240.52]) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NsIq7-00072X-DV for nanog at nanog.org; Thu, 18 Mar 2010 16:44:56 +0000 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao107.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20100318150713.FCRZ18765.eastrmmtao107.cox.net at eastrmimpo01.cox.net> for ; Thu, 18 Mar 2010 11:07:13 -0400 Received: from [192.168.1.202] ([68.229.170.168]) by eastrmimpo01.cox.net with bizsmtp id uf7E1d00F3eLnoL02f7F7u; Thu, 18 Mar 2010 11:07:15 -0400 -- Dan White From LarrySheldon at cox.net Thu Mar 18 12:12:38 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Mar 2010 12:12:38 -0500 Subject: Latency quesstion In-Reply-To: <20100318170625.GE4916@dan.olp.net> References: <4BA241A2.3090406@cox.net> <4BA2595F.4070801@cox.net> <20100318170625.GE4916@dan.olp.net> Message-ID: <4BA25F06.1020903@cox.net> On 3/18/2010 12:06, Dan White wrote: > On 18/03/10 11:48 -0500, Larry Sheldon wrote: >> On 3/18/2010 10:07, Larry Sheldon wrote: >>> On 3/18/2010 09:56, Dennis Dayman wrote: >>>> have a friend who has 21 floors of a building in DFW, multiple >>>> switches, etc and they started to have latency issues this weekend >>>> where half if not all packet are being dropped to folder shares, >>>> printers, etc. Suggestions on how they can troubleshoot that? call in >>>> a company to help identify it? >>> >>> I'd start with a map of the network mark the routes (paths) that work. >> >> It would be interesting to know where this message has been for an hour >> and a half. > > Received: from localhost ([::1] helo=s0.nanog.org) > by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) > (envelope-from ) > id 1NsIqy-0007si-VK; Thu, 18 Mar 2010 16:45:49 +0000 > Received: from eastrmpop110.cox.net ([68.230.240.52]) > by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) > (envelope-from ) id 1NsIq7-00072X-DV > for nanog at nanog.org; Thu, 18 Mar 2010 16:44:56 +0000 > Received: from eastrmimpo01.cox.net ([68.1.16.119]) > by eastrmmtao107.cox.net > (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id > <20100318150713.FCRZ18765.eastrmmtao107.cox.net at eastrmimpo01.cox.net> > for ; Thu, 18 Mar 2010 11:07:13 -0400 > Received: from [192.168.1.202] ([68.229.170.168]) > by eastrmimpo01.cox.net with bizsmtp > id uf7E1d00F3eLnoL02f7F7u; Thu, 18 Mar 2010 11:07:15 -0400 That _is_ interesting! I wonder if there is a way to get to those headers from Thunderbird. Not much else works and I didn't even think to try. My bad. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Thu Mar 18 12:16:06 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Mar 2010 12:16:06 -0500 Subject: Latency quesstion In-Reply-To: <4BA25F06.1020903@cox.net> References: <4BA241A2.3090406@cox.net> <4BA2595F.4070801@cox.net> <20100318170625.GE4916@dan.olp.net> <4BA25F06.1020903@cox.net> Message-ID: <4BA25FD6.7080305@cox.net> On 3/18/2010 12:12, Larry Sheldon wrote: > On 3/18/2010 12:06, Dan White wrote: [previous comments and header display] > That _is_ interesting! > > I wonder if there is a way to get to those headers from Thunderbird. > Not much else works and I didn't even think to try. > > My bad. It does work (takes a bit of poking to find them, but it does work). My very bad. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jof at thejof.com Thu Mar 18 12:16:21 2010 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 18 Mar 2010 10:16:21 -0700 Subject: Using private APNIC range in US In-Reply-To: <4c6b8c911003180922j426f6e94g37eb772210a249f8@mail.gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <4c6b8c911003180922j426f6e94g37eb772210a249f8@mail.gmail.com> Message-ID: <1268932018-sup-3407@sfo.thejof.com> Excerpts from Jaren Angerbauer's message of Thu Mar 18 09:22:40 -0700 2010: > Thanks all for the on / off list responses on this. I acknowledge I'm > playing in territory I'm not familiar with, and was a bad idea to jump > to the conclusion that this range was private. I made that assumption > originally because the entire /8 was owned by APNIC, and just figured > since the registrar owned them, it must have been a private range. :S > > It sounds like this range was just recently assigned -- is there any > document (RFC?) or source I could look through to learn more about > this, and/or provide evidence to my client? There's a couple of relevant documents you could refer them to: IANA's IPv4 Address Space Registry ( http://www.iana.org/assignments/ipv4-address-space/ ), which will show you a listing of which registries and various entities are assigned /8 chunks of IPv4 space. There's some interesting names and historical registrations in there (including 1.0.0.0/8's recent allocation to APNIC) There's also an RFC, RFC1918 that sets aside some IPv4 space for private, ad-hoc use. http://www.faqs.org/rfcs/rfc1918.html This is also a good lay reference: http://en.wikipedia.org/wiki/Private_network Have fun, jof From michael.holstein at csuohio.edu Thu Mar 18 12:29:29 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 18 Mar 2010 13:29:29 -0400 Subject: Latency quesstion In-Reply-To: <4BA25F06.1020903@cox.net> References: <4BA241A2.3090406@cox.net> <4BA2595F.4070801@cox.net> <20100318170625.GE4916@dan.olp.net> <4BA25F06.1020903@cox.net> Message-ID: <4BA262F9.3040805@csuohio.edu> > I wonder if there is a way to get to those headers from Thunderbird. > Not much else works and I didn't even think to try. > Ctrl + U (or "View" and then "Message source"). As an aside .. we see this all the time with some of the cable providers (we have both Cox and TWC here in Cleveland) when investigating wrongly-placed blame for "missing" or "delayed" emails. One server at TWC (which still has an *.adelphia.net name) in particular seemed to hold messages for the default retry interval 100% of the time (misconfigured greylisting?). Cheers, Michael Holstein Cleveland State University From nonobvious at gmail.com Thu Mar 18 13:16:09 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 18 Mar 2010 11:16:09 -0700 Subject: IPv6 in Education Question In-Reply-To: <4e913c5d1003172039id15ba75k2fa5fb85be3f26e3@mail.gmail.com> References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> <1268868062.5727.652.camel@karl> <4e913c5d1003172039id15ba75k2fa5fb85be3f26e3@mail.gmail.com> Message-ID: <18a5e7cb1003181116g2d26b169yfcad480c8e2a044a@mail.gmail.com> You're either going to have to sell them on future-proofing or "We're sailing off the edge of the world in two years, there be dragons there, train your folks now." Remember that there are two IPv6 transitions - introducing IPv6 and forcing some people onto it - getting rid of IPv4 after IPv6 support is universal. > Death of NAT NAT's not going away for a long time - IPv6 doesn't need it for address space conservation, and pretends not to need it very much for renumbering IPv6 to IPv6, but it's widely used as a firewall substitute and administrative convenience. The first IPv6 transition will eliminate some NAT in pure-v6 environments, so there will be applications that are no longer broken and can Just Work, but it'll also introduce several different flavors of IPv4-to-IPv6 NATs/tunnels/etc., so there are other applications that will get broken in new and creative ways. The second IPv6 transition may really finish eliminating NAT, but that won't be for *years*, and you'll need to get all your users deeply involved in IPv6 long before that. Other than networking research and networking-related training, there really aren't education-specific applications of IPv6; there are just sites that you can or can't reach with IPv4 or IPv6. Any big commercial sites will stay reachable with IPv4 for a long time, certainly until IPv6 has been well established for a couple of years, and while there may be new content that's IPv6 only after a while, commercial content sites are more likely to buy IPv4 space if they need it. And most educational sites big enough to be Really Cool already have enough IPv4 space to last a few years, though they may very well start adding IPv6 connectivity just like commercial sites will. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From tony at hoyle.me.uk Thu Mar 18 13:23:10 2010 From: tony at hoyle.me.uk (Tony Hoyle) Date: Thu, 18 Mar 2010 18:23:10 +0000 Subject: IPv6 in Education Question In-Reply-To: <18a5e7cb1003181116g2d26b169yfcad480c8e2a044a@mail.gmail.com> References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> <1268868062.5727.652.camel@karl> <4e913c5d1003172039id15ba75k2fa5fb85be3f26e3@mail.gmail.com> <18a5e7cb1003181116g2d26b169yfcad480c8e2a044a@mail.gmail.com> Message-ID: <4BA26F8E.2030705@hoyle.me.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/03/2010 18:16, Bill Stewart wrote: > You're either going to have to sell them on future-proofing or > "We're sailing off the edge of the world in two years, > there be dragons there, train your folks now." Most students starting this year will be graduating in 3-4 years time, in a world where IANA depletion will almost certainly have happened and RIR depletion will either have happened or about to happen. If they don't have a working knowledge of ipv6 at that point then they're going to find getting employment a lot tougher. Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLom+OAAoJEJ1qCQ6ePCDUXq8IAJuNSJRJWtVWycsvMiAlE3fv /ZE8WCH0Jeu56l43Jg7QKf85Sad5dV9fxvsM5+cVXKaGHrPV+z+nFQcXA8RIbsvf lEdZFCK/krMUrWmM0mIEAqlB3FZ64L5xI4EqujRgoUVINToAgC3WR2PHXMf07eRn xYeyw+thiC3XYZNEjCJUwNKdH1N6brvsQ7otmZZrgoyO7J9dQAKEccUtc5euR84j kKO7wn+0LCtUqryM1uE+adBOIlWQG7+3WiaVXICMgKRCuYG/17vY4jec/xHgn3vh Wq98kpddrsmWPib6ezdo9yVFL2j0idoSkJ/s/5zjzKoREmWYBb2viYiL6hoX5w0= =ZWSF -----END PGP SIGNATURE----- From if at xip.at Thu Mar 18 13:25:51 2010 From: if at xip.at (Ingo Flaschberger) Date: Thu, 18 Mar 2010 19:25:51 +0100 (CET) Subject: cisco as pptp client Message-ID: Hi, I'm searching a working (if possible) configuration for a cisco 1841 as pptp-client. 1841 should do an pptp dialin to another cisco via ethernet-port. Kind regards, Ingo Flaschberger From owen at delong.com Thu Mar 18 13:25:15 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Mar 2010 11:25:15 -0700 Subject: Using private APNIC range in US In-Reply-To: References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: On Mar 18, 2010, at 9:34 AM, Fred Baker wrote: > Are they using them only within their domain(s), and ARIN addresses outside, or are they advertising them to their upstream(s) to be readvertised into the backbone? > > If they are using them internally and NAT'ing to the outside, they're not hurting themselves or anyone else. I would personally let them alone. > Except you're missing a keyword on the "not hurting themselves" part of that... It's "YET". Once 1.0.0.0/8 starts getting used in the wild for legitimate sites, it means that this customer won't be able to reach the legitimate 1.0.0.0/8 sites from within their environment and it won't be immediately intuitive to debug the failures. > If they are advertising them outside, it adds a small prefix in the ARIN domain that doesn't get aggregated by the upstream. Among 300K such prefixes it is probably noise, but gently suggesting that they use something aggregatable into their upstream's allocation would help a little bit in that regard. What they are most likely hurting is themselves, really; a datagram sent to the address from an ISP outside themselves probably travels via Australia or an Australian ISP. > The route announcement notwithstanding, they're using space that does not belong to them and will belong to someone else in the near future. If you think that is OK, please let me know what your addresses are so that I can start re-using them. Owen > On Mar 18, 2010, at 8:52 AM, Jaren Angerbauer wrote: > >> Hi all, >> >> I have a client here in the US, that I just discovered is using a host >> of private IPs that (as I understand) belong to APNIC (i.e. >> 1.7.154.70, 1.7.154.00-99, etc.) for their web servers. I'm assuming >> that the addresses probably nat to a [US] public IP. I'm not familiar >> enough with the use of private address space outside of ARIN (i.e. >> 192.0.0.0, 10.0.0.0, etc) but I figure if their sites are up and >> accessible it must be working for them. I'm just wondering if there >> is any recommendation or practice around this -- using private IP >> ranges from another country. Thanks. >> >> --Jaren >> > > http://www.ipinc.net/IPv4.GIF > From jared at puck.nether.net Thu Mar 18 13:35:29 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 18 Mar 2010 14:35:29 -0400 Subject: Using private APNIC range in US In-Reply-To: References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: On Mar 18, 2010, at 2:25 PM, Owen DeLong wrote: > > On Mar 18, 2010, at 9:34 AM, Fred Baker wrote: > >> Are they using them only within their domain(s), and ARIN addresses outside, or are they advertising them to their upstream(s) to be readvertised into the backbone? >> >> If they are using them internally and NAT'ing to the outside, they're not hurting themselves or anyone else. I would personally let them alone. >> > Except you're missing a keyword on the "not hurting themselves" part of that... It's "YET". > > Once 1.0.0.0/8 starts getting used in the wild for legitimate sites, it means that this > customer won't be able to reach the legitimate 1.0.0.0/8 sites from within their > environment and it won't be immediately intuitive to debug the failures. > >> If they are advertising them outside, it adds a small prefix in the ARIN domain that doesn't get aggregated by the upstream. Among 300K such prefixes it is probably noise, but gently suggesting that they use something aggregatable into their upstream's allocation would help a little bit in that regard. What they are most likely hurting is themselves, really; a datagram sent to the address from an ISP outside themselves probably travels via Australia or an Australian ISP. >> > The route announcement notwithstanding, they're using space that does not > belong to them and will belong to someone else in the near future. If you > think that is OK, please let me know what your addresses are so that I can > start re-using them. Does anyone know if the University of Michigan or Cisco are going be updating their systems and documentation to no longer use 1.2.3.4 ? http://www.google.com/search?q=1.2.3.4+site%3Acisco.com I know that the University of Michigan utilize 1.2.3.4 for their captive portal login/logout pages as recently as monday when I was on the medical campus. - Jared From dts at senie.com Thu Mar 18 13:50:11 2010 From: dts at senie.com (Daniel Senie) Date: Thu, 18 Mar 2010 14:50:11 -0400 Subject: Using private APNIC range in US In-Reply-To: References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: <80CC32C4-649A-4214-AD76-FE2F098F9544@senie.com> On Mar 18, 2010, at 2:25 PM, Owen DeLong wrote: > > On Mar 18, 2010, at 9:34 AM, Fred Baker wrote: > >> Are they using them only within their domain(s), and ARIN addresses outside, or are they advertising them to their upstream(s) to be readvertised into the backbone? >> >> If they are using them internally and NAT'ing to the outside, they're not hurting themselves or anyone else. I would personally let them alone. >> > Except you're missing a keyword on the "not hurting themselves" part of that... It's "YET". > > Once 1.0.0.0/8 starts getting used in the wild for legitimate sites, it means that this > customer won't be able to reach the legitimate 1.0.0.0/8 sites from within their > environment and it won't be immediately intuitive to debug the failures. While the analysis above is correct, the original poster talked about the 1/8 addressing being used on web server farms with translation of incoming connections. Sounds like load balancers using 1/8 for the addresses behind them and on the servers that are providing the service. As such, prospective users of the web site(s) provided by the outfit will not function for broadband users and such who get allocated addresses from 1/8. Reality of course is that both are true, but in terms of "who gets hurt" the issue here may well be a large server farm that is inaccessible from consumer networks in places in Asia. As you note, debugging this type of thing is often not intuitive, as everything appears to work from almost everywhere. > >> If they are advertising them outside, it adds a small prefix in the ARIN domain that doesn't get aggregated by the upstream. Among 300K such prefixes it is probably noise, but gently suggesting that they use something aggregatable into their upstream's allocation would help a little bit in that regard. What they are most likely hurting is themselves, really; a datagram sent to the address from an ISP outside themselves probably travels via Australia or an Australian ISP. >> > The route announcement notwithstanding, they're using space that does not > belong to them and will belong to someone else in the near future. If you > think that is OK, please let me know what your addresses are so that I can > start re-using them. A scenario repeated many times over the years. In the 1990s, it was common to see leakage of the address blocks of vendors that were used in documentation for routers, workstations, etc., as people would look at examples in the manual, and use the exact IP addresses shown, not understanding the "go get your own addresses first" part of the process. > > Owen > >> On Mar 18, 2010, at 8:52 AM, Jaren Angerbauer wrote: >> >>> Hi all, >>> >>> I have a client here in the US, that I just discovered is using a host >>> of private IPs that (as I understand) belong to APNIC (i.e. >>> 1.7.154.70, 1.7.154.00-99, etc.) for their web servers. I'm assuming >>> that the addresses probably nat to a [US] public IP. I'm not familiar >>> enough with the use of private address space outside of ARIN (i.e. >>> 192.0.0.0, 10.0.0.0, etc) but I figure if their sites are up and >>> accessible it must be working for them. I'm just wondering if there >>> is any recommendation or practice around this -- using private IP >>> ranges from another country. Thanks. >>> >>> --Jaren >>> >> >> http://www.ipinc.net/IPv4.GIF >> > > From ghicks at hicks-net.net Thu Mar 18 14:12:08 2010 From: ghicks at hicks-net.net (Gregory Hicks) Date: Thu, 18 Mar 2010 12:12:08 -0700 (PDT) Subject: Latency quesstion Message-ID: <201003181912.o2IJC8lW027169@metis.hicks-net.net> > X-VR-Score: -70.00 > Date: Thu, 18 Mar 2010 11:48:31 -0500 > From: Larry Sheldon > To: nanog at nanog.org > Subject: Re: Latency quesstion > > On 3/18/2010 10:07, Larry Sheldon wrote: > > On 3/18/2010 09:56, Dennis Dayman wrote: > >> have a friend who has 21 floors of a building in DFW, multiple [...] > > It would be interesting to know where this message has been for an hour > and a half. It looks like it was stuck on machine eastrmpop110.cox.net for a while: Received: from eastrmpop110.cox.net ([68.230.240.52]) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1NsIq7-00072X-DV for nanog at nanog.org; Thu, 18 Mar 2010 16:44:56 +0000 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao107.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20100318150713.FCRZ18765.eastrmmtao107.cox.net at eastrmimpo01.cox.net> for ; Thu, 18 Mar 2010 11:07:13 -0400 It didn't waste any time getting from you to eastrmimpop01.cox.net but took about 45 minutes to get off of eastrmpop110.cox.net. That backlog has most probably been cleared up by now. Regards, Gregory Hicks --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton From bill at herrin.us Thu Mar 18 14:25:43 2010 From: bill at herrin.us (William Herrin) Date: Thu, 18 Mar 2010 15:25:43 -0400 Subject: IP4 Space In-Reply-To: <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> Message-ID: <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> > On Mar 5, 2010, at 7:24 AM, William Herrin wrote: >> Joel made a remarkable assertion >> that non-aggregable assignments to end users, the ones still needed >> for multihoming, would go down under IPv6. I wondered about his >> reasoning. Stan then offered the surprising clarification that a >> reduction in the use of NAT would naturally result in a reduction of >> multihoming. On Thu, Mar 18, 2010 at 11:07 AM, Stan Barber wrote: > I was not trying to say there would be a reduction in multihoming. I was > trying to say that the rate of increase in non-NATed single-homing > would increase faster than multihoming. I guess I was not very clear. Hi Stan, Your logic still escapes me. Network-wise there's not a lot of difference between a single-homed IPv4 /32 and a single-homed IPv6 /56. Host-wise there may be a difference but why would you expect that to impact networks? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From william.allen.simpson at gmail.com Thu Mar 18 14:30:39 2010 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 18 Mar 2010 15:30:39 -0400 Subject: Using private APNIC range in US In-Reply-To: References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: <4BA27F5F.1050607@gmail.com> On 3/18/10 2:35 PM, Jared Mauch wrote: > Does anyone know if the University of Michigan or Cisco are going be updating their systems and documentation to no longer use 1.2.3.4 ? > > http://www.google.com/search?q=1.2.3.4+site%3Acisco.com > > I know that the University of Michigan utilize 1.2.3.4 for their captive portal login/logout pages as recently as monday when I was on the medical campus. > Dunno about cisco. med.umich.edu seems to run their own stuff, separately from umich.edu, and quite badly. I've complained about their setup repeatedly over the past several years. No traction. Should we try again, jointly? ;-) From LarrySheldon at cox.net Thu Mar 18 14:41:54 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 18 Mar 2010 14:41:54 -0500 Subject: Using private APNIC range in US In-Reply-To: <4BA27F5F.1050607@gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <4BA27F5F.1050607@gmail.com> Message-ID: <4BA28202.7040900@cox.net> On 3/18/2010 14:30, William Allen Simpson wrote: > On 3/18/10 2:35 PM, Jared Mauch wrote: >> Does anyone know if the University of Michigan or Cisco are going be updating their systems and documentation to no longer use 1.2.3.4 ? >> >> http://www.google.com/search?q=1.2.3.4+site%3Acisco.com >> >> I know that the University of Michigan utilize 1.2.3.4 for their captive portal login/logout pages as recently as monday when I was on the medical campus. >> > Dunno about cisco. > > med.umich.edu seems to run their own stuff, separately from umich.edu, and > quite badly. I've complained about their setup repeatedly over the past > several years. No traction. Is it something about Medical Schools? When we were first putting together the campus network, Surgery was running a Token Ring (I thought "Vampire Tap" was a fitting item for their inventory) running in Class D space as I recall. > Should we try again, jointly? ;-) Towards the end, there were people who insisted I must rout their net to the Internets. I declined. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From dedelman at iname.com Thu Mar 18 15:06:18 2010 From: dedelman at iname.com (Dave Edelman) Date: Thu, 18 Mar 2010 15:06:18 -0500 Subject: anti-ddos test solutions ? In-Reply-To: References: <4BA07A6F.4010104@yahoo.fr> <1268817124.2479.3.camel@localhost> <4BA11C48.6000506@knownelement.com> <005001cac5ff$96a55370$c3effa50$@net> <7db9abd31003172132l3d94fe2du7e9e8c9a05775df6@mail.gmail.com> Message-ID: I use argus, radium, and the ra clients to do this. Works very well www.qosient.com Dave Edelman +1 917 331-0112 cell On Mar 18, 2010, at 8:05 AM, Drew Weaver wrote: > On a similar note but slightly unrelated note, > > Not to thread hijack, but does anyone have any useful recipes for > generating any basic baseline data (top talkers, SSH brute forcing, > SMTP brute forcing, 445,etc) > via any of the open source netflow collectors (Flow-Tools, nfdump)? > > I've had mixed success getting these packages to produce any useful > information after getting them to collect the flow data. > > Thanks, > -Drew > > > -----Original Message----- > From: kowsik [mailto:kowsik at gmail.com] > Sent: Thursday, March 18, 2010 12:33 AM > To: Stefan Fouant > Cc: nanog at nanog.org > Subject: Re: anti-ddos test solutions ? > > http://labs.mudynamics.com/2009/04/10/ddos-testing-network-applications/ > http://www.pcapr.net/dos > > YMMV, but mudos converts *any* IP packet into a DoS generator (it's > free). > > K. > --- > http://www.pcapr.net > http://labs.mudynamics.com > http://twitter.com/pcapr > > On Wed, Mar 17, 2010 at 11:28 AM, Stefan Fouant > wrote: >>> -----Original Message----- >>> From: Charles N Wyble [mailto:charles at knownelement.com] >>> Sent: Wednesday, March 17, 2010 12:16 PM >>> To: nanog at nanog.org >>> Subject: Re: anti-ddos test solutions ? >>> >>> bit gossip wrote: >>>> Nessus is a vulnerability scanner: >>>> >>>> http://www.nessus.org/nessus/ >>>> >>>> Ixia provides a full Nessus implementation in one of its platform. >>>> >>> >>> Well these days I would use http://www.openvas.org and >>> http://www.metasploit.org >>> for vulnerability scanning and analysis. >>> >>> However that wouldn't be a DDoS, but could certainly lead to DOS. >> >> If you can get your hands on a PCAP from a previous attack, you >> could also use something like Bit-Twist which will allow you to >> manipulate things like the destination IP and also the transmission >> rate, etc. Pretty useful tool to include in the DDoS simulation >> toolbox. >> >> http://bittwist.sourceforge.net/ >> >> Stefan Fouant, CISSP, JNCIE-M/T >> www.shortestpathfirst.net >> GPG Key ID: 0xB5E3803D >> >> >> > From kauer at biplane.com.au Thu Mar 18 17:29:12 2010 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 19 Mar 2010 09:29:12 +1100 Subject: IPv6 in Education Question In-Reply-To: <18a5e7cb1003181116g2d26b169yfcad480c8e2a044a@mail.gmail.com> References: <97487AA41962C74E83D8ABABD2A90A4905A2C8138B@mail.springnet.local> <1268868062.5727.652.camel@karl> <4e913c5d1003172039id15ba75k2fa5fb85be3f26e3@mail.gmail.com> <18a5e7cb1003181116g2d26b169yfcad480c8e2a044a@mail.gmail.com> Message-ID: <1268951352.5978.58.camel@karl> On Thu, 2010-03-18 at 11:16 -0700, Bill Stewart wrote: > You're either going to have to sell them on future-proofing or > "We're sailing off the edge of the world in two years, > there be dragons there, train your folks now." Or sell them on the point that IPv6 is where the innovation is. We have literally no idea what our children will be doing with restored end-to-end transparency and abundant addresses. That's where education has to be. It's not an educational "feature", but a very important emergent property... > Remember that there are two IPv6 transitions > - introducing IPv6 and forcing some people onto it > - getting rid of IPv4 after IPv6 support is universal. And the third (well, probably the second, between those two) - learning to *really use* IPv6. > > Death of NAT > NAT's not going away for a long time - IPv6 doesn't need it for > address space conservation, and pretends not to need it very much for > renumbering IPv6 to IPv6, but it's widely used as a firewall > substitute and administrative convenience. Both oddities that I confidently predict will not survive long in the face of the enormous advantages that properly-implemented IPv6 can bring. A teensy packet filter substitutes for the "security" aspect, and PI address space deals with the second. > The first IPv6 transition will eliminate some NAT in pure-v6 environments, > so there will be applications that are no longer broken and can Just Work, > but it'll also introduce several different flavors of IPv4-to-IPv6 > NATs/tunnels/etc., Sure, there will be practical reasons why people need this or that half-solution, this or that broken stopgap. But we can keep the Dark Years fewer by trying not to use them. > Any big commercial sites will stay reachable with IPv4 for a long time, > certainly until IPv6 has been well established for a couple of years, We've all been here before. The same thing will happen globally as happened in thousands of networks with IPX, Appletalk and DECNet. IPv4 remains only on sufferance. The alternative rapidly becomes vastly more attractive as the connectedness of the new protocol snowballs. Pressure builds from inside and out, and - way sooner than anyone expected - there is a sort of communal sigh of relief and the old stuff gets quietly dropped. I wonder what landmarks we should designate as "IPv4 is done" - Google dropping support for IPv4? And I wonder what the landmarks for the beginning of the end would be - Windows 15 coming out with IPv4 disabled by default? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sob at academ.com Thu Mar 18 18:36:39 2010 From: sob at academ.com (Stan Barber) Date: Thu, 18 Mar 2010 18:36:39 -0500 Subject: IP4 Space In-Reply-To: <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> Message-ID: <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> Ok. Let's get back to some basics to be sure we are talking about the same things. First, do you believe that a residential customer of an ISP will get an IPv6 /56 assigned for use in their home? Do you believe that residential customer will often choose to multihome using that prefix? Do you believe that on an Internet that has its primary layer 3 protocol is IPv6 that a residential customer will still desire to do NAT for reaching IPv6 destinations? I am looking forward to your response. On Mar 18, 2010, at 2:25 PM, William Herrin wrote: >> On Mar 5, 2010, at 7:24 AM, William Herrin wrote: >>> Joel made a remarkable assertion >>> that non-aggregable assignments to end users, the ones still needed >>> for multihoming, would go down under IPv6. I wondered about his >>> reasoning. Stan then offered the surprising clarification that a >>> reduction in the use of NAT would naturally result in a reduction of >>> multihoming. > > On Thu, Mar 18, 2010 at 11:07 AM, Stan Barber wrote: >> I was not trying to say there would be a reduction in multihoming. I was >> trying to say that the rate of increase in non-NATed single-homing >> would increase faster than multihoming. I guess I was not very clear. > > > Hi Stan, > > Your logic still escapes me. Network-wise there's not a lot of > difference between a single-homed IPv4 /32 and a single-homed IPv6 > /56. Host-wise there may be a difference but why would you expect that > to impact networks? > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Thu Mar 18 20:20:02 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Mar 2010 21:20:02 -0400 Subject: IP4 Space In-Reply-To: <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> Message-ID: <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> On Thu, Mar 18, 2010 at 7:36 PM, Stan Barber wrote: > Ok. Let's get back to some basics to be sure we are talking about the same things. > > ?First, do you believe that a residential customer of an ISP will get an IPv6 /56 assigned for use in their home? Do > you believe that residential customer will often choose to multihome using that prefix? Do you believe that on an > Internet that has its primary layer 3 protocol is IPv6 that a residential customer will still desire to do NAT for reaching how are nat and ipv6 and multihoming related here? (also 'that has a primary layer 3 protocol as ipv6' ... that's a LONG ways off) -chris > IPv6 destinations? > > I am looking forward to your response. > > > > > On Mar 18, 2010, at 2:25 PM, William Herrin wrote: > >>> On Mar 5, 2010, at 7:24 AM, William Herrin wrote: >>>> Joel made a remarkable assertion >>>> that non-aggregable assignments to end users, the ones still needed >>>> for multihoming, would go down under IPv6. I wondered about his >>>> reasoning. Stan then offered the surprising clarification that a >>>> reduction in the use of NAT would naturally result in a reduction of >>>> multihoming. >> >> On Thu, Mar 18, 2010 at 11:07 AM, Stan Barber wrote: >>> I was not trying to say there would be a reduction in multihoming. I was >>> trying to say that the rate of increase in non-NATed single-homing >>> would increase faster than multihoming. I guess I was not very clear. >> >> >> Hi Stan, >> >> Your logic still escapes me. Network-wise there's not a lot of >> difference between a single-homed ?IPv4 /32 and a single-homed IPv6 >> /56. Host-wise there may be a difference but why would you expect that >> to impact networks? >> >> Regards, >> Bill Herrin >> >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 > > > From gfortaine at live.com Thu Mar 18 22:43:18 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Fri, 19 Mar 2010 04:43:18 +0100 Subject: NSP-SEC Message-ID: Misses, Misters, I would want to inform you that the security of the Internet, that is discussed in the NSP-SEC mailing-list [0] by a selected group of vendors (Cisco, Juniper & Arbor) [1] and operations contacts of the big ISPs [2] : 1) applies the "Security through Obscurity" paradigm that has been proven inefficient [3]. To quote [4] : "Please do not Forward, CC, or BCC this E-mail outside of the nsp-security community. Confidentiality is essential for effective Internet security counter-measures." First question : Why was I able to find this mail on the Internet if it should be kept secret ? 2) includes [5] a) Spammers (Rodney Joffe) [6] [7] b) Freelancers (Gadi Evron) [8] [9] Second question : Do you still ask yourself why the Internet is so insecure ? [10] Best Regards, Guillaume FORTAINE [0] http://puck.nether.net/mailman/listinfo/nsp-security [1] http://www.confickerworkinggroup.org/wiki/pmwiki.php/SP/ServiceProviders [2] http://docs.google.com/viewer?url=http://www.cisco.com/web/ME/exposaudi2009/assets/docs/isp_security_routing_and_switching.pdf [3] http://en.wikipedia.org/wiki/Security_through_obscurity [4] http://lists.ausnog.net/pipermail/ausnog/2007-April/000397.html [5] http://www.google.com/search?hl=en&source=hp&q="nsp-sec"+site:mailman.nanog.org&aq=f&aqi=&aql=&oq=&gs_rfai=&esrch=FT1 [6] http://mailman.nanog.org/pipermail/nanog/2008-October/004724.html [7] http://www.iadl.org/RodneyJoffe/rodneyjoffe.html [8] http://mailman.nanog.org/pipermail/nanog/2009-November/015354.html [9] http://il.linkedin.com/in/gadievron [10] http://caislab.kaist.ac.kr/77ddos/ From nenolod at systeminplace.net Thu Mar 18 22:46:49 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 18 Mar 2010 22:46:49 -0500 Subject: NSP-SEC In-Reply-To: References: Message-ID: Hello, Few people actually care about nsp-sec so what exactly are you getting at? "Guillaume FORTAINE" wrote: >Misses, Misters, > >I would want to inform you that the security of the Internet, that is >discussed in the NSP-SEC mailing-list [0] by a selected group of vendors >(Cisco, Juniper & Arbor) [1] and operations contacts of the big ISPs [2] : > > >1) applies the "Security through Obscurity" paradigm that has been >proven inefficient [3]. To quote [4] : > >"Please do not Forward, CC, or BCC this E-mail outside of the nsp-security >community. Confidentiality is essential for effective Internet security >counter-measures." > >First question : Why was I able to find this mail on the Internet if it >should be kept secret ? > > >2) includes [5] > >a) Spammers (Rodney Joffe) [6] [7] > >b) Freelancers (Gadi Evron) [8] [9] > >Second question : Do you still ask yourself why the Internet is so >insecure ? [10] > > >Best Regards, > >Guillaume FORTAINE > >[0] http://puck.nether.net/mailman/listinfo/nsp-security >[1] http://www.confickerworkinggroup.org/wiki/pmwiki.php/SP/ServiceProviders >[2] >http://docs.google.com/viewer?url=http://www.cisco.com/web/ME/exposaudi2009/assets/docs/isp_security_routing_and_switching.pdf >[3] http://en.wikipedia.org/wiki/Security_through_obscurity >[4] >http://lists.ausnog.net/pipermail/ausnog/2007-April/000397.html >[5] >http://www.google.com/search?hl=en&source=hp&q="nsp-sec"+site:mailman.nanog.org&aq=f&aqi=&aql=&oq=&gs_rfai=&esrch=FT1 >[6] http://mailman.nanog.org/pipermail/nanog/2008-October/004724.html >[7] http://www.iadl.org/RodneyJoffe/rodneyjoffe.html >[8] http://mailman.nanog.org/pipermail/nanog/2009-November/015354.html >[9] http://il.linkedin.com/in/gadievron >[10] http://caislab.kaist.ac.kr/77ddos/ > > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From drc at virtualized.org Thu Mar 18 22:50:02 2010 From: drc at virtualized.org (David Conrad) Date: Thu, 18 Mar 2010 20:50:02 -0700 Subject: NSP-SEC In-Reply-To: References: Message-ID: Why respond to an obvious troll? Regards, -drc On Mar 18, 2010, at 8:46 PM, William Pitcock wrote: > Hello, > > Few people actually care about nsp-sec so what exactly are you getting at? > > "Guillaume FORTAINE" wrote: ... From patrick at ianai.net Thu Mar 18 22:52:25 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 18 Mar 2010 23:52:25 -0400 Subject: NSP-SEC In-Reply-To: References: Message-ID: <4629B58D-22D5-42C8-83CB-6504DD106802@ianai.net> On Mar 18, 2010, at 11:46 PM, William Pitcock wrote: > Few people actually care about nsp-sec so what exactly are you getting at? I might argue the "few" comment, but I think it's better not to reply to Guillaume so people who are smart enough to not see his posts (which would be quite a bit more than a "few") will not be force to see them. Although I have to admit I am impressed at how quickly he has managed to piss off, alienate, and pretty much guarantee lasting animosity from, well, pretty much every significant person on the 'Net. Perhaps we should lump Guillaume in with $HE_WHO_MUST_NOT_BE_NAMED[*]? -- TTFN, patrick [*] Lest you receive a bazillion unicast messages CC'ed to a bazillion other people who don't care. From matt.shadbolt at gmail.com Thu Mar 18 23:04:52 2010 From: matt.shadbolt at gmail.com (Matt Shadbolt) Date: Fri, 19 Mar 2010 15:04:52 +1100 Subject: Using private APNIC range in US In-Reply-To: <4BA28202.7040900@cox.net> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <4BA27F5F.1050607@gmail.com> <4BA28202.7040900@cox.net> Message-ID: <2511b2981003182104l1c671426odb0768337faf4dcf@mail.gmail.com> I once had a customer who for some reason had all their printers on public addresses they didn't own. Not advertising them outside, but internally whenever a user browsed to a external site that happened to be one of the addresses used, they would just receive a HP or Konica login page :) They didn't mind though. No idea if they've changed it since. On Fri, Mar 19, 2010 at 6:41 AM, Larry Sheldon wrote: > On 3/18/2010 14:30, William Allen Simpson wrote: > > On 3/18/10 2:35 PM, Jared Mauch wrote: > >> Does anyone know if the University of Michigan or Cisco are going be > updating their systems and documentation to no longer use 1.2.3.4 ? > >> > >> http://www.google.com/search?q=1.2.3.4+site%3Acisco.com > >> > >> I know that the University of Michigan utilize 1.2.3.4 for their captive > portal login/logout pages as recently as monday when I was on the medical > campus. > >> > > Dunno about cisco. > > > > med.umich.edu seems to run their own stuff, separately from umich.edu, > and > > quite badly. I've complained about their setup repeatedly over the past > > several years. No traction. > > Is it something about Medical Schools? > > When we were first putting together the campus network, Surgery was > running a Token Ring (I thought "Vampire Tap" was a fitting item for > their inventory) running in Class D space as I recall. > > > Should we try again, jointly? ;-) > > Towards the end, there were people who insisted I must rout their net to > the Internets. > > I declined. > -- > Democracy: Three wolves and a sheep voting on the dinner menu. > (A republic, using parliamentary law, protects the minority.) > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > > From gfortaine at live.com Thu Mar 18 23:22:41 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Fri, 19 Mar 2010 05:22:41 +0100 Subject: NSP-SEC In-Reply-To: <4629B58D-22D5-42C8-83CB-6504DD106802@ianai.net> References: <4629B58D-22D5-42C8-83CB-6504DD106802@ianai.net> Message-ID: On 03/19/2010 04:52 AM, Patrick W. Gilmore wrote: > On Mar 18, 2010, at 11:46 PM, William Pitcock wrote: > > >> Few people actually care about nsp-sec so what exactly are you getting at? >> > I might argue the "few" comment > Could you argue, if possible, please ? I look forward to your answer, Best Regards, Guillaume FORTAINE From nenolod at systeminplace.net Thu Mar 18 23:27:15 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 18 Mar 2010 23:27:15 -0500 Subject: NSP-SEC In-Reply-To: <4629B58D-22D5-42C8-83CB-6504DD106802@ianai.net> References: <4629B58D-22D5-42C8-83CB-6504DD106802@ianai.net> Message-ID: <1268972835.1220.132.camel@petrie> On Thu, 2010-03-18 at 23:52 -0400, Patrick W. Gilmore wrote: > On Mar 18, 2010, at 11:46 PM, William Pitcock wrote: > > > Few people actually care about nsp-sec so what exactly are you getting at? > > I might argue the "few" comment, but I think it's better not to reply to Guillaume so people who are smart enough to not see his posts (which would be quite a bit more than a "few") will not be force to see them. I would say that, in general, more people care about NANOG than nsp-security, although nsp-security is a worthwhile resource for those who are dealing with backbone-level problems (which is a minority of the people on NANOG, who generally are managing single typically-not-multihomed sites for the most part). > > Although I have to admit I am impressed at how quickly he has managed to piss off, alienate, and pretty much guarantee lasting animosity from, well, pretty much every significant person on the 'Net. Perhaps we should lump Guillaume in with $HE_WHO_MUST_NOT_BE_NAMED[*]? Ugh, that IADL guy. I blackholed his entire IP block at edge because I got tired of receiving his crap. :D And yeah, I'm surprised Guillaume can actually post here still. William From gordslater at ieee.org Fri Mar 19 01:08:56 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 19 Mar 2010 06:08:56 +0000 Subject: Using private APNIC range in US In-Reply-To: <80CC32C4-649A-4214-AD76-FE2F098F9544@senie.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <80CC32C4-649A-4214-AD76-FE2F098F9544@senie.com> Message-ID: <1268978936.6588.27.camel@ub-g-d2> On Thu, 2010-03-18 at 14:50 -0400, Daniel Senie wrote: > As you note, debugging this type of thing is often not intuitive, as > everything appears to work from almost everywhere I got curious yesterday and set off a couple (very slow {option -T0}, very polite, very restrictive) nmap single port scans of a few lumps of 1.0.0.0/22 yesterday, but couldn't see much out there due to my several of our ISPs internal boxes. It looks like chaos-squared out there. I don't envy anyone fathoming that stuff out for real. Still, that said, the transition to fully signed roots seems to be going along without too much breakage (I think/hope!) so maybe only time will tell how much this latest block release will give trouble longterm. Gord -- rockin ze chair mit Davey Graham to Banshee from rackserver-2 From gordslater at ieee.org Fri Mar 19 01:37:33 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 19 Mar 2010 06:37:33 +0000 Subject: Using private APNIC range in US In-Reply-To: <1268978936.6588.27.camel@ub-g-d2> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <80CC32C4-649A-4214-AD76-FE2F098F9544@senie.com> <1268978936.6588.27.camel@ub-g-d2> Message-ID: <1268980653.6588.44.camel@ub-g-d2> On Fri, 2010-03-19 at 06:08 +0000, gordon b slater wrote: > It looks like chaos-squared out there. I don't envy anyone fathoming > that stuff out for real. clarification: `chaos` due to our ISP running internal boxes on the range in question, rather than external chaos. The implication being: if it's looping around inside the customers ISP then there's not much hope of easy troubleshooting, Gord -- sig nal generator From pauldotwall at gmail.com Fri Mar 19 04:50:37 2010 From: pauldotwall at gmail.com (Paul WALL) Date: Fri, 19 Mar 2010 02:50:37 -0700 Subject: NSP-SEC In-Reply-To: References: Message-ID: <620fd17c1003190250i13e13ba9y286ae54e895d8a8e@mail.gmail.com> On Thu, Mar 18, 2010 at 8:43 PM, Guillaume FORTAINE wrote: > Misses, Misters, You forgot the ballers, shot callers, brawlers, those who dippin' in the benz with the spoilers. [0] > I would want to inform you that the security of the Internet, that is > discussed in the NSP-SEC mailing-list [0] by a selected group of vendors > (Cisco, Juniper & Arbor) [1] and operations contacts of the big ISPs [2] : I personally believe that that U.S. Americans are unable to do so because, uh, some people out there in our nation don't have maps and, uh, I believe that our, uh, education like such as in South Africa and, uh, the Iraq, everywhere like such as, and, I believe that they should, our education over here in the U.S. should help the U.S., uh, or, uh, should help South Africa and should help the Iraq and the Asian countries, so we will be able to build up our future, for our children. [1] > 1) applies the "Security through Obscurity" paradigm that has been proven > inefficient [3]. To quote [4] : When the Sun shines upon Earth, 2 - major Time points are created on opposite sides of Earth - known as Midday and Midnight. Where the 2 major Time forces join, synergy creates 2 new minor Time points we recognize as Sunup and Sundown. The 4-equidistant Time points can be considered as Time Square imprinted upon the circle of Earth. In a single rotation of the Earth sphere, each Time corner point rotates through the other 3-corner Time points, thus creating 16 corners, 96 hours and 4-simultaneous 24 hour Days within a single rotation of Earth - equated to a Higher Order of Life Time Cube. [2] > First question : Why was I able to find this mail on the Internet if it > should be kept secret ? ELMSFORD 12 GALAXIES CESJROGENICAL ERGONOMICS NBC: XOXPHROZENIGUL COVERAGE WASPROVENIKIL ADMONISHMENTS MINUSCULE STRATOSPHERICAL [3] > Second question : Do you still ask yourself why the Internet is so insecure > ? [10] http://www.youtube.com/watch?v=GkMvKeX7erI [4] I am also curious [5], is OBESUS [6] the new IASON [7]? Are you Peter and Karin Dambier [8]? Drive Slow [9], Paul WALL [10] [0] http://www.lyricsmode.com/lyrics/p/p_diddy/all_about_the_benjamins.html [1] http://en.wikipedia.org/wiki/Caitlin_Upton [2] http://en.wikipedia.org/wiki/Time_cube [3] http://en.wikipedia.org/wiki/Frank_Chu [4] http://en.wikipedia.org/wiki/List_of_recurring_characters_in_The_Simpsons#Crazy_Cat_Lady [5] http://www.merriam-webster.com/dictionary/curious [6] http://mailman.nanog.org/pipermail/nanog/2010-March/019518.html [7] http://iason.site.voila.fr/ [8] http://www.peter-dambier.de/ [9] http://en.wikipedia.org/wiki/Drive_Slow [10] http://en.wikipedia.org/wiki/Paul_Wall From jtk at cymru.com Fri Mar 19 08:31:43 2010 From: jtk at cymru.com (John Kristoff) Date: Fri, 19 Mar 2010 08:31:43 -0500 Subject: NSP-SEC In-Reply-To: References: Message-ID: <20100319083143.553b0111@t61p> On Fri, 19 Mar 2010 04:43:18 +0100 Guillaume FORTAINE wrote: > First question : Why was I able to find this mail on the Internet if > it should be kept secret ? nsp-security was originally formed out of the dissatisfaction with other so-called private collaborative channels back when it was formed a number of years ago. There are many more lists and groups that have since formed along the same lines. The existence of nsp-security is no secret and there has been a small number of "leaks", that is, mail primarily, that was not meant to be forwarded or copied outside the list that had been. Its been far from perfect from both a secretive standpoint and policy standpoint, but compared to what existed before it, it has proved useful from time to time. The ISP Security BoF/Track meetings at NANOG grew out of the nsp-security effort and those are open to any NANOG attendee. One thing groups like this has perhaps most helped with is building one-to-one relationships between colleagues. Groups like nsp-security help you to learn who the trusted and reliable contacts are at various organizations. An ongoing area of work is to build better closed, trusted communities without leaks. Its still an ongoing problem. Thats why many times really sensitive work gets done in even smaller ad-hoc groups or on a one-to-one basis. John From bicknell at ufp.org Fri Mar 19 08:42:44 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 19 Mar 2010 06:42:44 -0700 Subject: NSP-SEC In-Reply-To: <620fd17c1003190250i13e13ba9y286ae54e895d8a8e@mail.gmail.com> References: <620fd17c1003190250i13e13ba9y286ae54e895d8a8e@mail.gmail.com> Message-ID: <20100319134244.GA98417@ussenterprise.ufp.org> I'd like to nominate this for the Best of Nanog 2010. In a message written on Fri, Mar 19, 2010 at 02:50:37AM -0700, Paul WALL wrote: > On Thu, Mar 18, 2010 at 8:43 PM, Guillaume FORTAINE wrote: > > Misses, Misters, > > You forgot the ballers, shot callers, brawlers, those who dippin' in > the benz with the spoilers. [0] > > > I would want to inform you that the security of the Internet, that is > > discussed in the NSP-SEC mailing-list [0] by a selected group of vendors > > (Cisco, Juniper & Arbor) [1] and operations contacts of the big ISPs [2] : > > I personally believe that that U.S. Americans are unable to do so > because, uh, some people out there in our nation don't have maps and, > uh, I believe that our, uh, education like such as in South Africa > and, uh, the Iraq, everywhere like such as, and, I believe that they > should, our education over here in the U.S. should help the U.S., uh, > or, uh, should help South Africa and should help the Iraq and the > Asian countries, so we will be able to build up our future, for our > children. [1] > > > 1) applies the "Security through Obscurity" paradigm that has been proven > > inefficient [3]. To quote [4] : > > When the Sun shines upon Earth, 2 - major Time points are created on > opposite sides of Earth - known as Midday and Midnight. Where the 2 > major Time forces join, synergy creates 2 new minor Time points we > recognize as Sunup and Sundown. The 4-equidistant Time points can be > considered as Time Square imprinted upon the circle of Earth. In a > single rotation of the Earth sphere, each Time corner point rotates > through the other 3-corner Time points, thus creating 16 corners, 96 > hours and 4-simultaneous 24 hour Days within a single rotation of > Earth - equated to a Higher Order of Life Time Cube. [2] > > > First question : Why was I able to find this mail on the Internet if it > > should be kept secret ? > > ELMSFORD 12 GALAXIES CESJROGENICAL ERGONOMICS NBC: XOXPHROZENIGUL > COVERAGE WASPROVENIKIL ADMONISHMENTS MINUSCULE STRATOSPHERICAL [3] > > > Second question : Do you still ask yourself why the Internet is so insecure > > ? [10] > > http://www.youtube.com/watch?v=GkMvKeX7erI [4] > > I am also curious [5], is OBESUS [6] the new IASON [7]? Are you Peter > and Karin Dambier [8]? > > Drive Slow [9], > > Paul WALL [10] > > [0] http://www.lyricsmode.com/lyrics/p/p_diddy/all_about_the_benjamins.html > [1] http://en.wikipedia.org/wiki/Caitlin_Upton > [2] http://en.wikipedia.org/wiki/Time_cube > [3] http://en.wikipedia.org/wiki/Frank_Chu > [4] http://en.wikipedia.org/wiki/List_of_recurring_characters_in_The_Simpsons#Crazy_Cat_Lady > [5] http://www.merriam-webster.com/dictionary/curious > [6] http://mailman.nanog.org/pipermail/nanog/2010-March/019518.html > [7] http://iason.site.voila.fr/ > [8] http://www.peter-dambier.de/ > [9] http://en.wikipedia.org/wiki/Drive_Slow > [10] http://en.wikipedia.org/wiki/Paul_Wall -- 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 nenolod at systeminplace.net Fri Mar 19 08:44:29 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 19 Mar 2010 08:44:29 -0500 Subject: NSP-SEC In-Reply-To: <20100319083143.553b0111@t61p> References: <20100319083143.553b0111@t61p> Message-ID: <1269006269.1220.135.camel@petrie> On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: > An ongoing area of work is to build better closed, > trusted communities without leaks. Have you ever considered that public transparency might not be a bad thing? This seems to be the plight of many security people, that they have to be 100% secretive in everything they do, which is total bullshit. Just saying. William From Valdis.Kletnieks at vt.edu Fri Mar 19 08:50:00 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 19 Mar 2010 09:50:00 -0400 Subject: NSP-SEC In-Reply-To: Your message of "Fri, 19 Mar 2010 06:42:44 PDT." <20100319134244.GA98417@ussenterprise.ufp.org> References: <620fd17c1003190250i13e13ba9y286ae54e895d8a8e@mail.gmail.com> <20100319134244.GA98417@ussenterprise.ufp.org> Message-ID: <31856.1269006600@localhost> On Fri, 19 Mar 2010 06:42:44 PDT, Leo Bicknell said: > I'd like to nominate this for the Best of Nanog 2010. Amen to that. As the Jargon File says, "C|N>K". Unfortunately, I was eating breakfast, and it was corn flakes not coffee. Ouch. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From thegameiam at yahoo.com Fri Mar 19 08:54:57 2010 From: thegameiam at yahoo.com (David Barak) Date: Fri, 19 Mar 2010 06:54:57 -0700 (PDT) Subject: NSP-SEC Message-ID: <570778.33984.qm@web31812.mail.mud.yahoo.com> Total transparency in security matters works about as well as it would for law enforcement: fine for tactical concerns, but not so great for long-term strategic concerns. -David Barak On Fri Mar 19th, 2010 9:44 AM EDT William Pitcock wrote: >On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: >> An ongoing area of work is to build better closed, >> trusted communities without leaks. > >Have you ever considered that public transparency might not be a bad >thing? This seems to be the plight of many security people, that they >have to be 100% secretive in everything they do, which is total >bullshit. > >Just saying. > >William > > From bmanning at vacation.karoshi.com Fri Mar 19 08:56:36 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 19 Mar 2010 13:56:36 +0000 Subject: NSP-SEC - should read Integrity In-Reply-To: <1269006269.1220.135.camel@petrie> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> Message-ID: <20100319135636.GA17876@vacation.karoshi.com.> On Fri, Mar 19, 2010 at 08:44:29AM -0500, William Pitcock wrote: > On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: > > An ongoing area of work is to build better closed, > > trusted communities without leaks. > > Have you ever considered that public transparency might not be a bad > thing? This seems to be the plight of many security people, that they > have to be 100% secretive in everything they do, which is total > bullshit. I thnk I'd settle for operators with Integrity. those who do what they say. --bill From lorell at hathcock.org Fri Mar 19 09:02:27 2010 From: lorell at hathcock.org (Lorell Hathcock) Date: Fri, 19 Mar 2010 09:02:27 -0500 Subject: Cogent outage yesterday Message-ID: <012101cac76c$cf870c10$6e952430$@org> All: Does anyone know anything about a Cogent outage yesterday? Thanks, Lorell Hathcock From Tim.Green2 at mms.gov Fri Mar 19 09:03:00 2010 From: Tim.Green2 at mms.gov (Green, Tim R) Date: Fri, 19 Mar 2010 10:03:00 -0400 Subject: NSP-SEC - should read Integrity In-Reply-To: <20100319135636.GA17876@vacation.karoshi.com.> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <20100319135636.GA17876@vacation.karoshi.com.> Message-ID: <129D9C95B82B2B47A19A6DD244AB83690BBD7820@IMSHEXPRI03.service.agency.mms.pri> There are some out there......Infragard?....(shrugs shoulders)...... -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Friday, March 19, 2010 9:57 AM To: William Pitcock Cc: nanog at nanog.org Subject: Re: NSP-SEC - should read Integrity On Fri, Mar 19, 2010 at 08:44:29AM -0500, William Pitcock wrote: > On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: > > An ongoing area of work is to build better closed, > > trusted communities without leaks. > > Have you ever considered that public transparency might not be a bad > thing? This seems to be the plight of many security people, that they > have to be 100% secretive in everything they do, which is total > bullshit. I thnk I'd settle for operators with Integrity. those who do what they say. --bill From LarrySheldon at cox.net Fri Mar 19 09:09:46 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 19 Mar 2010 09:09:46 -0500 Subject: Open Security (was Re:[a string that stops delivery here]) In-Reply-To: <1269006269.1220.135.camel@petrie> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> Message-ID: <4BA385AA.20508@cox.net> On 3/19/2010 08:44, William Pitcock wrote: > On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: >> An ongoing area of work is to build better closed, >> trusted communities without leaks. > > Have you ever considered that public transparency might not be a bad > thing? This seems to be the plight of many security people, that they > have to be 100% secretive in everything they do, which is total > bullshit. > > Just saying. It is clear that our security would be much improved if our politicians had to operate out in the open. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From patrick at ianai.net Fri Mar 19 09:12:58 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 19 Mar 2010 10:12:58 -0400 Subject: NSP-SEC - should read Integrity In-Reply-To: <20100319135636.GA17876@vacation.karoshi.com.> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <20100319135636.GA17876@vacation.karoshi.com.> Message-ID: <3C6CEF99-CB3F-4F6A-84CA-DE6C67CE0A9D@ianai.net> On Mar 19, 2010, at 9:56 AM, bmanning at vacation.karoshi.com wrote: > On Fri, Mar 19, 2010 at 08:44:29AM -0500, William Pitcock wrote: >> On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: >>> An ongoing area of work is to build better closed, >>> trusted communities without leaks. >> >> Have you ever considered that public transparency might not be a bad >> thing? This seems to be the plight of many security people, that they >> have to be 100% secretive in everything they do, which is total >> bullshit. > > I thnk I'd settle for operators with Integrity. those who do what > they say. If we had that, no secrecy would be needed. But anyone who thinks publishing everything we learn about the miscreants is a Good Idea, has never tried to take out a botnet or snow-shoe spammer or .... Secrecy sucks. If you think those keeping secrets enjoy it[*], you just haven't been bored to tears by working one of these issues. Seriously, most of the work is mind numbingly horrible, and I have nothing but the utmost respect for people who do it on a regular basis. (In case it is not clear, I do not have to do it often, and for that I think whatever ghods there may be.) Put another way: Do not dis those that make the Internet safer for you. They spend time, effort, and money - frequently their own - and risk much more (ever been sued by a spammer?). In return, they often get nothing. Before you question (and to be clear, I am not saying you should not question), offer to help and see things from their side. -- TTFN, patrick [*] I'm sure there are a few who get off on the thrill. But that's the exception, not the rule. From Valdis.Kletnieks at vt.edu Fri Mar 19 09:19:26 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 19 Mar 2010 10:19:26 -0400 Subject: NSP-SEC In-Reply-To: Your message of "Fri, 19 Mar 2010 04:43:18 BST." References: Message-ID: <520.1269008366@localhost> On Fri, 19 Mar 2010 04:43:18 BST, Guillaume FORTAINE said: > First question : Why was I able to find this mail on the Internet if it > should be kept secret ? Congratulations. You found an example of a mailing list where applying a standard disclaimer by default *does* make sense, which then got forwarded *by a coordination team leader at a national CERT* to an appropriate forum so that action could be taken, but failed to take the disclaimer off the bottom of that posting. Double bonus points for finding a posting that discussed something *really* sensitive, like "we've seen bots connecting to...". You *do* realize that there's an estimated 140,000,000 bots on the net, right, and as a result, some operation lists have *dozens* of "bots spotted connecting to" postings *per day*. And you wonder why you have a hard time being taken seriously. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From w3yni1 at gmail.com Fri Mar 19 10:06:16 2010 From: w3yni1 at gmail.com (Charles Mills) Date: Fri, 19 Mar 2010 11:06:16 -0400 Subject: Using private APNIC range in US In-Reply-To: <2511b2981003182104l1c671426odb0768337faf4dcf@mail.gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <4BA27F5F.1050607@gmail.com> <4BA28202.7040900@cox.net> <2511b2981003182104l1c671426odb0768337faf4dcf@mail.gmail.com> Message-ID: <607f1e0a1003190806r66487175i35977d74ea152abb@mail.gmail.com> I love war stories. I once got chewed out by a colleague from another organization because we were using "their" address space. We were using 10.0.0.0/8. Explanation of NAT and RFC1918 was met with a deer in the headlights look. On Fri, Mar 19, 2010 at 12:04 AM, Matt Shadbolt wrote: > I once had a customer who for some reason had all their printers on public > addresses they didn't own. Not advertising them outside, but internally > whenever a user browsed to a external site that happened to be one of the > addresses used, they would just receive a HP or Konica login page :) > > They didn't mind though. No idea if they've changed it since. > > > On Fri, Mar 19, 2010 at 6:41 AM, Larry Sheldon wrote: > >> On 3/18/2010 14:30, William Allen Simpson wrote: >> > On 3/18/10 2:35 PM, Jared Mauch wrote: >> >> Does anyone know if the University of Michigan or Cisco are going be >> updating their systems and documentation to no longer use 1.2.3.4 ? >> >> >> >> http://www.google.com/search?q=1.2.3.4+site%3Acisco.com >> >> >> >> I know that the University of Michigan utilize 1.2.3.4 for their captive >> portal login/logout pages as recently as monday when I was on the medical >> campus. >> >> >> > Dunno about cisco. >> > >> > med.umich.edu seems to run their own stuff, separately from umich.edu, >> and >> > quite badly. ?I've complained about their setup repeatedly over the past >> > several years. ?No traction. >> >> Is it something about Medical Schools? >> >> When we were first putting together the campus network, Surgery was >> running a Token Ring (I thought "Vampire Tap" was a fitting item for >> their inventory) running in Class D space as I recall. >> >> > Should we try again, jointly? ?;-) >> >> Towards the end, there were people who insisted I must rout their net to >> the Internets. >> >> I declined. >> -- >> Democracy: Three wolves and a sheep voting on the dinner menu. >> (A republic, using parliamentary law, protects the minority.) >> >> Requiescas in pace o email >> Ex turpi causa non oritur actio >> Eppure si rinfresca >> >> ICBM Targeting Information: ?http://tinyurl.com/4sqczs >> http://tinyurl.com/7tp8ml >> >> >> >> > -- ===================================== Charles L. Mills Westmoreland Co. ARES EC Amateur Radio Callsign W3YNI Email: w3yni1 at gmail.com From adam at adamstas.com Fri Mar 19 10:08:55 2010 From: adam at adamstas.com (Adam Stasiniewicz) Date: Fri, 19 Mar 2010 10:08:55 -0500 Subject: NSP-SEC In-Reply-To: <570778.33984.qm@web31812.mail.mud.yahoo.com> References: <570778.33984.qm@web31812.mail.mud.yahoo.com> Message-ID: IMHO, I think you have it backwards. I see strategic discussions (like new crypto algorithms, technologies, initiatives, etc) should be open to public debate, review, and scrutiny. But operational/tactical discussions (like new malware, software exploits, virus infected hosts, botnets, etc) don't need public review. Rather, those types of communications should be streamlined that would allow for quick resolution. -----Original Message----- From: David Barak [mailto:thegameiam at yahoo.com] Sent: Friday, March 19, 2010 8:55 AM To: nenolod at systeminplace.net; jtk at cymru.com Cc: nanog at nanog.org Subject: Re: NSP-SEC Total transparency in security matters works about as well as it would for law enforcement: fine for tactical concerns, but not so great for long-term strategic concerns. -David Barak On Fri Mar 19th, 2010 9:44 AM EDT William Pitcock wrote: >On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: >> An ongoing area of work is to build better closed, >> trusted communities without leaks. > >Have you ever considered that public transparency might not be a bad >thing? This seems to be the plight of many security people, that they >have to be 100% secretive in everything they do, which is total >bullshit. > >Just saying. > >William > > From Valdis.Kletnieks at vt.edu Fri Mar 19 10:33:38 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 19 Mar 2010 11:33:38 -0400 Subject: NSP-SEC In-Reply-To: Your message of "Fri, 19 Mar 2010 10:08:55 CDT." References: <570778.33984.qm@web31812.mail.mud.yahoo.com> Message-ID: <5803.1269012818@localhost> On Fri, 19 Mar 2010 10:08:55 CDT, Adam Stasiniewicz said: > IMHO, I think you have it backwards. I see strategic discussions (like > new crypto algorithms, technologies, initiatives, etc) should be open to > public debate, review, and scrutiny. But operational/tactical discussions > (like new malware, software exploits, virus infected hosts, botnets, etc) > don't need public review. Reducto ad absurdum: The police don't usually phone ahead to a suspect and say "We're planning to stop by around 4PM and execute a search warrant, so please don't destroy any evidence before then, ktxbai" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From thegameiam at yahoo.com Fri Mar 19 10:35:08 2010 From: thegameiam at yahoo.com (David Barak) Date: Fri, 19 Mar 2010 08:35:08 -0700 (PDT) Subject: NSP-SEC In-Reply-To: Message-ID: <780536.73475.qm@web31803.mail.mud.yahoo.com> --- On Fri, 3/19/10, Adam Stasiniewicz wrote: > IMHO, I think you have it > backwards.? I see strategic discussions (like > new crypto algorithms, technologies, initiatives, etc) > should be open to > public debate, review, and scrutiny.? But > operational/tactical discussions > (like new malware, software exploits, virus infected hosts, > botnets, etc) > don't need public review.? Rather, those types of > communications should be > streamlined that would allow for quick resolution. > Fair point - I was using "strategic" in the law enforcement with things like "long-term undercover investigation" in mind, but your point is well taken. I think we agree that some things benefit from increased transparency and other things don't. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From bruns at 2mbit.com Fri Mar 19 10:49:02 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 19 Mar 2010 08:49:02 -0700 Subject: NSP-SEC In-Reply-To: <20100319134244.GA98417@ussenterprise.ufp.org> References: <620fd17c1003190250i13e13ba9y286ae54e895d8a8e@mail.gmail.com> <20100319134244.GA98417@ussenterprise.ufp.org> Message-ID: <4BA39CEE.7070502@2mbit.com> On 3/19/10 6:42 AM, Leo Bicknell wrote: > > I'd like to nominate this for the Best of Nanog 2010. > I'd like to second/third/whatever that nomination as well. :) Epic win. Not only did it make me fall off the chair laughing, but I highly doubt Fortaine will understand why its so funny. Paul, remind me if I ever get into politics, that I hire you as a consultant for speeches. :-D -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From cvuljanic at gmail.com Fri Mar 19 11:45:59 2010 From: cvuljanic at gmail.com (Craig Vuljanic) Date: Fri, 19 Mar 2010 12:45:59 -0400 Subject: Using private APNIC range in US In-Reply-To: <607f1e0a1003190806r66487175i35977d74ea152abb@mail.gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <4BA27F5F.1050607@gmail.com> <4BA28202.7040900@cox.net> <2511b2981003182104l1c671426odb0768337faf4dcf@mail.gmail.com> <607f1e0a1003190806r66487175i35977d74ea152abb@mail.gmail.com> Message-ID: Chuck - Very true... What about the time our old manager (MARTIN) gave your old organization that Entire Class B !!!! On Fri, Mar 19, 2010 at 11:06 AM, Charles Mills wrote: > I love war stories. I once got chewed out by a colleague from > another organization because we were using "their" address space. > > We were using 10.0.0.0/8. Explanation of NAT and RFC1918 was met with > a deer in the headlights look. > > On Fri, Mar 19, 2010 at 12:04 AM, Matt Shadbolt > wrote: > > I once had a customer who for some reason had all their printers on > public > > addresses they didn't own. Not advertising them outside, but internally > > whenever a user browsed to a external site that happened to be one of the > > addresses used, they would just receive a HP or Konica login page :) > > > > They didn't mind though. No idea if they've changed it since. > > > > > > On Fri, Mar 19, 2010 at 6:41 AM, Larry Sheldon > wrote: > > > >> On 3/18/2010 14:30, William Allen Simpson wrote: > >> > On 3/18/10 2:35 PM, Jared Mauch wrote: > >> >> Does anyone know if the University of Michigan or Cisco are going be > >> updating their systems and documentation to no longer use 1.2.3.4 ? > >> >> > >> >> http://www.google.com/search?q=1.2.3.4+site%3Acisco.com > >> >> > >> >> I know that the University of Michigan utilize 1.2.3.4 for their > captive > >> portal login/logout pages as recently as monday when I was on the > medical > >> campus. > >> >> > >> > Dunno about cisco. > >> > > >> > med.umich.edu seems to run their own stuff, separately from umich.edu > , > >> and > >> > quite badly. I've complained about their setup repeatedly over the > past > >> > several years. No traction. > >> > >> Is it something about Medical Schools? > >> > >> When we were first putting together the campus network, Surgery was > >> running a Token Ring (I thought "Vampire Tap" was a fitting item for > >> their inventory) running in Class D space as I recall. > >> > >> > Should we try again, jointly? ;-) > >> > >> Towards the end, there were people who insisted I must rout their net to > >> the Internets. > >> > >> I declined. > >> -- > >> Democracy: Three wolves and a sheep voting on the dinner menu. > >> (A republic, using parliamentary law, protects the minority.) > >> > >> Requiescas in pace o email > >> Ex turpi causa non oritur actio > >> Eppure si rinfresca > >> > >> ICBM Targeting Information: http://tinyurl.com/4sqczs > >> http://tinyurl.com/7tp8ml > >> > >> > >> > >> > > > > > > -- > ===================================== > Charles L. Mills > Westmoreland Co. ARES EC > Amateur Radio Callsign W3YNI > Email: w3yni1 at gmail.com > > From eesslinger at fpu-tn.com Fri Mar 19 12:12:37 2010 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Fri, 19 Mar 2010 12:12:37 -0500 Subject: Using private APNIC range in US In-Reply-To: <607f1e0a1003190806r66487175i35977d74ea152abb@mail.gmail.com> Message-ID: > -----Original Message----- > From: Charles Mills [mailto:w3yni1 at gmail.com] > Sent: Friday, March 19, 2010 10:06 AM > To: Matt Shadbolt > Cc: nanog at nanog.org > Subject: Re: Using private APNIC range in US > > > I love war stories. I once got chewed out by a colleague > from another organization because we were using "their" address space. > > We were using 10.0.0.0/8. Explanation of NAT and RFC1918 was > met with a deer in the headlights look. > > On Fri, Mar 19, 2010 at 12:04 AM, Matt Shadbolt > wrote: > > I once had a customer who for some reason had all their printers on > > public addresses they didn't own. Not advertising them outside, but > > internally whenever a user browsed to a external site that > happened to > > be one of the addresses used, they would just receive a HP > or Konica > > login page :) > > > > They didn't mind though. No idea if they've changed it since. > > > > Was troubleshooting a customer's vpn trouble a few years ago at another ISP. Could connect from outside our ISP, but users of our service sometimes could and sometimes couldn't connect. Turns out the Master Network Manager (that's what he called himself) had looked at the static IP assignment, and extrapolated back the whole /22 they were on and used it for the inside of his NAT router. When people hit that part of our network pool, they could make the initial connection but then the poor firewall would have a nervous breakdown and not pass traffic right (I don't blame it). My solution: Renumber to a reserved private block internally. He had about 200 devices with static assigned dhcp on about 10 of them. His solution: Every company user that gets access through our service had to get some form of other service in order to connect to his network by vpn since we 'don't know what we're doing with network configuration'. 35 people either switched away from us or got a second (usually dial up) connection for when they wanted to vpn in. I believe his core mantra was that the private 1918's were 'not secure' for some reason he couldn't articulate to me. This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: Eric J Esslinger.vcf Type: text/x-vcard Size: 498 bytes Desc: Eric J Esslinger.vcf URL: From wavetossed at googlemail.com Fri Mar 19 12:48:24 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Fri, 19 Mar 2010 17:48:24 +0000 Subject: NSP-SEC In-Reply-To: <620fd17c1003190250i13e13ba9y286ae54e895d8a8e@mail.gmail.com> References: <620fd17c1003190250i13e13ba9y286ae54e895d8a8e@mail.gmail.com> Message-ID: <877585b01003191048s6bb4499dm7e97b3199fc62176@mail.gmail.com> > When the Sun shines upon Earth, 2 - major Time points are created on > opposite sides of Earth - known as Midday and Midnight. Where the 2 > major Time forces join, synergy creates 2 new minor Time points we > recognize as Sunup and Sundown. The 4-equidistant Time points can be > considered as Time Square imprinted upon the circle of Earth. In a > single rotation of the Earth sphere, each Time corner point rotates > through the other 3-corner Time points, thus creating 16 corners, 96 > hours and 4-simultaneous 24 hour Days within a single rotation of > Earth - equated to a Higher Order of Life Time Cube. [2] > [2] http://en.wikipedia.org/wiki/Time_cube Uhhh, yeah... WOW man, like FARM OUT man! The best thing I've learned on NANOG all year is this message about Gene Ray. And as an added bonus that led me to the Peirce quincuncial projection which is actually something useful to know about. --Michael Dillon From lorell at hathcock.org Fri Mar 19 13:25:16 2010 From: lorell at hathcock.org (Lorell Hathcock) Date: Fri, 19 Mar 2010 13:25:16 -0500 Subject: Cogent outage yesterday Message-ID: <01c901cac791$89500ab0$9bf02010$@org> Thanks for the responses to my query. Here's what happened to my network. On 3/17/2010 in the morning Central Time in Houston we started having issues connecting to parts of the rest of the world on an intermittent basis. We were troubleshooting our own equipment for quite some time and did not realize that Cogent was having routing/peering issues with Time Warner (Telecom?). Apparently it was an issue that was supposed to have started 3/17/2010 at 9:00am Central Time and effected Houston and Dallas, Texas, USA and stopped around 1:00pm CT on the same day. But my experience was that the outage was not resolved until 3/18/2010 at 3:00pm CT (or so). The Cogent ticket # on the issue was HD2113436. Thanks, Lorell Hathcock From gfortaine at live.com Fri Mar 19 15:18:56 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Fri, 19 Mar 2010 21:18:56 +0100 Subject: NSP-SEC - should read Integrity In-Reply-To: <3C6CEF99-CB3F-4F6A-84CA-DE6C67CE0A9D@ianai.net> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <20100319135636.GA17876@vacation.karoshi.com.> <3C6CEF99-CB3F-4F6A-84CA-DE6C67CE0A9D@ianai.net> Message-ID: > If we had that, no secrecy would be needed. > > But anyone who thinks publishing everything we learn about the miscreants is a Good Idea, has never tried to take out a botnet or snow-shoe spammer or ... Me, an evolvable malware : http://docs.google.com/viewer?url=http://www.genetic-programming.org/hc2009/3-Noreen/Noreen-Presentation.ppt Best Regards, Guillaume FORTAINE From streiner at cluebyfour.org Fri Mar 19 13:05:37 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 19 Mar 2010 14:05:37 -0400 (EDT) Subject: NSP-SEC In-Reply-To: <1269006269.1220.135.camel@petrie> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> Message-ID: On Fri, 19 Mar 2010, William Pitcock wrote: > On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: >> An ongoing area of work is to build better closed, >> trusted communities without leaks. > > Have you ever considered that public transparency might not be a bad > thing? This seems to be the plight of many security people, that they > have to be 100% secretive in everything they do, which is total > bullshit. That's fine, in theory, but in practice it doesn't work. Part of the issue is that information that could be considered sensitive generally has to have a level of trust for both the sender(s) and receiver(s), and that level of trust is generally not possible in an open forum. By "level of trust" I mean that if I have sensitive intel about an ongoing incident (attack, pwnd box, etc) I need to have some assurance that the information gets to people who can and will act on it, and keep that information confidential. nsp-sec has worked to build that level of trust (in general, work pretty good success) through the vetting process that every potential participant goes through. Is it a perfect system? No, but it does serve a useful and important purpose. Many security people have to keep things quiet for the same reasons, in addition to (not an all-inclusive list): 1. They might be under NDA or be employed at a company that has a policy against any sort of "unapproved disclosures" 2. The sources of various bits of intel is confidential and releasing unfiltered information could compromise that source. 3. Releasing unfiltered information could compromised intel gathering methods, potentially rendering them useless for further action. "The likelihood that a secret will be kept goes down by the square of the number of people who know it" -- source unknown "The likelihood that a meeting will be productive goes down by the square of the number of people who attend" -- me jms From cscora at apnic.net Fri Mar 19 16:05:01 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Mar 2010 07:05:01 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201003192105.o2JL51D9016412@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 20 Mar, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 312799 Prefixes after maximum aggregation: 145223 Deaggregation factor: 2.15 Unique aggregates announced to Internet: 153590 Total ASes present in the Internet Routing Table: 33561 Prefixes per ASN: 9.32 Origin-only ASes present in the Internet Routing Table: 29134 Origin ASes announcing only one prefix: 14245 Transit ASes present in the Internet Routing Table: 4427 Transit-only ASes present in the Internet Routing Table: 106 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 22 Max AS path prepend of ASN (32374) 19 Prefixes from unregistered ASNs in the Routing Table: 966 Unregistered ASNs in the Routing Table: 158 Number of 32-bit ASNs allocated by the RIRs: 481 Prefixes from 32-bit ASNs in the Routing Table: 480 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 218 Number of addresses announced to Internet: 2204886880 Equivalent to 131 /8s, 107 /16s and 231 /24s Percentage of available address space announced: 59.5 Percentage of allocated address space announced: 66.1 Percentage of available address space allocated: 90.0 Percentage of address space in use by end-sites: 81.7 Total number of prefixes smaller than registry allocations: 149633 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 75611 Total APNIC prefixes after maximum aggregation: 26228 APNIC Deaggregation factor: 2.88 Prefixes being announced from the APNIC address blocks: 72268 Unique aggregates announced from the APNIC address blocks: 31854 APNIC Region origin ASes present in the Internet Routing Table: 3976 APNIC Prefixes per ASN: 18.18 APNIC Region origin ASes announcing only one prefix: 1089 APNIC Region transit ASes present in the Internet Routing Table: 626 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 504451648 Equivalent to 30 /8s, 17 /16s and 82 /24s Percentage of available APNIC address space announced: 79.1 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 129513 Total ARIN prefixes after maximum aggregation: 67928 ARIN Deaggregation factor: 1.91 Prefixes being announced from the ARIN address blocks: 103342 Unique aggregates announced from the ARIN address blocks: 40062 ARIN Region origin ASes present in the Internet Routing Table: 13568 ARIN Prefixes per ASN: 7.62 ARIN Region origin ASes announcing only one prefix: 5261 ARIN Region transit ASes present in the Internet Routing Table: 1338 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 724084128 Equivalent to 43 /8s, 40 /16s and 165 /24s Percentage of available ARIN address space announced: 61.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 72365 Total RIPE prefixes after maximum aggregation: 42232 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 65423 Unique aggregates announced from the RIPE address blocks: 43239 RIPE Region origin ASes present in the Internet Routing Table: 14233 RIPE Prefixes per ASN: 4.60 RIPE Region origin ASes announcing only one prefix: 7383 RIPE Region transit ASes present in the Internet Routing Table: 2130 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 418727296 Equivalent to 24 /8s, 245 /16s and 69 /24s Percentage of available RIPE address space announced: 78.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 27949 Total LACNIC prefixes after maximum aggregation: 6632 LACNIC Deaggregation factor: 4.21 Prefixes being announced from the LACNIC address blocks: 26292 Unique aggregates announced from the LACNIC address blocks: 13679 LACNIC Region origin ASes present in the Internet Routing Table: 1253 LACNIC Prefixes per ASN: 20.98 LACNIC Region origin ASes announcing only one prefix: 411 LACNIC Region transit ASes present in the Internet Routing Table: 214 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 71650304 Equivalent to 4 /8s, 69 /16s and 76 /24s Percentage of available LACNIC address space announced: 71.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6643 Total AfriNIC prefixes after maximum aggregation: 1781 AfriNIC Deaggregation factor: 3.73 Prefixes being announced from the AfriNIC address blocks: 4996 Unique aggregates announced from the AfriNIC address blocks: 1480 AfriNIC Region origin ASes present in the Internet Routing Table: 345 AfriNIC Prefixes per ASN: 14.48 AfriNIC Region origin ASes announcing only one prefix: 101 AfriNIC Region transit ASes present in the Internet Routing Table: 75 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 14861056 Equivalent to 0 /8s, 226 /16s and 195 /24s Percentage of available AfriNIC address space announced: 44.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1865 8405 475 Korea Telecom (KIX) 17488 1307 134 133 Hathway IP Over Cable Interne 4755 1287 287 136 TATA Communications formerly 4134 1016 20245 401 CHINANET-BACKBONE 7545 1010 199 101 TPG Internet Pty Ltd 9583 1003 75 500 Sify Limited 18101 997 221 41 Reliance Infocom Ltd Internet 17974 939 282 20 PT TELEKOMUNIKASI INDONESIA 24560 844 300 167 Bharti Airtel Ltd., Telemedia 4808 843 1585 215 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4061 3842 311 bellsouth.net, inc. 4323 2120 1057 379 Time Warner Telecom 1785 1794 698 131 PaeTec Communications, Inc. 7018 1565 5757 1005 AT&T WorldNet Services 20115 1537 1497 656 Charter Communications 2386 1326 616 934 AT&T Data Communications Serv 3356 1230 10949 425 Level 3 Communications, LLC 6478 1162 246 165 AT&T Worldnet Services 11492 1142 222 14 Cable One 22773 1127 2604 70 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 594 40 5 United Telecom of Georgia 30890 450 101 207 Evolva Telecom 3292 449 1900 391 TDC Tele Danmark 702 421 1870 333 UUNET - Commercial IP service 8551 400 355 36 Bezeq International 8866 392 117 18 Bulgarian Telecommunication C 3320 364 7072 318 Deutsche Telekom AG 3301 356 1413 317 TeliaNet Sweden 3215 347 3206 103 France Telecom Transpac 12479 330 576 5 Uni2 Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1533 2892 237 UniNet S.A. de C.V. 10620 1028 229 156 TVCABLE BOGOTA 28573 947 730 82 NET Servicos de Comunicao S.A 7303 686 360 97 Telecom Argentina Stet-France 22047 546 310 15 VTR PUNTO NET S.A. 6503 508 168 195 AVANTEL, S.A. 7738 477 922 30 Telecomunicacoes da Bahia S.A 11830 474 308 56 Instituto Costarricense de El 18881 471 268 11 Global Village Telecom 3816 454 195 69 Empresa Nacional de Telecomun Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 914 445 10 TEDATA 24863 710 144 41 LINKdotNET AS number 36992 573 131 167 Etisalat MISR 3741 274 853 233 The Internet Solution 33776 262 14 11 Starcomms Nigeria Limited 2018 211 215 122 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 171 19 9 Ci Telecom Autonomous system 24835 136 78 11 RAYA Telecom - Egypt 29975 133 506 14 Vodacom Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4061 3842 311 bellsouth.net, inc. 4323 2120 1057 379 Time Warner Telecom 4766 1865 8405 475 Korea Telecom (KIX) 1785 1794 698 131 PaeTec Communications, Inc. 7018 1565 5757 1005 AT&T WorldNet Services 20115 1537 1497 656 Charter Communications 8151 1533 2892 237 UniNet S.A. de C.V. 2386 1326 616 934 AT&T Data Communications Serv 17488 1307 134 133 Hathway IP Over Cable Interne 4755 1287 287 136 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2120 1741 Time Warner Telecom 1785 1794 1663 PaeTec Communications, Inc. 4766 1865 1390 Korea Telecom (KIX) 8151 1533 1296 UniNet S.A. de C.V. 17488 1307 1174 Hathway IP Over Cable Interne 4755 1287 1151 TATA Communications formerly 11492 1142 1128 Cable One 22773 1127 1057 Cox Communications, Inc. 18566 1059 1049 Covad Communications 6478 1162 997 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.190.64.0/22 28683 Office des Postes et telecomm 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.220.144.0/20 36918 ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 36918 ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.24.0/22 25747 VSC Satellite Co 41.223.92.0/22 36936 >>UNKNOWN<< Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:25 /11:66 /12:192 /13:389 /14:669 /15:1238 /16:10989 /17:5185 /18:8756 /19:18125 /20:22106 /21:22221 /22:28728 /23:28428 /24:162777 /25:942 /26:1177 /27:589 /28:137 /29:14 /30:8 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2628 4061 bellsouth.net, inc. 4766 1477 1865 Korea Telecom (KIX) 1785 1255 1794 PaeTec Communications, Inc. 4323 1065 2120 Time Warner Telecom 17488 1060 1307 Hathway IP Over Cable Interne 11492 1052 1142 Cable One 18566 1040 1059 Covad Communications 7018 943 1565 AT&T WorldNet Services 10620 934 1028 TVCABLE BOGOTA 18101 868 997 Reliance Infocom Ltd Internet Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:12 8:247 12:1986 13:10 15:22 16:3 17:8 20:39 24:1368 27:1 32:48 38:648 40:100 41:2008 44:3 46:1 47:23 52:6 55:2 56:2 57:24 58:629 59:638 60:413 61:1094 62:1051 63:1982 64:3700 65:2343 66:3455 67:1812 68:1050 69:2802 70:697 71:240 72:1859 73:2 74:1952 75:245 76:315 77:828 78:580 79:414 80:997 81:772 82:449 83:447 84:675 85:1023 86:384 87:677 88:428 89:1547 90:78 91:2702 92:431 93:1139 94:1377 95:551 96:230 97:304 98:526 99:26 109:425 110:304 111:454 112:243 113:236 114:384 115:596 116:1027 117:630 118:378 119:929 120:148 121:844 122:1387 123:879 124:1054 125:1286 128:208 129:204 130:142 131:486 132:219 133:17 134:194 135:44 136:230 137:171 138:242 139:94 140:471 141:137 142:375 143:346 144:412 145:50 146:414 147:169 148:582 149:249 150:151 151:169 152:258 153:167 154:2 155:278 156:181 157:324 158:96 159:356 160:307 161:179 162:269 163:163 164:310 165:507 166:508 167:394 168:680 169:157 170:729 171:46 172:2 173:555 174:623 175:65 178:8 180:349 182:35 183:232 184:19 186:334 187:242 188:1177 189:711 190:3574 192:5723 193:4562 194:3361 195:2802 196:1174 198:3554 199:3380 200:5280 201:1479 202:8051 203:8298 204:4054 205:2169 206:2472 207:2752 208:3912 209:3366 210:2551 211:1200 212:1717 213:1689 214:263 215:61 216:4463 217:1514 218:491 219:427 220:1076 221:380 222:313 End of report From micheal at spmedicalgroup.com Fri Mar 19 16:14:02 2010 From: micheal at spmedicalgroup.com (Micheal Patterson) Date: Fri, 19 Mar 2010 16:14:02 -0500 Subject: AT&T MIS Testing Center Manager Message-ID: Is there a manager in the AT&T MIS Testing center by chance on the list, or anyone have a contact that can put me in direct touch with one? I've got one circuit out of a bonded set that the testing center has had in a loopback now for almost 24 hours and after level 3 escalation, it's still not normaled up, my csu still shows a loop up, and all calls today, approx 1 every hour and half for the last 8 hours has resulted in "We show the smartjack tested good, but we're showing that it's looping back toward the CSU, we'll open up a ticket with the testing center to request the loop be removed." Thanks. -- Micheal Patterson From cidr-report at potaroo.net Fri Mar 19 17:00:01 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Mar 2010 22:00:01 GMT Subject: BGP Update Report Message-ID: <201003192200.o2JM01vK037512@wattle.apnic.net> BGP Update Report Interval: 11-Mar-10 -to- 18-Mar-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS665 99574 8.9% 1059.3 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 2 - AS45985 23578 2.1% 5894.5 -- DAEWOOSEC Daewoo Securities Co., Ltd. 3 - AS14420 17434 1.6% 44.4 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 4 - AS30890 15750 1.4% 35.6 -- EVOLVA Evolva Telecom s.r.l. 5 - AS9829 13664 1.2% 27.7 -- BSNL-NIB National Internet Backbone 6 - AS31055 13155 1.2% 3288.8 -- CONSULTIX-AS Consultix GmbH 7 - AS35805 12226 1.1% 20.7 -- UTG-AS United Telecom AS 8 - AS9808 10983 1.0% 24.4 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 9 - AS12479 10423 0.9% 694.9 -- UNI2-AS Uni2 - Lince telecomunicaciones 10 - AS8452 9035 0.8% 18.0 -- TEDATA TEDATA 11 - AS16569 8216 0.7% 8216.0 -- ASN-CITY-OF-CALGARY - City of Calgary 12 - AS33776 8174 0.7% 29.0 -- STARCOMMS-ASN 13 - AS7738 7862 0.7% 16.5 -- Telecomunicacoes da Bahia S.A. 14 - AS26025 7195 0.7% 7195.0 -- COC - City of Calgary 15 - AS20115 7025 0.6% 8.5 -- CHARTER-NET-HKY-NC - Charter Communications 16 - AS27747 6408 0.6% 37.3 -- Telecentro S.A. 17 - AS1659 6067 0.5% 19.9 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center 18 - AS10052 5951 0.5% 2975.5 -- KNU-AS Kyungpook National Univ. 19 - AS17974 5867 0.5% 8.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS27097 5815 0.5% 1453.8 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16569 8216 0.7% 8216.0 -- ASN-CITY-OF-CALGARY - City of Calgary 2 - AS26025 7195 0.7% 7195.0 -- COC - City of Calgary 3 - AS45985 23578 2.1% 5894.5 -- DAEWOOSEC Daewoo Securities Co., Ltd. 4 - AS31055 13155 1.2% 3288.8 -- CONSULTIX-AS Consultix GmbH 5 - AS10052 5951 0.5% 2975.5 -- KNU-AS Kyungpook National Univ. 6 - AS27097 5815 0.5% 1453.8 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 7 - AS665 99574 8.9% 1059.3 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 8 - AS22395 968 0.1% 968.0 -- GHCO-INTERNAP - Goldenberg Hehmeyer 9 - AS5691 2630 0.2% 876.7 -- MITRE-AS-5 - The MITRE Corporation 10 - AS12479 10423 0.9% 694.9 -- UNI2-AS Uni2 - Lince telecomunicaciones 11 - AS5554 653 0.1% 653.0 -- INTEGRA Integra Information Co. Ltd 12 - AS31496 615 0.1% 615.0 -- ATNET-AS ATNET Autonomous System 13 - AS35400 1082 0.1% 541.0 -- MFIST Interregoinal Organization Network Technologies 14 - AS45960 502 0.1% 502.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 15 - AS28052 496 0.0% 496.0 -- Arte Radiotelevisivo Argentino 16 - AS8346 2569 0.2% 428.2 -- SONATEL-AS Autonomous System 17 - AS32794 400 0.0% 400.0 -- ICFG - International Church of the Foursquare Gospel 18 - AS34875 2293 0.2% 382.2 -- YANFES OJSC "Uralsviazinform" 19 - AS18399 1409 0.1% 352.2 -- BAGAN-TRANSIT-AS Bagan Cybertech IDC & Teleport International Transit 20 - AS35291 651 0.1% 325.5 -- ICOMM-AS SC Internet Communication Systems SRL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 62.168.199.0/24 13100 1.1% AS31055 -- CONSULTIX-AS Consultix GmbH 2 - 208.98.230.0/24 8216 0.7% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 3 - 208.98.231.0/24 7195 0.6% AS26025 -- COC - City of Calgary 4 - 155.230.0.0/16 5927 0.5% AS10052 -- KNU-AS Kyungpook National Univ. 5 - 210.92.10.0/24 5895 0.5% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 6 - 210.92.6.0/24 5895 0.5% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 7 - 210.92.4.0/24 5895 0.5% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 8 - 123.140.107.0/24 5893 0.5% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 9 - 214.15.217.0/24 5673 0.5% AS27097 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 10 - 41.235.80.0/24 5590 0.5% AS8452 -- TEDATA TEDATA 11 - 199.114.154.0/24 3567 0.3% AS1733 -- CENTAF-SWA - 754th Electronic Systems Group 12 - 85.60.192.0/23 3060 0.3% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 13 - 206.184.16.0/24 2874 0.2% AS174 -- COGENT Cogent/PSI 14 - 205.101.192.0/24 2658 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 15 - 205.109.96.0/20 2658 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 16 - 205.109.208.0/20 2657 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 17 - 205.109.160.0/19 2651 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 18 - 205.110.243.0/24 2647 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 19 - 205.101.66.0/24 2646 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 20 - 199.121.123.0/24 2638 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 19 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Mar 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201003192200.o2JM00MP037505@wattle.apnic.net> This report has been generated at Fri Mar 19 21:11:43 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 12-03-10 316317 194613 13-03-10 316114 194620 14-03-10 316308 194520 15-03-10 316419 194586 16-03-10 316559 194728 17-03-10 316754 194931 18-03-10 316966 194996 19-03-10 316783 195279 AS Summary 33916 Number of ASes in routing system 14488 Number of ASes announcing only one prefix 4402 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 95798016 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'). --- 19Mar10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 318238 195224 123014 38.7% All ASes AS6389 4063 317 3746 92.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4402 1260 3142 71.4% TWTC - tw telecom holdings, inc. AS4766 1865 489 1376 73.8% KIXS-AS-KR Korea Telecom AS1785 1794 659 1135 63.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1287 200 1087 84.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1127 75 1052 93.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1059 33 1026 96.9% COVAD - Covad Communications Co. AS17488 1307 349 958 73.3% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1535 621 914 59.5% Uninet S.A. de C.V. AS10620 1028 170 858 83.5% Telmex Colombia S.A. AS18101 998 159 839 84.1% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS19262 1082 245 837 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS7545 1030 247 783 76.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS6478 1162 411 751 64.6% ATT-INTERNET3 - AT&T WorldNet Services AS5668 803 197 606 75.5% AS-5668 - CenturyTel Internet Holdings, Inc. AS4808 843 242 601 71.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 678 85 593 87.5% MPX-AS Microplex PTY LTD AS4134 1023 435 588 57.5% CHINANET-BACKBONE No.31,Jin-rong Street AS7303 686 104 582 84.8% Telecom Argentina S.A. AS8452 914 345 569 62.3% TEDATA TEDATA AS7018 1565 1006 559 35.7% ATT-INTERNET4 - AT&T WorldNet Services AS24560 843 294 549 65.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1230 688 542 44.1% LEVEL3 Level 3 Communications AS17908 772 234 538 69.7% TCISL Tata Communications AS4780 657 157 500 76.1% SEEDNET Digital United Inc. AS22047 546 53 493 90.3% VTR BANDA ANCHA S.A. AS17676 575 87 488 84.9% GIGAINFRA Softbank BB Corp. AS9443 555 75 480 86.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS28573 947 475 472 49.8% NET Servicos de Comunicao S.A. AS11492 1142 671 471 41.2% CABLEONE - CABLE ONE, INC. Total 37518 10383 27135 72.3% Top 30 total Possible Bogus Routes 2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.190.64.0/22 AS28683 BENINTELECOM 41.202.96.0/19 AS29571 CITelecom-AS 41.220.144.0/20 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.24.0/22 AS25747 VSC-SATELLITE-CO - VSC Satellite Co. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 50.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.193.160.0/19 AS22351 INTELSAT Intelsat Global BGP Routing Policy 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 78.41.80.0/24 AS29158 DE-IP69 Tux-Service 78.41.81.0/24 AS29158 DE-IP69 Tux-Service 78.41.82.0/24 AS29158 DE-IP69 Tux-Service 78.41.83.0/24 AS29158 DE-IP69 Tux-Service 78.41.84.0/24 AS29158 DE-IP69 Tux-Service 78.41.86.0/24 AS29158 DE-IP69 Tux-Service 78.41.87.0/24 AS29158 DE-IP69 Tux-Service 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 80.250.32.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.34.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering AS 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 178.148.0.0/15 AS31042 SERBIA-BROADBAND-AS Serbia BroadBand-Srpske Kablovske mreze d.o.o. 178.216.0.0/21 AS50751 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.29.40.0/22 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 196.32.96.0/20 AS33787 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.254.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.216.4.0/22 AS23889 MAURITIUS-TELECOM-AS-AP 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.77.138.0/23 AS24487 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.184.0/23 AS24487 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.154.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.124.96.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.100.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.104.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.160.130.0/23 AS24487 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/24 AS31997 209.87.223.0/24 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.29.208.0/23 AS33774 DJAWEB 217.29.212.0/23 AS33774 DJAWEB Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jmamodio at gmail.com Fri Mar 19 17:03:02 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 19 Mar 2010 17:03:02 -0500 Subject: NSP-SEC In-Reply-To: <20100319134244.GA98417@ussenterprise.ufp.org> References: <620fd17c1003190250i13e13ba9y286ae54e895d8a8e@mail.gmail.com> <20100319134244.GA98417@ussenterprise.ufp.org> Message-ID: <202705b1003191503g3c2569e7iaa452ed5426ad57b@mail.gmail.com> On Fri, Mar 19, 2010 at 8:42 AM, Leo Bicknell wrote: > > I'd like to nominate this for the Best of Nanog 2010. +1. Does the nomination include a sample ? J From David_Hankins at isc.org Fri Mar 19 18:26:13 2010 From: David_Hankins at isc.org (David W. Hankins) Date: Fri, 19 Mar 2010 16:26:13 -0700 Subject: ISC DHCP server failover In-Reply-To: <20100317142206.GB4773@dan.olp.net> References: <20100317142206.GB4773@dan.olp.net> Message-ID: <20100319232613.GD5775@isc.org> On Wed, Mar 17, 2010 at 09:22:06AM -0500, Dan White wrote: > The servers stop balancing their addresses, and one server starts to > exhibit 'peer holds all free leases' in its logs, in which case we need to > restart the dhcpd process(es) to force a rebalance. If restarting one or both dhcpd processes corrects a pool balancing problem, then I suspect what you're looking at is a bug where the servers would fail to schedule a reconnection if the failover socket is lost in a particular way. Because the protocol also uses a message exchange inside the TCP channel to determine if the socket is up (rather than just TCP keepalives) this can sometimes happen even without a network outage during load spikes or other brief hiccups on the partner DHCP server. So far as I know that particular problem is fixed in current maintenance releases (4.1.1, 4.0.2), so I'm curious if you are using them. But it's also possible that your pools need rebalancing more often than the default minimum rebalance interval. > In some cases, and I'm not sure which equipment may be to blame, if one > server goes down then the other server will not hand out addresses to > clients which had originally received addresses from the failed server. > We've dealt with that by balancing our lease times with our MTTR for a > failed server. To me this sounds like another symptom of the failover connection between the servers failing and not being reconnected. It would explain why the server doesn't have the partner's "recently active" bindings, it wouldn't have received updated information if the socket was inactive. My own opinion of the failover software is that it may be clunky and hard to use (we're working on that), but it is reliable. One of the warnings I want to give when someone is interested in deploying failover pairs of ISC DHCP servers is to still be prepared to react to a server failure. Unlike other fault tolerance protocols where losing communication with the peer can safely be assumed that the peer is off-line, DHCP servers can go out of communication with each other while still being able to reach clients. To cope with this, failover segregates the idea of entering a "communications-interrupted" state from a "partner-down" state, and many rules govern how servers can allocate or extend leases to ensure there are no addressing conflicts (caused by the servers giving one IP address to two different clients without the knowledge of the other server). Failover essentially bridges the gap of a server outage by giving each server in the pair roughly half of the remaining pool of unallocated addresses, which they individually allocate from normally and when operating in communications-interrupted. Either server can continue to extend already active leases, letting clients keep the addresses they already have, but if it runs out of free* leases, or if the current clients' leases are allowed to expire, it won't be able to admit any new clients or extend expired leases. Because the software can't detect if its peer is truly off-line, the operator must manually move the surviving server to partner-down to inform it that it's operating alone in order to use expired or leases in the peer's free pool. Most people have a bad experience with failover, and therefore form a poor opinion of it, because of experiencing such an event without knowing of the need to transition the server state explicitly during an outage. It isn't as automatic as the word 'failover' makes it sound. For now the lesson is that failover gives you precious hours or days to find a terminal and repair the partner server or put the surviving server into partner-down. It's also quite a good idea to monitor the failover state of your servers and ensure they aren't spending a great deal of time in communications-interrupted. NEW in 4.2.0: There is a new configuration option intended for servers sharing a "Heartbeat Cable", or similar situations where the operator is convinced with certainty that a failover socket disconnect likely implies the peer is truly down. A configurable timeout can now be entered such that the server automatically enters partner-down. Note that the failover protocol still requires an "MCLT delay" before the server is allowed to use the peer's free leases, but this is not normally a problem in usual operation. There is a new optimization that significantly increases endurance during communications-interrupted and in many cases could mean you could remain in that state indefinitely, but it won't help you for example if the active load requires the full free pool; it can't allocate the peer's leases. So it doesn't replace entering partner-down for long-term outages. These features were both provided in 4.2.0 (a1 and a2 respectively as memory serves), currently an alpha which I hope to move to its first beta soon. * I'm simplifying a lot to make this shorter and easier to read, and also using language that failover overloads. If you really want to know all about failover internals, ask us on dhcp-users. :) -- David W. Hankins BIND 10 needs more DHCP voices, Software Engineer there just aren't enough in our heads. Internet Systems Consortium, Inc. http://www.isc.org/bind10 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mike-nanog at tiedyenetworks.com Fri Mar 19 19:10:04 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 19 Mar 2010 17:10:04 -0700 Subject: ISC DHCP server failover In-Reply-To: <20100319232613.GD5775@isc.org> References: <20100317142206.GB4773@dan.olp.net> <20100319232613.GD5775@isc.org> Message-ID: <4BA4125C.2090309@tiedyenetworks.com> David W. Hankins wrote: > On Wed, Mar 17, 2010 at 09:22:06AM -0500, Dan White wrote: > >> The servers stop balancing their addresses, and one server starts to >> exhibit 'peer holds all free leases' in its logs, in which case we need to >> restart the dhcpd process(es) to force a rebalance. >> > > If restarting one or both dhcpd processes corrects a pool balancing > problem, then I suspect what you're looking at is a bug where the > servers would fail to schedule a reconnection if the failover socket > is lost in a particular way. Because the protocol also uses a message > exchange inside the TCP channel to determine if the socket is up > (rather than just TCP keepalives) this can sometimes happen even > without a network outage during load spikes or other brief hiccups on > With all due respect and acknowledgment of the tremendous contributions of ISC and you yourself Mr. Hankins, I have to comment that failover in isc-dhcp is broken by design because it requires the amount of handholding and operator thinking in the event of a failure that you explained to us at length is required. Failure needs to be handled automatically and without any intervention at all, otherwise you might as well not have it and I think most network operators would agree. I am certainly not prepared to develop proof of concept code or go the full route of developing such a server myself, however, I belive firmly that a failover implementation in dhcp could be designed as a counterpoint to the current implementation that is reliable, simple, scalable and requiring no special procedures once a 'break' occurs. The method used by isc-dhcpd, I think, creates the problem of the potential for unreliable failover because it's not designed for the 'right' problem. But there are example implementations - such as vrrp/carp - that would form the basis of trustworthy dhcp failover protocol. Your key issues are a) broadcast discovery packets, which every listening host on the lan segment (such as 1 or more slaves) can easily respond to, and b) unicast frames from relay agents and others, which could easily be handled by a virtual mac/shared ip address by a group of slaves. This means that redundancy of more than 2 hosts is already possible. The last pieces are protocol for servers to join and leave the pool of hosts serving dhcp, a master election protocol that pre-determines the order of slaves to fail over to in order to avoid the half-brain syndrome, a sanity checking protocol to ensure the elected master is sane and kicking (eg: the slaves all hit the master with, what else, dhcp requests), and a well defined group database update protocol over the network so that leases hit some fixed storage somewhere, sometime. Just my $0.02 worth. Mike- From smeuse at mara.org Fri Mar 19 20:30:20 2010 From: smeuse at mara.org (Steve Meuse) Date: Fri, 19 Mar 2010 21:30:20 -0400 Subject: CRS-3 In-Reply-To: <6cd462c01003092255s7f4c6a9bm4b452e8527991811@mail.gmail.com> References: <6cd462c01003092255s7f4c6a9bm4b452e8527991811@mail.gmail.com> Message-ID: <20100320013020.GA1574@mara.org> Paul Ferguson expunged (fergdawgster at gmail.com): > -----BEGIN PGP SIGNED MESSAGE----- > > > > Anyone have any idea how much a fully configured CRS-3 would cost? Or > > how much power it would consume? Or how much heat it would generate? > > > > Admittedly, my information on these topics comes from NPR these days. :-) > > They said it costs ~US$90k, and that AT&T was in trails. $90k is the price of the special lift jack you need to move them around :) -Steve From deleskie at gmail.com Fri Mar 19 20:37:48 2010 From: deleskie at gmail.com (jim deleskie) Date: Fri, 19 Mar 2010 22:37:48 -0300 Subject: CRS-3 In-Reply-To: <20100320013020.GA1574@mara.org> References: <6cd462c01003092255s7f4c6a9bm4b452e8527991811@mail.gmail.com> <20100320013020.GA1574@mara.org> Message-ID: Thats funny, not sure if Cisco sells one or not but back in the day, I worked @ Avici, and we did in fact have a special jack used to move the chassis around :) -jim On Fri, Mar 19, 2010 at 10:30 PM, Steve Meuse wrote: > Paul Ferguson expunged (fergdawgster at gmail.com): > >> -----BEGIN PGP SIGNED MESSAGE----- >> > >> > Anyone have any idea how much a fully configured CRS-3 would cost? ?Or >> > how much power it would consume? ?Or how much heat it would generate? >> > >> >> Admittedly, my information on these topics comes from NPR these days. :-) >> >> They said ?it costs ~US$90k, and that AT&T was in trails. > > $90k is the price of the special lift jack you need to move them around :) > > -Steve > > > > From sthaug at nethelp.no Sat Mar 20 03:43:41 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 20 Mar 2010 09:43:41 +0100 (CET) Subject: ISC DHCP server failover In-Reply-To: <4BA4125C.2090309@tiedyenetworks.com> References: <20100317142206.GB4773@dan.olp.net> <20100319232613.GD5775@isc.org> <4BA4125C.2090309@tiedyenetworks.com> Message-ID: <20100320.094341.74713325.sthaug@nethelp.no> > With all due respect and acknowledgment of the tremendous contributions > of ISC and you yourself Mr. Hankins, I have to comment that failover in > isc-dhcp is broken by design because it requires the amount of > handholding and operator thinking in the event of a failure that you > explained to us at length is required. Failure needs to be handled > automatically and without any intervention at all, otherwise you might > as well not have it and I think most network operators would agree. Note that this method of handling failover is inherent in the original DHCP failover design. See http://tools.ietf.org/id/draft-ietf-dhc-failover-12.txt Specifically, quoting from the above draft, "While this technique works in some domains, having the only server to which a DHCP client can communicate voluntarily shut itself down seems like something worth avoiding. The failover protocol will operate correctly while both servers are unable to communicate, whether they are both running or not. At some point there may be resource contention, and if one of the servers is actually down, then the operator can inform the operational server and the operational server will be able to use all of the failed server's resources." I certainly cannot speak for "most network operators". However, I will note that I have been aware of this behavior of the IDC DHCP server as long as I have been running it in failover mode. > I am certainly not prepared to develop proof of concept code or go the > full route of developing such a server myself, however, I belive firmly > that a failover implementation in dhcp could be designed as a > counterpoint to the current implementation that is reliable, simple, > scalable and requiring no special procedures once a 'break' occurs. And which implements failover protocol in the IETF draft? Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jess.kitchen at adjacentnetworks.net Sat Mar 20 06:27:44 2010 From: jess.kitchen at adjacentnetworks.net (Jess Kitchen) Date: Sat, 20 Mar 2010 11:27:44 +0000 (GMT) Subject: Help with a 3561 debug Message-ID: Hello, If anyone is single homed via Savvis AS3561 that could spare a minute to help with a couple of mtr/tcptraceroute/iperfs that would be great- trying to drill down a peculiar and intermittent issue that has been occurring since some time Thursday (packets indescriminately dropped on the floor but only on particular paths) Please mail offlist, thanks -- Jess Kitchen From lukasz at bromirski.net Sat Mar 20 08:16:53 2010 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Sat, 20 Mar 2010 14:16:53 +0100 Subject: Using private APNIC range in US In-Reply-To: References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: <4BA4CAC5.6060300@bromirski.net> On 2010-03-18 19:35, Jared Mauch wrote: > http://www.google.com/search?q=1.2.3.4+site%3Acisco.com > I know that the University of Michigan utilize 1.2.3.4 for their > captive portal login/logout pages as recently as monday when I was > on the medical campus. A lot of cheap, low-end devices (sometimes with names of well-know vendors) use IPs like 1.1.1.1 and 1.2.3.4 as captive portal IPs to authenticate connecting clients. A lot of "WLAN hotspots" users will have problems reaching 1/8 unless they connect via VPN to corporate and browse from there or something like that. The question is how soon 1/8 will have interesting content to serve, as I know at least one popular hotel chain in Europe using "1.1.1.1". -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end." | http://lukasz.bromirski.net From ra at app-tec.com Sat Mar 20 12:02:09 2010 From: ra at app-tec.com (Rashed Alwarrag) Date: Sat, 20 Mar 2010 20:02:09 +0300 Subject: IPtv solutions Message-ID: Dear Nanog I am interested in IPtv solutions so Can anybody advice me what is the best IPTv products/solutions that is wildly deployed in most of the Service provider and if they have courses available ? Thanks a lot Rashed Alwarrag Applied Technologies From ra at app-tec.com Sat Mar 20 12:06:43 2010 From: ra at app-tec.com (Rashed Alwarrag) Date: Sat, 20 Mar 2010 20:06:43 +0300 Subject: IPtv solutions Message-ID: Dear Nanog I am interested in IPtv solutions so Can anybody advice me what is the best IPTv products/solutions that is Widely deployed in most of the Service provider and if they have courses available ? Thanks a lot Rashed Alwarrag Applied Technologies From dwhite at olp.net Sat Mar 20 13:20:09 2010 From: dwhite at olp.net (Dan White) Date: Sat, 20 Mar 2010 13:20:09 -0500 Subject: ISC DHCP server failover In-Reply-To: <4BA4125C.2090309@tiedyenetworks.com> References: <20100317142206.GB4773@dan.olp.net> <20100319232613.GD5775@isc.org> <4BA4125C.2090309@tiedyenetworks.com> Message-ID: <20100320182009.GB24617@dan.olp.net> On 19/03/10?17:10?-0700, Mike wrote: > David W. Hankins wrote: >> On Wed, Mar 17, 2010 at 09:22:06AM -0500, Dan White wrote: >> >>> The servers stop balancing their addresses, and one server starts to >>> exhibit 'peer holds all free leases' in its logs, in which case we need to >>> restart the dhcpd process(es) to force a rebalance. >>> >> >> If restarting one or both dhcpd processes corrects a pool balancing >> problem, then I suspect what you're looking at is a bug where the >> servers would fail to schedule a reconnection if the failover socket >> is lost in a particular way. Because the protocol also uses a message >> exchange inside the TCP channel to determine if the socket is up >> (rather than just TCP keepalives) this can sometimes happen even >> without a network outage during load spikes or other brief hiccups on >> > > > With all due respect and acknowledgment of the tremendous contributions > of ISC and you yourself Mr. Hankins, I have to comment that failover in > isc-dhcp is broken by design because it requires the amount of > handholding and operator thinking in the event of a failure that you > explained to us at length is required. Failure needs to be handled > automatically and without any intervention at all, otherwise you might > as well not have it and I think most network operators would agree. I don't want to defend bad code where it may exist, but I view the problems we've encountered with ISC DHCP to be minor compared to the benefits. It may not be fair to compare DHCP failover to redundancy in a routing scenario. In a routing failure, I'd be highly motivated to find the root cause, open tickets, and get the problem fixed. In a scenario where a couple of customers are unable to pull an IP address, every few months, I'm OK with manual intervention as long as state is maintained. I'd argue that it's more important to maintain data integrity (no two servers think they own the same IP) than availability (where one server is too aggressive and corrupts data). That's true of much of the open source software I use, such as cyrus (email) replication and openldap synchronization. Given the resources I and others in my company have to deal with issues, it's always a matter of putting out the biggest fire. If/when problems with DHCP failover become a big enough issues, we'll spend the time to find out what in our network is causing the issue and fix it, or find out what the bug is in the software and open a bug report. All problems are fixable given enough resources, and enough motivation. -- Dan White From hank at efes.iucc.ac.il Sat Mar 20 13:30:01 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 20 Mar 2010 20:30:01 +0200 (IST) Subject: NSP-SEC In-Reply-To: <1269006269.1220.135.camel@petrie> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> Message-ID: On Fri, 19 Mar 2010, William Pitcock wrote: > On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: >> An ongoing area of work is to build better closed, >> trusted communities without leaks. > > Have you ever considered that public transparency might not be a bad > thing? This seems to be the plight of many security people, that they > have to be 100% secretive in everything they do, which is total > bullshit. > > Just saying. How exactly would being transparent for the following help Internet security: "I am seeing a new malware infection vector via port 91714 coming from the IP range of 32.0.0.0/8 that installs a rootkit after visiting the web page http://www.trythisoutnow.com/. In addition, it has credit card and pswd stealing capabilities and sends the details to a maildrop at trythisoutnow at gmail.com" The only upside of being transparent is alerting the miscreant to change the vector and maildrop. Regards, Hank From nenolod at systeminplace.net Sat Mar 20 13:37:58 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 20 Mar 2010 13:37:58 -0500 Subject: NSP-SEC In-Reply-To: References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> Message-ID: <1269110278.1220.147.camel@petrie> On Sat, 2010-03-20 at 20:30 +0200, Hank Nussbacher wrote: > On Fri, 19 Mar 2010, William Pitcock wrote: > > > On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: > >> An ongoing area of work is to build better closed, > >> trusted communities without leaks. > > > > Have you ever considered that public transparency might not be a bad > > thing? This seems to be the plight of many security people, that they > > have to be 100% secretive in everything they do, which is total > > bullshit. > > > > Just saying. > > How exactly would being transparent for the following help Internet > security: > > "I am seeing a new malware infection vector via port 91714 coming from the > IP range of 32.0.0.0/8 that installs a rootkit after visiting the web page > http://www.trythisoutnow.com/. In addition, it has credit card and pswd > stealing capabilities and sends the details to a maildrop at > trythisoutnow at gmail.com" > > The only upside of being transparent is alerting the miscreant to change > the vector and maildrop. That is not what I mean and you know it. What I mean is: why can't anyone contribute valuable information to the security community? It is next to impossible to meet so-called 'trusted people' if you're new to the game, which is counter-productive. If you're a 15 year old kid and you just discovered a way to own the latest IOS, for example, how do you know who to tell about it? William From streiner at cluebyfour.org Sat Mar 20 13:43:00 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 20 Mar 2010 14:43:00 -0400 (EDT) Subject: NSP-SEC In-Reply-To: <1269110278.1220.147.camel@petrie> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> Message-ID: On Sat, 20 Mar 2010, William Pitcock wrote: > If you're a 15 year old kid and you just discovered a way to own the > latest IOS, for example, how do you know who to tell about it? Report the issue to the vendor? This is pretty common practice today. jms From hank at efes.iucc.ac.il Sat Mar 20 13:47:45 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 20 Mar 2010 20:47:45 +0200 (IST) Subject: NSP-SEC In-Reply-To: <1269110278.1220.147.camel@petrie> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> Message-ID: On Sat, 20 Mar 2010, William Pitcock wrote: > What I mean is: why can't anyone contribute valuable information to the > security community? It is next to impossible to meet so-called 'trusted > people' if you're new to the game, which is counter-productive. > > If you're a 15 year old kid and you just discovered a way to own the > latest IOS, for example, how do you know who to tell about it? If I was such a clever 15 year old I would go to Google and enter "contacting cisco ios security" which would lead me to -> http://www.cisco.com/en/US/products/products_security_advisories_listing.html which would lead me to -> http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html Same exercise can be repeated for most vendors you can choose. -Hank From gfortaine at live.com Sat Mar 20 14:56:39 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Sat, 20 Mar 2010 20:56:39 +0100 Subject: NSP-SEC In-Reply-To: <1269110278.1220.147.camel@petrie> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> Message-ID: On 03/20/2010 07:37 PM, William Pitcock wrote: > On Sat, 2010-03-20 at 20:30 +0200, Hank Nussbacher wrote: > >> On Fri, 19 Mar 2010, William Pitcock wrote: >> >> >>> On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: >>> >>>> An ongoing area of work is to build better closed, >>>> trusted communities without leaks. >>>> >>> Have you ever considered that public transparency might not be a bad >>> thing? This seems to be the plight of many security people, that they >>> have to be 100% secretive in everything they do, which is total >>> bullshit. >>> >>> Just saying. >>> >> How exactly would being transparent for the following help Internet >> security: >> >> "I am seeing a new malware infection vector via port 91714 coming from the >> IP range of 32.0.0.0/8 that installs a rootkit after visiting the web page >> http://www.trythisoutnow.com/. In addition, it has credit card and pswd >> stealing capabilities and sends the details to a maildrop at >> trythisoutnow at gmail.com" >> >> The only upside of being transparent is alerting the miscreant to change >> the vector and maildrop. >> > That is not what I mean and you know it. > > What I mean is: why can't anyone contribute valuable information to the > security community? It is next to impossible to meet so-called 'trusted > people' if you're new to the game, which is counter-productive. > > I totally agree with William. Best Regards, Guillaume FORTAINE From gfortaine at live.com Sat Mar 20 15:06:25 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Sat, 20 Mar 2010 21:06:25 +0100 Subject: NSP-SEC In-Reply-To: References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> Message-ID: > If I was such a clever 15 year old I would go to Google and enter > "contacting cisco ios security" > which would lead me to -> > http://www.cisco.com/en/US/products/products_security_advisories_listing.html > > which would lead me to -> > http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html > > Same exercise can be repeated for most vendors you can choose. > I would counter argue by quoting this article : http://www.breakingpointsystems.com/community/blog/cisco-becomes-the-weakest-link-in-national-infrastructure-security Cisco Becomes The Weakest Link In National Infrastructure Security Last week Cisco released patches in their semi-annual security announcement. The publication includes 11 advisories that address 12 individual vulnerabilities. Ten of the advisories address vulnerabilities in Cisco IOS and one advisory addresses a vulnerability in Cisco Unified Communications Manager. Together these can affect routers and switches that not only use the Cisco Unified Communications Manager, but any device relying on the Cisco IOS operating system. To put it bluntly, this means a ton of devices critical to any network, and these vulnerabilities leave businesses and government agencies exposed to a barrage of attacks including denial-of-service (DDoS) or policy bypass. Much has been written about the announcement of the vulnerabilities. However, details are lacking and there are more questions than answers. This lack of information leads me to believe Cisco does not take security seriously and continues to not know how to work with the security community. Considering the lack of details and opinions, I thought I would provide a few of my own. 1) Twice A Year Is Not Enough The number of vulnerabilities patched by Cisco is not the issue. It is the potential danger these vulnerabilities pose. One of the IOS vulnerabilities allows unauthenticated attackers to bypass access control policies when the ?Object Groups for Access Control Lists (ACLs)? feature is used. Your company is most likely protecting your critical components by leveraging ACLs, now imagine they are no longer in place. The human resources database with all that W-2 information? Hackers now have your salary, your direct deposit account, your medical history and of course your social security number. To make matters worse, replace that HR database with our government?s nuclear secrets; don?t you think Iran is aware of the Cisco vulnerabilities? Scary stuff, for sure, but how long has the vulnerability been around and recognized. The answer is unknown. The only fact we have is that each of these eleven vulnerabilities may have been around for at least six months. That is an eternity in the security space and has given hackers too much time to walk in through an open door. Microsoft is often a punching bag when it comes to vulnerabilities and it is sometimes warranted, but let?s be honest, the company does a good job of patching issues on a regular basis. With Microsoft, you know that you are going to get a patch each month and important details that help you make an informed security decision. Cisco should examine its patching schedule in light of the September 24th announcement; every six months is not acceptable. 2) Updating Routers and Switches is Now Critical You can never diminish the importance of a switch or router to your network infrastructure. They are the core to any network whether in a home, a large Enterprise or the Federal Government. If one fails you know it. However, if a vulnerability let?s people through due to a hack do you know it? While everyone remembers to patch their Mac or Windows laptop, how often do they patch the router, firewall or switch? To see how up-to-date folks are with their Cisco firmware I ran a quick test. During a 1-hour scan of the Internet I found 420 responding systems and NONE were patched with any fixes from this cycle or the last. That means 420 systems, at a minimum, are susceptible to a years worth of vulnerabilities. Microsoft had enough of people not patching and now it force feeds the patches. While I?m not a fan of that solution, it does work. Cisco needs to apply the same method to its products. It is irresponsible for Cisco to run its business in a way that could cause mass disruption to critical network infrastructures including government and military services. Cisco is not the only one to blame in this mess, the people responsible for getting their routers, switches and other network equipment up-to-date also must be held accountable. How many of you updated with the patches on September 24th, the day of the announcement? The quick scan I did is telling me not many. Kelly Jackson Higgins of Dark Reading put it best, ?The dirty little secret about patching routers is that many enterprises don't bother for fear of the fallout any changes to their Cisco router software could have on the rest of the infrastructure.? 3) Testing, Testing, Testing In this case we have a great example of why every network device needs to be realistically tested under a variety of scenarios, both security and performance driven. Obviously, testing must occur at the NEMs level throughout the product lifecycle, but the enterprise must also test this equipment before it is deployed and after updates like these are made. Having the ability to quickly test equipment and the network after making updates is critical. There is no room for excuses anymore. We have been able to become more adept at updating and testing equipment and software that are given more regular patches. Just look at how Microsoft Tuesday has become a habit. Other vendors have realized that this approach, ultimately, is better for everyone. I would encourage manufacturers of any network equipment to do the same. The reason this is important is because the United States is currently fighting in two wars, heavily dependent on network technologies. The Department of Defense and other military agencies have concluded that the next major war will be waged, in great part, in cyberspace. If Cisco and other vendors guilty of the same security concerns do not get their act together it will be a war we cannot win. Until March 24, 2010, when the next Cisco bulletin is due. From sean at donelan.com Sat Mar 20 15:12:31 2010 From: sean at donelan.com (Sean Donelan) Date: Sat, 20 Mar 2010 16:12:31 -0400 (EDT) Subject: NSP-SEC In-Reply-To: <1269110278.1220.147.camel@petrie> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> Message-ID: On Sat, 20 Mar 2010, William Pitcock wrote: > If you're a 15 year old kid and you just discovered a way to own the > latest IOS, for example, how do you know who to tell about it? Read the manual? Most products and open source projects have a manual which includes information about contacting the vendor or project. If you don't have the manual, but know how to use a search engine, try a search for "reporting security vulnerabilities". Most major IT vendors and open source projects have a security reporting page. Some people have suggested vendors and projects have a common URL such as ".../security" with security information. For example if you found a vulnerability in IOS, look up the following URL to find out Cisco's reporting contacts: http://www.cisco.com/security Report a potential vulnerability in Cisco products: psirt at cisco.com Urgent technical assistance for non-security issues that involve Cisco products: Cisco Technical Support 800 553 2447 (U.S.) Worldwide Contacts Emergency response to active security incidents that involve Cisco products: PSIRT 877 228 7302 (U.S.) +1 408 525 6532 (outside U.S.) Report an incident involving the Cisco corporate network: infosec at cisco.com If you still don't know who to contact, CERT/CC maintains a world-wide map of national computer security incident response teams. http://www.cert.org/cert/map_open.html Although some of the "intra" forums between CSIRT, vendor, project, provider, researcher communities aren't open to everyone, e.g. a CSIRT forum may only have CSIRTs, an academic forum may only have academics; each of the CSIRTs, vendors, projects, providers have contacts for reporting vulnerabilities that may affect their constituencies. From ge at linuxbox.org Sat Mar 20 15:12:40 2010 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 20 Mar 2010 22:12:40 +0200 Subject: NSP-SEC In-Reply-To: <1269110278.1220.147.camel@petrie> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> Message-ID: <4BA52C38.2060403@linuxbox.org> On 3/20/10 8:37 PM, William Pitcock wrote: > That is not what I mean and you know it. What do you mean than? Hank made a good point on the type of traffic normally going through these groups. > What I mean is: why can't anyone contribute valuable information to the > security community? It is next to impossible to meet so-called 'trusted > people' if you're new to the game, which is counter-productive. Well, that's not transparency at all. That's about being able to get connected, and be trusted. That's called a process. Now, I've been preaching public engagement for years now, and indeed also made several attempts in this regard -- some very successful, others failed miserably. There are three suggestions I can make: 1. Join the open mailing lists and show your usefulness. Places where a lot of us hang out (depending on communities): NANOG, funsec. 2. Show you are responsive and responsible in handling issues in your own back yard. 3. Go to conferences and drink beer with people. > If you're a 15 year old kid and you just discovered a way to own the > latest IOS, for example, how do you know who to tell about it? That's a completely different question yet again, on vulnerability disclosure. In this particular case, try Cisco PSIRT. I recently wrote a post on how to handle the PR aspects of vulnerability disclosure, but it covers the basics in the first few paragraphs and I think it will clear the subject for you. http://www.darkreading.com/blog/archives/2009/12/security_pr_str.html Gadi. > > William > > -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From ge at linuxbox.org Sat Mar 20 15:19:46 2010 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 20 Mar 2010 22:19:46 +0200 Subject: NSP-SEC In-Reply-To: References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> Message-ID: <4BA52DE2.6030409@linuxbox.org> On 3/20/10 10:06 PM, Guillaume FORTAINE wrote: >> Same exercise can be repeated for most vendors you can choose. >> > > I would counter argue by quoting this article : I made it a goal in life to study many things, among them rhetoric. Another is culture. One basic question you should ask yourself is: who is your audience? Another would be, what is your goal? Is your purpose to counter-argue, or to ask a follow-up question such as "is Cisco responsive to reports?" or "what do I do if a network vendor is not responsive?" I had many challenges when I first joined this list due to cultural bias and the way Israelis use language, but these are behind me now and whatever misunderstandings happen these days, they are about content. It seems to me like your mind-set is of rebuttal rather than inquiry. I'd hate for you to suffer through what miscommunication can lead to on a list of techies. Your language leads people to treat you as a troll, although so far many folks here have been very nice in their answers, giving you the benefit of the doubt. Gadi. -- Gadi Evron, ge at linuxbox.org. Blog: http://gevron.livejournal.com/ From bicknell at ufp.org Sat Mar 20 15:25:20 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 20 Mar 2010 13:25:20 -0700 Subject: ISC DHCP server failover In-Reply-To: <4BA4125C.2090309@tiedyenetworks.com> References: <20100317142206.GB4773@dan.olp.net> <20100319232613.GD5775@isc.org> <4BA4125C.2090309@tiedyenetworks.com> Message-ID: <20100320202520.GA27556@ussenterprise.ufp.org> In a message written on Fri, Mar 19, 2010 at 05:10:04PM -0700, Mike wrote: > I am certainly not prepared to develop proof of concept code or go the > full route of developing such a server myself, however, I belive firmly > that a failover implementation in dhcp could be designed as a > counterpoint to the current implementation that is reliable, simple, > scalable and requiring no special procedures once a 'break' occurs. The > method used by isc-dhcpd, I think, creates the problem of the potential > for unreliable failover because it's not designed for the 'right' > problem. But there are example implementations - such as vrrp/carp - > that would form the basis of trustworthy dhcp failover protocol. Your [snip technical bits] Your method might work good where there is a LAN segment with two DHCP servers on it, and I'm sure that's how some people operate. However your method doesn't cover a much more common, and difficult case. Consider a DHCP server in Chicago and one in New York, performing DHCP for clients in Chicago, Cleveland, Pittsburg, Buffalo, Albany, and New York. When the network is broken, Chicago may still need to serve Cleveland and Pittsburg, and New York may need to serve Buffalo and Albany, and yet Chicago and New York cannot communicate during that time. Also, you want to be sure when they come back together there are no conflicts, for instance maybe Rodchester can reach both Chicago and New York while those two cannot talk to each other. LAN discovery does not work for servers 1000 miles apart. All-or nothing failure doesn't work, when each server may see part of the clients. I do think the DHCP failover protocol was perhaps over-engineered which I think is the jist of your post, but unfortunately unlike VRRP it's not always two things on the same local LAN. Perhaps there is a market for DHCP redundancy "lite" where it only handles the case of two servers on the same LAN, I dunno. -- 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 nenolod at systeminplace.net Sat Mar 20 15:23:33 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 20 Mar 2010 15:23:33 -0500 Subject: NSP-SEC In-Reply-To: <4BA52C38.2060403@linuxbox.org> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> <4BA52C38.2060403@linuxbox.org> Message-ID: <1269116613.1220.150.camel@petrie> On Sat, 2010-03-20 at 22:12 +0200, Gadi Evron wrote: > On 3/20/10 8:37 PM, William Pitcock wrote: > > That is not what I mean and you know it. > > What do you mean than? Hank made a good point on the type of traffic > normally going through these groups. My point hasn't much to do with the NSP-SEC list, I know plenty well what traffic goes through there, but instead that the security community is not welcoming to new contributors. I do run a bloody DNSBL, after all. My point was also that there are people on the NSP-SEC list that can get things done faster than PSIRT/etc do on turnaround times. Many of those same people also exist on a certain irc channel that will remain unnamed, too. William From sean at donelan.com Sat Mar 20 16:05:55 2010 From: sean at donelan.com (Sean Donelan) Date: Sat, 20 Mar 2010 17:05:55 -0400 (EDT) Subject: NSP-SEC In-Reply-To: <1269110278.1220.147.camel@petrie> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> Message-ID: On Sat, 20 Mar 2010, William Pitcock wrote: > What I mean is: why can't anyone contribute valuable information to the > security community? It is next to impossible to meet so-called 'trusted > people' if you're new to the game, which is counter-productive. How do I break into show business? http://www.imdb.com/help/show_leaf?becomeastar Is your goal to contribute valuable information to the security community? Or is your goal to become a security "celebrity" and hang out with the "trusted people?" Anyone can contribute valuable information to the security community. There are many channels to achieve this. If in fact your contributions are valuable, you will probably find the security community trying to become your buddy. If instead your goal is to become security "celebrity" hanging out with "trusted people"; that's different. Annoying the people you want to hang out with by sending e-mails to their personal addresses, and generally making a fool out of yourself is probably not going to help achieve your goal. From nanog at armorfirewall.com Sat Mar 20 16:47:42 2010 From: nanog at armorfirewall.com (George Imburgia) Date: Sat, 20 Mar 2010 16:47:42 -0500 (EST) Subject: NSP-SEC In-Reply-To: References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> Message-ID: On Sat, 20 Mar 2010, Hank Nussbacher wrote: > How exactly would being transparent for the following help Internet security: > > "I am seeing a new malware infection vector via port 91714 coming from the IP > range of 32.0.0.0/8 that installs a rootkit after visiting the web page > http://www.trythisoutnow.com/. In addition, it has credit card and pswd > stealing capabilities and sends the details to a maildrop at > trythisoutnow at gmail.com" > > The only upside of being transparent is alerting the miscreant to change the > vector and maildrop. I disagree. *All* of that information would be useful for configuring filters at my border. Cheers, George AD7RL From holwerds at jsjcorp.com Sat Mar 20 19:02:06 2010 From: holwerds at jsjcorp.com (Scott Holwerda) Date: Sat, 20 Mar 2010 20:02:06 -0400 Subject: NANOG Digest, Vol 26, Issue 106 Message-ID: <77dd01cac889$c053d0ed$2c0712ac@jsjcorp.com> 4** Sent from my Windows Mobile? phone. -----Original Message----- From: nanog-request at nanog.org Sent: Saturday, March 20, 2010 8:00 AM To: nanog at nanog.org Subject: NANOG Digest, Vol 26, Issue 106 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: ISC DHCP server failover (Mike) 2. Re: CRS-3 (Steve Meuse) 3. Re: CRS-3 (jim deleskie) 4. Re: ISC DHCP server failover (sthaug at nethelp.no) 5. Help with a 3561 debug (Jess Kitchen) ---------------------------------------------------------------------- Message: 1 Date: Fri, 19 Mar 2010 17:10:04 -0700 From: Mike Subject: Re: ISC DHCP server failover To: "David W. Hankins" Cc: nanog at nanog.org Message-ID: <4BA4125C.2090309 at tiedyenetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed David W. Hankins wrote: > On Wed, Mar 17, 2010 at 09:22:06AM -0500, Dan White wrote: > >> The servers stop balancing their addresses, and one server starts to >> exhibit 'peer holds all free leases' in its logs, in which case we need to >> restart the dhcpd process(es) to force a rebalance. >> > > If restarting one or both dhcpd processes corrects a pool balancing > problem, then I suspect what you're looking at is a bug where the > servers would fail to schedule a reconnection if the failover socket > is lost in a particular way. Because the protocol also uses a message > exchange inside the TCP channel to determine if the socket is up > (rather than just TCP keepalives) this can sometimes happen even > without a network outage during load spikes or other brief hiccups on > With all due respect and acknowledgment of the tremendous contributions of ISC and you yourself Mr. Hankins, I have to comment that failover in isc-dhcp is broken by design because it requires the amount of handholding and operator thinking in the event of a failure that you explained to us at length is required. Failure needs to be handled automatically and without any intervention at all, otherwise you might as well not have it and I think most network operators would agree. I am certainly not prepared to develop proof of concept code or go the full route of developing such a server myself, however, I belive firmly that a failover implementation in dhcp could be designed as a counterpoint to the current implementation that is reliable, simple, scalable and requiring no special procedures once a 'break' occurs. The method used by isc-dhcpd, I think, creates the problem of the potential for unreliable failover because it's not designed for the 'right' problem. But there are example implementations - such as vrrp/carp - that would form the basis of trustworthy dhcp failover protocol. Your key issues are a) broadcast discovery packets, which every listening host on the lan segment (such as 1 or more slaves) can easily respond to, and b) unicast frames from relay agents and others, which could easily be handled by a virtual mac/shared ip address by a group of slaves. This means that redundancy of more than 2 hosts is already possible. The last pieces are protocol for servers to join and leave the pool of hosts serving dhcp, a master election protocol that pre-determines the order of slaves to fail over to in order to avoid the half-brain syndrome, a sanity checking protocol to ensure the elected master is sane and kicking (eg: the slaves all hit the master with, what else, dhcp requests), and a well defined group database update protocol over the network so that leases hit some fixed storage somewhere, sometime. Just my $0.02 worth. Mike- ------------------------------ Message: 2 Date: Fri, 19 Mar 2010 21:30:20 -0400 From: Steve Meuse Subject: Re: CRS-3 To: Paul Ferguson Cc: "nanog at nanog.org list" Message-ID: <20100320013020.GA1574 at mara.org> Content-Type: text/plain; charset=us-ascii Paul Ferguson expunged (fergdawgster at gmail.com): > -----BEGIN PGP SIGNED MESSAGE----- > > > > Anyone have any idea how much a fully configured CRS-3 would cost? Or > > how much power it would consume? Or how much heat it would generate? > > > > Admittedly, my information on these topics comes from NPR these days. :-) > > They said it costs ~US$90k, and that AT&T was in trails. $90k is the price of the special lift jack you need to move them around :) -Steve ------------------------------ Message: 3 Date: Fri, 19 Mar 2010 22:37:48 -0300 From: jim deleskie Subject: Re: CRS-3 To: Steve Meuse Cc: "nanog at nanog.org list" Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Thats funny, not sure if Cisco sells one or not but back in the day, I worked @ Avici, and we did in fact have a special jack used to move the chassis around :) -jim On Fri, Mar 19, 2010 at 10:30 PM, Steve Meuse wrote: > Paul Ferguson expunged (fergdawgster at gmail.com): > >> -----BEGIN PGP SIGNED MESSAGE----- >> > >> > Anyone have any idea how much a fully configured CRS-3 would cost? ?Or >> > how much power it would consume? ?Or how much heat it would generate? >> > >> >> Admittedly, my information on these topics comes from NPR these days. :-) >> >> They said ?it costs ~US$90k, and that AT&T was in trails. > > $90k is the price of the special lift jack you need to move them around :) > > -Steve > > > > ------------------------------ Message: 4 Date: Sat, 20 Mar 2010 09:43:41 +0100 (CET) From: sthaug at nethelp.no Subject: Re: ISC DHCP server failover To: mike-nanog at tiedyenetworks.com Cc: nanog at nanog.org Message-ID: <20100320.094341.74713325.sthaug at nethelp.no> Content-Type: Text/Plain; charset=us-ascii > With all due respect and acknowledgment of the tremendous contributions > of ISC and you yourself Mr. Hankins, I have to comment that failover in > isc-dhcp is broken by design because it requires the amount of > handholding and operator thinking in the event of a failure that you > explained to us at length is required. Failure needs to be handled > automatically and without any intervention at all, otherwise you might > as well not have it and I think most network operators would agree. Note that this method of handling failover is inherent in the original DHCP failover design. See http://tools.ietf.org/id/draft-ietf-dhc-failover-12.txt Specifically, quoting from the above draft, "While this technique works in some domains, having the only server to which a DHCP client can communicate voluntarily shut itself down seems like something worth avoiding. The failover protocol will operate correctly while both servers are unable to communicate, whether they are both running or not. At some point there may be resource contention, and if one of the servers is actually down, then the operator can inform the operational server and the operational server will be able to use all of the failed server's resources." I certainly cannot speak for "most network operators". However, I will note that I have been aware of this behavior of the IDC DHCP server as long as I have been running it in failover mode. > I am certainly not prepared to develop proof of concept code or go the > full route of developing such a server myself, however, I belive firmly > that a failover implementation in dhcp could be designed as a > counterpoint to the current implementation that is reliable, simple, > scalable and requiring no special procedures once a 'break' occurs. And which implements failover protocol in the IETF draft? Steinar Haug, Nethelp consulting, sthaug at nethelp.no ------------------------------ Message: 5 Date: Sat, 20 Mar 2010 11:27:44 +0000 (GMT) From: Jess Kitchen Subject: Help with a 3561 debug To: nanog at nanog.org Message-ID: Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Hello, If anyone is single homed via Savvis AS3561 that could spare a minute to help with a couple of mtr/tcptraceroute/iperfs that would be great- trying to drill down a peculiar and intermittent issue that has been occurring since some time Thursday (packets indescriminately dropped on the floor but only on particular paths) Please mail offlist, thanks -- Jess Kitchen ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 26, Issue 106 ************************************** From graham at apolix.co.za Sun Mar 21 00:42:53 2010 From: graham at apolix.co.za (Graham Beneke) Date: Sun, 21 Mar 2010 07:42:53 +0200 Subject: Using private APNIC range in US In-Reply-To: <2511b2981003182104l1c671426odb0768337faf4dcf@mail.gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <4BA27F5F.1050607@gmail.com> <4BA28202.7040900@cox.net> <2511b2981003182104l1c671426odb0768337faf4dcf@mail.gmail.com> Message-ID: <4BA5B1DD.8080204@apolix.co.za> On 19/03/2010 06:04, Matt Shadbolt wrote: > I once had a customer who for some reason had all their printers on public > addresses they didn't own. Not advertising them outside, but internally > whenever a user browsed to a external site that happened to be one of the > addresses used, they would just receive a HP or Konica login page :) I have seen quite a number of organisations using /24s that they have pirated from various places. Worst culprits seem to be small access providers who change upstream providers and are too lazy to renumber their corporated network away from the IPs that have been reclaimed. They stick in a NAT and then ignore the problem for a few years. One particular company insisted that their pirate IP block be routable within the shiny new core network causing endless headaches making sure it doesn't leak into their BGP. Another ISP is even using oops-I-thought-that-was-RFC1918-addresses in the vicinity of 172.50.x.x and pirate space from 6.7.8.x for their point to point links. > > They didn't mind though. No idea if they've changed it since. > > > On Fri, Mar 19, 2010 at 6:41 AM, Larry Sheldon wrote: > >> On 3/18/2010 14:30, William Allen Simpson wrote: >>> On 3/18/10 2:35 PM, Jared Mauch wrote: >>>> Does anyone know if the University of Michigan or Cisco are going be >> updating their systems and documentation to no longer use 1.2.3.4 ? >>>> >>>> http://www.google.com/search?q=1.2.3.4+site%3Acisco.com >>>> >>>> I know that the University of Michigan utilize 1.2.3.4 for their captive >> portal login/logout pages as recently as monday when I was on the medical >> campus. >>>> >>> Dunno about cisco. >>> >>> med.umich.edu seems to run their own stuff, separately from umich.edu, >> and >>> quite badly. I've complained about their setup repeatedly over the past >>> several years. No traction. >> >> Is it something about Medical Schools? >> >> When we were first putting together the campus network, Surgery was >> running a Token Ring (I thought "Vampire Tap" was a fitting item for >> their inventory) running in Class D space as I recall. >> >>> Should we try again, jointly? ;-) >> >> Towards the end, there were people who insisted I must rout their net to >> the Internets. >> >> I declined. >> -- >> Democracy: Three wolves and a sheep voting on the dinner menu. >> (A republic, using parliamentary law, protects the minority.) >> >> Requiescas in pace o email >> Ex turpi causa non oritur actio >> Eppure si rinfresca >> >> ICBM Targeting Information: http://tinyurl.com/4sqczs >> http://tinyurl.com/7tp8ml >> >> >> >> -- Graham Beneke From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Mar 21 03:12:31 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 21 Mar 2010 18:42:31 +1030 Subject: Using private APNIC range in US In-Reply-To: <4BA25974.9060504@utah.edu> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <4c6b8c911003180922j426f6e94g37eb772210a249f8@mail.gmail.com> <4BA25974.9060504@utah.edu> Message-ID: <20100321184231.09faa1af@opy.nosense.org> On Thu, 18 Mar 2010 10:48:52 -0600 Tom Ammon wrote: > RFC1918 is a good place to start ;) > Most of the issues in "Deprecating Site Local Addresses" http://www.rfc-editor.org/rfc/rfc3879.txt identified in IPv6 Site-Local addressing also apply to duplicated/overlapping IPv4 addressing. > On 3/18/2010 10:22 AM, Jaren Angerbauer wrote: > > Thanks all for the on / off list responses on this. I acknowledge I'm > > playing in territory I'm not familiar with, and was a bad idea to jump > > to the conclusion that this range was private. I made that assumption > > originally because the entire /8 was owned by APNIC, and just figured > > since the registrar owned them, it must have been a private range. :S > > > > It sounds like this range was just recently assigned -- is there any > > document (RFC?) or source I could look through to learn more about > > this, and/or provide evidence to my client? > > > > Thanks, > > > > Jaren > > > > > > -- > -------------------------------------------------------------------- > Tom Ammon > Network Engineer > Office: 801.587.0976 > Mobile: 801.674.9273 > > Center for High Performance Computing > University of Utah > http://www.chpc.utah.edu > > From joelja at bogus.com Sun Mar 21 09:10:04 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 21 Mar 2010 07:10:04 -0700 Subject: Using private APNIC range in US In-Reply-To: <20100321184231.09faa1af@opy.nosense.org> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> <4c6b8c911003180922j426f6e94g37eb772210a249f8@mail.gmail.com> <4BA25974.9060504@utah.edu> <20100321184231.09faa1af@opy.nosense.org> Message-ID: <4BA628BC.8090000@bogus.com> >>> It sounds like this range was just recently assigned -- is there any >>> document (RFC?) or source I could look through to learn more about >>> this, and/or provide evidence to my client http://www.iana.org/assignments/ipv4-address-space/ >>> Thanks, >>> >>> Jaren >>> >>> >> >> -- >> -------------------------------------------------------------------- >> Tom Ammon >> Network Engineer >> Office: 801.587.0976 >> Mobile: 801.674.9273 >> >> Center for High Performance Computing >> University of Utah >> http://www.chpc.utah.edu >> >> > From David_Hankins at isc.org Sun Mar 21 12:33:39 2010 From: David_Hankins at isc.org (David W. Hankins) Date: Sun, 21 Mar 2010 10:33:39 -0700 Subject: ISC DHCP server failover In-Reply-To: <4BA4125C.2090309@tiedyenetworks.com> References: <20100317142206.GB4773@dan.olp.net> <20100319232613.GD5775@isc.org> <4BA4125C.2090309@tiedyenetworks.com> Message-ID: <20100321173339.GA3159@isc.org> On Fri, Mar 19, 2010 at 05:10:04PM -0700, Mike wrote: > With all due respect and acknowledgment of the tremendous contributions of > ISC and you yourself Mr. Hankins, I have to comment that failover in > isc-dhcp is broken by design because it requires the amount of handholding > and operator thinking in the event of a failure that you explained to us at > length is required. Failure needs to be handled automatically and without > any intervention at all, otherwise you might as well not have it and I > think most network operators would agree. First let me say that I wasn't involved in failover's design, I'm only a sort of "maintainer," so the criticism is not offending me in the slightest. :) Failover definitely busied itself with the cross-country, geographically diverse DHCP server situation, hoping that by solving that they are also giving "HA", heartbeat-cable types of folks a tool they can also use, although it isn't explicitly designed for that purpose alone. That does tend to leave this community a little under-served and unhappy, which was my motivation for failover features in 4.2 to try and support their needs better (auto partner- down, greater endurance in comms-interrupted). What you describe for an alternative (although I will criticize it slightly in suggesting you are under-estimating DHCP's needs; the question of message delivery is really not relevant) are the building blocks for something I would refer to as "DHCP Server Clustering". I fully endorse it. That is a set of separate programs that work together to appear from the outside to be a single DHCP server (as those terms are defined in RFC), and the ways in which you can build-in redundancy and self- healing (self-restarting components, component failures only affect a subset of services, redundant processes that cover gaps in coverage, etc). In short, you're describing one of our key motivations for migrating ISC DHCP to the BIND 10 framework. That gives us a complete set of tools. Within the same rack, you will ultimately be able to implement a "single server" from all outside observance that is actually implemented in a redundant way across (N+1) systems* or CPU's within one system, while still maintaining a failover ability to tie two such geographically diverse clusters together (not to mention co-habitation with BIND 10's DNS services in the same configuration and monitoring plane) that don't actually have to be clusters if you don't want all that baggage either. So everyone's happy. Unfortunately at the moment we are still collecting sponsors for the DHCP-in-BIND-10 project, and no shovels have been turned. But I'm confident the work will proceed (and if anyone wishes to help as a sponsor or a participant, please contact us! We are in Anaheim this week, and there is also a link in my signature you can click). In the meantime, failover is a tool we have whereas DHCP clustering software is so far only a tool we want to create. * Some objects in the future-mirror may be further away than they appear. -- David W. Hankins BIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From gfortaine at live.com Sun Mar 21 14:14:18 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Sun, 21 Mar 2010 20:14:18 +0100 Subject: NSP-SEC In-Reply-To: <4BA52C38.2060403@linuxbox.org> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> <4BA52C38.2060403@linuxbox.org> Message-ID: On 03/20/2010 09:12 PM, Gadi Evron wrote: > > 2. Show you are responsive and responsible in handling issues in your > own back yard. > http://docs.google.com/viewer?a=v&q=cache:ENEl1xrgXNwJ:https://ow.feide.no/_media/geantcampus:s5.2-flows_at_mu.pdf%3Fid%3Dgeantcampus%253Anetw_monitoring_oct_2009%26cache%3Dcache+s5.2-flows_at_mu&hl=en&pid=bl&srcid=ADGEEShCR2bC8bfpSow5e5Ebqi-x0szdV_rZN15cDn6t_nZpD6Vd-K-FRZ-sMpZy4k-7XJKWQdcsXt3hKYpc1M5RtNB_LMPahnYx9Zw8gSxEJ2WTjBQ5rn-KISGF8vE7qCOkyvHsPySt&sig=AHIEtbTjuYrs5deXJTat5R5_8Xb1oDQFNg http://isotf.org/pipermail/cii/2010-February/000137.html Best Regards, Guillaume FORTAINE From trelane at trelane.net Sun Mar 21 14:31:34 2010 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 21 Mar 2010 15:31:34 -0400 Subject: NSP-SEC In-Reply-To: References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> <4BA52C38.2060403@linuxbox.org> Message-ID: <4BA67416.3050507@trelane.net> Guillaume FORTAINE wrote: > On 03/20/2010 09:12 PM, Gadi Evron wrote: >> >> 2. Show you are responsive and responsible in handling issues in your >> own back yard. >> > > http://docs.google.com/viewer?a=v&q=cache:ENEl1xrgXNwJ:https://ow.feide.no/_media/geantcampus:s5.2-flows_at_mu.pdf%3Fid%3Dgeantcampus%253Anetw_monitoring_oct_2009%26cache%3Dcache+s5.2-flows_at_mu&hl=en&pid=bl&srcid=ADGEEShCR2bC8bfpSow5e5Ebqi-x0szdV_rZN15cDn6t_nZpD6Vd-K-FRZ-sMpZy4k-7XJKWQdcsXt3hKYpc1M5RtNB_LMPahnYx9Zw8gSxEJ2WTjBQ5rn-KISGF8vE7qCOkyvHsPySt&sig=AHIEtbTjuYrs5deXJTat5R5_8Xb1oDQFNg > > > > http://isotf.org/pipermail/cii/2010-February/000137.html > > > Best Regards, > > Guillaume FORTAINE > > Are you done yet? Please go away. You're here posting from a webmail account at Microsoft, dictating some sort of network policy? Andrew From jwbensley at gmail.com Sun Mar 21 16:37:09 2010 From: jwbensley at gmail.com (James Bensley) Date: Sun, 21 Mar 2010 21:37:09 +0000 Subject: NSP-SEC In-Reply-To: <520.1269008366@localhost> References: <520.1269008366@localhost> Message-ID: <3c857e1c1003211437p7632053xb7cd8f6825bd3e@mail.gmail.com> On 19 March 2010 14:19, wrote: You *do* realize that > there's an estimated 140,000,000 bots on the net, right As many as that? Thats 1 in 12 according to http://www.internetworldstats.com/stats.htm. Lets be honest, I don't follow the world wide bot crisis because as your figure suggests, its just to much to keep your head on top of it, but is it really than many? I'm rather shocked its that high tbh! -- Regards, James ;) From sronan at fattoc.com Sun Mar 21 19:10:47 2010 From: sronan at fattoc.com (Shane Ronan) Date: Sun, 21 Mar 2010 19:10:47 -0500 Subject: Shutting Down a Network and Selling off Assets Message-ID: <9AC11C32-36C8-4038-9685-1D81F9DC5DFC@fattoc.com> Hello everyone, This might be slightly off topic, but I am shutting down a large network, and selling off the assets. Information is @ www.ronan-online/forsale.html I will be adding items to the list as they come offline, as well as the location of each asset. Email me with any questions or offers. Shane Ronan From sronan at fattoc.com Sun Mar 21 19:35:09 2010 From: sronan at fattoc.com (Shane Ronan) Date: Sun, 21 Mar 2010 19:35:09 -0500 Subject: Shutting Down a Network and Selling off Assets In-Reply-To: <9AC11C32-36C8-4038-9685-1D81F9DC5DFC@fattoc.com> References: <9AC11C32-36C8-4038-9685-1D81F9DC5DFC@fattoc.com> Message-ID: www.ronan-online.com/forsale.html On Mar 21, 2010, at 7:10 PM, Shane Ronan wrote: > Hello everyone, > > This might be slightly off topic, but I am shutting down a large > network, and selling off the assets. > > Information is @ www.ronan-online/forsale.html > > I will be adding items to the list as they come offline, as well as > the location of each asset. > > Email me with any questions or offers. > > Shane Ronan > From rsk at gsp.org Sun Mar 21 19:43:46 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 21 Mar 2010 20:43:46 -0400 Subject: NSP-SEC In-Reply-To: <3c857e1c1003211437p7632053xb7cd8f6825bd3e@mail.gmail.com> References: <520.1269008366@localhost> <3c857e1c1003211437p7632053xb7cd8f6825bd3e@mail.gmail.com> Message-ID: <20100322004346.GA19036@gsp.org> On Sun, Mar 21, 2010 at 09:37:09PM +0000, James Bensley wrote: > On 19 March 2010 14:19, wrote: > You *do* realize that > > there's an estimated 140,000,000 bots on the net, right > > As many as that? Thats 1 in 12 according to > http://www.internetworldstats.com/stats.htm. I think that estimate's a bit on the low side, but it's certainly very plausible, based on growth rates that have been observed over the past seven years. I think any estimate under 100M should be laughed out of the room, and that 200M is not unreasonable, although it's arguably edging toward the upper error bars. What's disconcerting about this -- well, actually there are a number of disconcerting things about this, but let me pick one -- is that our adversaries have convincingly demonstrated that they understand concepts like reserves, concealment, and misdirection. It's therefore entirely sensible to wonder how many system which are not presently displaying any externally-observable symptoms are in fact bots but are simply not being used as such -- for now. There is, by the way, no relief from this due to events like the recent bust of the Mariposa botnet (13M systems); all that means is that there are now 13M pre-compromised systems waiting for the first person clever enough to conscript them into *their* botnet. ---Rsk From ALanstein at FireEye.com Sun Mar 21 20:52:53 2010 From: ALanstein at FireEye.com (Alex Lanstein) Date: Sun, 21 Mar 2010 18:52:53 -0700 Subject: NSP-SEC In-Reply-To: <20100322004346.GA19036@gsp.org> References: <520.1269008366@localhost> <3c857e1c1003211437p7632053xb7cd8f6825bd3e@mail.gmail.com>, <20100322004346.GA19036@gsp.org> Message-ID: <60B0F2124D07B942988329B5B7CA393D023F2C88E8@mail2.FireEye.com> >>>________________________________________ >>>From: Rich Kulawiec [rsk at gsp.org] >>>Sent: Sunday, March 21, 2010 8:43 PM >>>To: nanog at nanog.org >>>Subject: Re: NSP-SEC >>> >>>There is, by the way, no relief from this due to events like the >>>recent bust of the Mariposa botnet (13M systems); The public numbers advertised were 13M _IPs_ connecting to a sinkhole over more than a month's time. When I've had visibility into other large botnets (srizbi, rustock, mega-d), I was consistently seeing a 10 to 1 IPs-to-unique-bots count over a time period of a week. Happy to make the raw pcap data available to anyone who is curious. The UCSB guys showed similar results in their excellent Torpig paper. http://www.cs.ucsb.edu/~seclab/projects/torpig/torpig.pdf My unscientific finger-in-the-wind would put it at well under 1M when you are talking a month and a half of monitoring IP connections. Regards, Alex Lanstein From Valdis.Kletnieks at vt.edu Sun Mar 21 21:03:11 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 21 Mar 2010 22:03:11 -0400 Subject: NSP-SEC In-Reply-To: Your message of "Sun, 21 Mar 2010 21:37:09 -0000." <3c857e1c1003211437p7632053xb7cd8f6825bd3e@mail.gmail.com> References: <520.1269008366@localhost> <3c857e1c1003211437p7632053xb7cd8f6825bd3e@mail.gmail.com> Message-ID: <28851.1269223391@localhost> On Sun, 21 Mar 2010 21:37:09 -0000, James Bensley said: > On 19 March 2010 14:19, wrote: > You *do* realize that > > there's an estimated 140,000,000 bots on the net, right > > As many as that? Thats 1 in 12 according to That was Vint Cerf's number as of 2007 or so. He dropped that estimate at a major keynote address, and for the next 2 weeks, every security expert out there was going "OK, who's going to tell Vint he's full of it?" - but nobody could find non-laughable countering estimates. Want a more depressing number? http://blog.trendmicro.com/1h-2009-malware-threat-grows-ever-larger/ "TrendLabs has seen this continued growth of malware. The effects on users is clear: in the first six months of 2008, the Trend Micro World Virus Tracking Center (WTC) recorded that 253.4 million systems were infected with malware. The comparable volume for 2009 is almost double at 491.2 million." The mind boggles. I would appreciate it if somebody would find the massive statistical error that inflated those numbers by a factor of 5 or 10. (Note that number probably includes adware and spyware as well as full-blown zombies, but any adware or spyware that can phone home can at least in principle upgrade itself to a bot if desired..) Operational impact: For close to half of your customers, the billing address no longer matches the effective owner's address. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From patrick at ianai.net Sun Mar 21 22:58:27 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 21 Mar 2010 23:58:27 -0400 Subject: NSP-SEC In-Reply-To: <60B0F2124D07B942988329B5B7CA393D023F2C88E8@mail2.FireEye.com> References: <520.1269008366@localhost> <3c857e1c1003211437p7632053xb7cd8f6825bd3e@mail.gmail.com>, <20100322004346.GA19036@gsp.org> <60B0F2124D07B942988329B5B7CA393D023F2C88E8@mail2.FireEye.com> Message-ID: <880233D8-1313-4F96-8948-EF459830A351@ianai.net> On Mar 21, 2010, at 9:52 PM, Alex Lanstein wrote: >>>> There is, by the way, no relief from this due to events like the >>>> recent bust of the Mariposa botnet (13M systems); > > The public numbers advertised were 13M _IPs_ connecting to a sinkhole over more than a month's time. When I've had visibility into other large botnets (srizbi, rustock, mega-d), I was consistently seeing a 10 to 1 IPs-to-unique-bots count over a time period of a week. Happy to make the raw pcap data available to anyone who is curious. The UCSB guys showed similar results in their excellent Torpig paper. http://www.cs.ucsb.edu/~seclab/projects/torpig/torpig.pdf > > My unscientific finger-in-the-wind would put it at well under 1M when you are talking a month and a half of monitoring IP connections. First, Alex, don't you know all security people are 100% secretive? :) Back on topic, there is good data out there showing far, far more than 1 million hosts on the Internet infected. Hrmm, my first two Google searches did not turn anything up. So maybe those security guys are being secretive! -- TTFN, patrick From ljakab at ac.upc.edu Mon Mar 22 05:24:04 2010 From: ljakab at ac.upc.edu (Lorand Jakab) Date: Mon, 22 Mar 2010 11:24:04 +0100 Subject: NSP-SEC In-Reply-To: <880233D8-1313-4F96-8948-EF459830A351@ianai.net> References: <520.1269008366@localhost> <3c857e1c1003211437p7632053xb7cd8f6825bd3e@mail.gmail.com>, <20100322004346.GA19036@gsp.org> <60B0F2124D07B942988329B5B7CA393D023F2C88E8@mail2.FireEye.com> <880233D8-1313-4F96-8948-EF459830A351@ianai.net> Message-ID: <4BA74544.3020607@ac.upc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/22/10 04:58, Patrick W. Gilmore wrote: > On Mar 21, 2010, at 9:52 PM, Alex Lanstein wrote: > >>>>> There is, by the way, no relief from this due to events >>>>> like the recent bust of the Mariposa botnet (13M systems); >> >> The public numbers advertised were 13M _IPs_ connecting to a >> sinkhole over more than a month's time. When I've had visibility >> into other large botnets (srizbi, rustock, mega-d), I was >> consistently seeing a 10 to 1 IPs-to-unique-bots count over a >> time period of a week. Happy to make the raw pcap data available >> to anyone who is curious. The UCSB guys showed similar results >> in their excellent Torpig paper. >> http://www.cs.ucsb.edu/~seclab/projects/torpig/torpig.pdf >> >> My unscientific finger-in-the-wind would put it at well under 1M >> when you are talking a month and a half of monitoring IP >> connections. > > First, Alex, don't you know all security people are 100% secretive? > :) > > Back on topic, there is good data out there showing far, far more > than 1 million hosts on the Internet infected. Hrmm, my first two > Google searches did not turn anything up. So maybe those security > guys are being secretive! > There are usually two important numbers to consider when discussing botnet sizes: botnet footprint and the number online bots. The former is the one typically reported by media and antivirus companies, because it's much larger (and more impressive). It represents the total number of host that were infected during the whole lifetime of the botnet. However, over time many machines are cleaned (i.e., Microsoft's MSRT on patch Tuesdays), new machines still get infected, but the number gets updated always only with the new infections. So it gets high over time, but doesn't represent the actual firepower of the botnet, which is the second figure, the number of online bots. This is the number of host that are available to the botmaster at a given time, and is much smaller. To give an example, a measurement done by Thorsten Holz et al. on the infamous Storm botnet in 2008 showed that the number of online hosts was actually just around 30,000 at the time of the measurements, while the highly publicized botnet size (representing the footprint) was over 1M. I'm not up to date on the topic, but I assume the relationship between the two figures is similar these days. So I think Rich and Valdis were talking about footprint and Alex about the online bots, and the two order of magnitude difference actually fits. - -Lorand Jakab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkunRUMACgkQlUwN75BxDXQWHgCgsx1KRnomAL9Y8iwl8kff5skC vIMAmwaM8d68DqmXzlYovRS08AO/ePwV =LoNE -----END PGP SIGNATURE----- From jwbensley at gmail.com Mon Mar 22 05:44:59 2010 From: jwbensley at gmail.com (James Bensley) Date: Mon, 22 Mar 2010 10:44:59 +0000 Subject: NSP-SEC In-Reply-To: References: <520.1269008366@localhost> <3c857e1c1003211437p7632053xb7cd8f6825bd3e@mail.gmail.com> Message-ID: <3c857e1c1003220344u4a27f5aes93521dcadd38dbd3@mail.gmail.com> On 21 March 2010 23:10, wrote: > Hey James,m > > Well, I'm sure that the 140,000,000 is a FUD figure extrapolated by an AV vendor rather than an actual audit (:-), but you make a fair point. > > That said, I did start wondering how an "Internet User" is defined in the stats you pointed to. Assuming that Internet User means an Internet connection (?), do we assume that there is only one bot per computer (bearing in mind that if you're susceptible to one, there's a good chance you have succumbed to more than one); or that there's only one computer per user (progressively less common in a domestic setting, and see the previous point again also); and we are probably ignoring the possibility of bots in commercial environments (bots couldn' t possibly penetrate the workplace, right?). All of the above I'd wager could skew the statistics to something more reasonable. > > In conclusion: blah blah blah statistics. Can't win :) > > Have a good weekend :) > > j. > Yes and what about virtual machines, servers, data centers? There are going to be (obviously) far more machines online than there are people so I guess the figure can be greatly skewed but I can see from other peoples posts that it could also be accurate. Scary! -- Regards, James ;) From Valdis.Kletnieks at vt.edu Mon Mar 22 08:08:35 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Mar 2010 09:08:35 -0400 Subject: NSP-SEC In-Reply-To: Your message of "Sat, 20 Mar 2010 21:06:25 BST." References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> Message-ID: <18013.1269263315@localhost> On Sat, 20 Mar 2010 21:06:25 BST, Guillaume FORTAINE said: > you make an informed security decision. Cisco should examine its > patching schedule in light of the September 24th announcement; every six > months is not acceptable. but then,,, > 3) Testing, Testing, Testing > > In this case we have a great example of why every network device needs > to be realistically tested under a variety of scenarios, both security > and performance driven. Cognitive dissonance, anybody? :) To paraphrase the old saying - frequent, well-tested, cheap - pick any two. Sure - Cisco *could* release well-tested patch kits once a month, but it's going to cost you. Remember that Microsoft can amortize the cost of its QA labs across several hundred million customers, so each one only has to pay a few dollars. Cisco has to split that cost across a few thousand customers - each customer's share of the bill is going to be higher. You want it once a month rather than once very six months, and just as well tested? It's going to cost *at least* six times as much. Probably more. So - just how much bigger a check you want to write to Cisco for support (whether it's a yearly contract, or bundled into the unit's purchase price)? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From randy at psg.com Mon Mar 22 09:22:05 2010 From: randy at psg.com (Randy Bush) Date: Mon, 22 Mar 2010 07:22:05 -0700 Subject: Shutting Down a Network and Selling off Assets In-Reply-To: <9AC11C32-36C8-4038-9685-1D81F9DC5DFC@fattoc.com> References: <9AC11C32-36C8-4038-9685-1D81F9DC5DFC@fattoc.com> Message-ID: and this is not spam? From braaen at zcorum.com Mon Mar 22 09:33:04 2010 From: braaen at zcorum.com (Brian Raaen) Date: Mon, 22 Mar 2010 10:33:04 -0400 Subject: Shutting Down a Network and Selling off Assets In-Reply-To: References: <9AC11C32-36C8-4038-9685-1D81F9DC5DFC@fattoc.com> Message-ID: <201003221033.05576.braaen@zcorum.com> Remember, never blame malice for what can be explained by stupidity. I don't know the guy's intentions, but I'm pretty sure this is against the list policy. I would agree that the more appropriate avenue for him is probably ebay. -- ---------------------- Brian Raaen Network Engineer braaen at zcorum.com Tel 678-507-5000x5574 On Monday 22 March 2010, Randy Bush wrote: > and this is not spam? > > From Carl.Andrews at crackerbarrel.com Mon Mar 22 12:24:05 2010 From: Carl.Andrews at crackerbarrel.com (Andrews Carl 448) Date: Mon, 22 Mar 2010 12:24:05 -0500 Subject: OpenLDAP and Active Directory Message-ID: <73BF1D6676C4E04E9675A08BA0C9825A07CB8466@exchsrvr01.CBOCS.com> Please forgive me if this is an inappropriate place to make this requests. I need to setup an OpenLDAP server for proxy authentication to Microsoft Active Directory. From what I have been able to determine this is completely possible but I am missing something. I have the O'Reilly LDAP book but it was written several years prior to the current OpenLDAP version and there has been a major rewrite of the software. Can anyone help me or point me to somewhere I can get assistance? I have tried one consulting firm and that was a stellar failure. I've tried many different searches but a search for 'active directory, openldap, authentication, proxy, pass-through' either gives information for Squid or all go back to the same OpenLDAP Administrators guide from which I am missing something. Thanks! Carl From charles at knownelement.com Mon Mar 22 12:31:31 2010 From: charles at knownelement.com (Charles N Wyble) Date: Mon, 22 Mar 2010 10:31:31 -0700 Subject: OpenLDAP and Active Directory In-Reply-To: <73BF1D6676C4E04E9675A08BA0C9825A07CB8466@exchsrvr01.CBOCS.com> References: <73BF1D6676C4E04E9675A08BA0C9825A07CB8466@exchsrvr01.CBOCS.com> Message-ID: <4BA7A973.8080706@knownelement.com> On 03/22/2010 10:24 AM, Andrews Carl 448 wrote: > > > I need to setup an OpenLDAP server for proxy authentication to Microsoft > Active Directory. From what I have been able to determine this is > completely possible but I am missing something. I have the O'Reilly LDAP > book but it was written several years prior to the current OpenLDAP > version and there has been a major rewrite of the software. > Check out the Fedora Directory Server. http://directory.fedoraproject.org/ From meenoo at gmail.com Mon Mar 22 12:33:27 2010 From: meenoo at gmail.com (Meenoo Shivdasani) Date: Mon, 22 Mar 2010 13:33:27 -0400 Subject: OpenLDAP and Active Directory In-Reply-To: <73BF1D6676C4E04E9675A08BA0C9825A07CB8466@exchsrvr01.CBOCS.com> References: <73BF1D6676C4E04E9675A08BA0C9825A07CB8466@exchsrvr01.CBOCS.com> Message-ID: > I need to setup an OpenLDAP server for proxy authentication to Microsoft > Can anyone help me or point me to somewhere I can get assistance? I have > tried one consulting firm and that was a stellar failure. Try the openldap-technical mailing list. It also has a searchable archive. http://www.openldap.org/lists/openldap-technical/ M From dwhite at olp.net Mon Mar 22 12:41:27 2010 From: dwhite at olp.net (Dan White) Date: Mon, 22 Mar 2010 12:41:27 -0500 Subject: OpenLDAP and Active Directory In-Reply-To: <73BF1D6676C4E04E9675A08BA0C9825A07CB8466@exchsrvr01.CBOCS.com> References: <73BF1D6676C4E04E9675A08BA0C9825A07CB8466@exchsrvr01.CBOCS.com> Message-ID: <20100322174126.GO4968@dan.olp.net> On 22/03/10?12:24?-0500, Andrews Carl 448 wrote: >Please forgive me if this is an inappropriate place to make this >requests. > > >I need to setup an OpenLDAP server for proxy authentication to Microsoft >Active Directory. From what I have been able to determine this is >completely possible but I am missing something. I have the O'Reilly LDAP >book but it was written several years prior to the current OpenLDAP >version and there has been a major rewrite of the software. Depending on details, you might find assistance with these two lists: http://www.openldap.org/lists/mm/listinfo/openldap-software http://lists.andrew.cmu.edu/mailman/listinfo/cyrus-sasl If you're wanting to authenticate based on username/password (as apposed to client Kerberos credentials), include 'saslauthd' in your search. >Can anyone help me or point me to somewhere I can get assistance? I have >tried one consulting firm and that was a stellar failure. > >I've tried many different searches but a search for 'active directory, >openldap, authentication, proxy, pass-through' either gives information >for Squid or all go back to the same OpenLDAP Administrators guide from >which I am missing something. -- Dan White From mark at viviotech.net Mon Mar 22 14:03:58 2010 From: mark at viviotech.net (Mark Keymer) Date: Mon, 22 Mar 2010 12:03:58 -0700 Subject: AOL Postmaster Message-ID: <4BA7BF1E.8000101@viviotech.net> Hi, If at all possible can a AOL Postmaster please get a hold of me. I have a client that co-lo's with use and we do the support for them and we need some help on getting mail to be delivering again to AOL. Thank You in advance. Sincerely, Mark Keymer From LarrySheldon at cox.net Mon Mar 22 14:23:53 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 22 Mar 2010 14:23:53 -0500 Subject: AOL Postmaster In-Reply-To: <4BA7BF1E.8000101@viviotech.net> References: <4BA7BF1E.8000101@viviotech.net> Message-ID: <4BA7C3C9.4060707@cox.net> On 3/22/2010 14:03, Mark Keymer wrote: > Hi, > > If at all possible can a AOL Postmaster please get a hold of me. I have > a client that co-lo's with use and we do the support for them and we > need some help on getting mail to be delivering again to AOL. Didn't I read that all of the AOL Postmasters had been....what is the word this week...made redundant? -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From schampeo at hesketh.com Mon Mar 22 15:42:24 2010 From: schampeo at hesketh.com (Steven Champeon) Date: Mon, 22 Mar 2010 16:42:24 -0400 Subject: Network Naming Conventions In-Reply-To: References: Message-ID: <20100322204224.GI25796@hesketh.com> Sorry for the delay; I've been traveling and neglecting my lists. on Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote: > With many changes going on this year in our network, I figured it's a > good time to revisit our naming conventions used in our networks. I study PTR naming conventions as part of my Enemieslist project; it turns out that genericity in naming is highly correlated to bot spam, so some folks find my patterns useful to block and/or score inbound mail for risk of being bot-originated. As such, I've written a few rants about /poor/ naming practices that you may find useful and/or amusing, as well as a few pointing out the rare /good/ naming practices. (See below) In a nutshell, it boils down to this: - note static/dynamic hosts in the name, in the furthest-right-hand token possible (dyn.example.net, not dyn-foo-1-2-3-4.ny.ny.example.net). - cute and funny are not useful to others trying to decide whether to block services originating from a host; clarity and forethought and transparency are. - use different conventions for different services, this helps us differentiate dialup from dsl from cable and other infrastructure; don't assume everyone will do a whois lookup to find out this block is all consumer dsl and this other one is fixed business class. - be consistent, for the love of all that is good and holy. I've got over a hundred patterns for vsnl.net.in *alone*. There are a couple of IDs that discuss naming, in the anti-abuse context: http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt Here's what I've had to say on the matter over the years: DHCP doesn't necessarily mean dynamic http://enemieslist.com/news/archives/2009/09/dhcp_doesnt_nec.html annoying-stupidity.volia.net http://enemieslist.com/news/archives/2009/08/annoyingstupidi.html A few thoughts on reverse DNS / PTR naming http://enemieslist.com/news/archives/2009/06/a_few_thoughts_1.html Basic principles of DNS and their discontents http://enemieslist.com/news/archives/2009/06/basic_principle.html http://enemieslist.com/news/archives/2009/06/basic_principle_1.html http://enemieslist.com/news/archives/2009/06/basic_principle_2.html Today's DNS Spotlight: Eircom http://enemieslist.com/news/archives/2009/06/todays_dns_spot.html A couple more: kudos, and mixed kudos/gripe http://enemieslist.com/news/archives/2009/06/a_couple_more_k.html Principles http://enemieslist.com/news/archives/2009/06/principles.html There's a few dozen more in the gripes archive: http://enemieslist.com/news/archives/gripes/ HTH, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/ From gfortaine at live.com Mon Mar 22 17:02:02 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Mon, 22 Mar 2010 23:02:02 +0100 Subject: NSP-SEC In-Reply-To: <18013.1269263315@localhost> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> <18013.1269263315@localhost> Message-ID: Dear Mister Kletnieks, Thank you for your reply. On 03/22/2010 02:08 PM, Valdis.Kletnieks at vt.edu wrote: > So - just how much bigger a check you want to write to Cisco for support > (whether it's a yearly contract, or bundled into the unit's purchase price)? > > This is a very pertinent question. My reply would be : How much money would you evaluate a security incident on your Cisco device ? Because, the fundamental questions are : a) How much value does your network bring to your business ? b) How much money are you ready to spend to ensure its security ? Conclusion : if you can't reply to these fundamental questions, hire a CISO and build a CSIRT. Best Regards, Guillaume FORTAINE From sob at academ.com Mon Mar 22 17:53:01 2010 From: sob at academ.com (Stan Barber) Date: Mon, 22 Mar 2010 17:53:01 -0500 Subject: IP4 Space In-Reply-To: <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> Message-ID: <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> In this case, I am talking about an IPv6<->IPv6 NAT analogue to the current IPv4<->IPv4 NAT that is widely used with residential Internet service delivery today. I believe that with IPv6 having much larger pool of addresses and each residential customer getting a large chunk of addresses will make IPv6<->IPv6 NAT unnecessary. I also believe that there will be IPv6 applications that require end-to-end communications that would be broken where NAT of that type used. Generally speaking, many users of the Internet today have not had the luxury to experience the end-to-end model because of the wide use of NAT. Given that these customers today don't routinely multihome today, I currently believe that behavior will continue. Multihoming is generally more complicated and expensive than just having a single connection with a default route and most residential customers don't have the time, expertise or financial support to do that. So, the rate of multihoming will stay about the same even though the number of potential sites that could multihome could increase dramatically as IPv6 takes hold. Now, there are clearly lots of specifics here that may change over time concerning what the minimum prefix length for IPv6 advertisements might be acceptable in the DFZ (some want that to be /32, other are ok with something longer). I don't know how that will change over time. I also think that that peering will continue to increase and that the prefix lengths that peers will exchange with each other are and will continue to be less constrained by the conventions of the DFZ since the whole point of peering is to be mutually beneficial to those two peers and their customers. But, that being said, I don't think residential customers will routinely do native IPv6 peering either. I think IP6-in-IPv4 tunneling is and will continue to be popular and that already makes for some interesting IPv6 routing concerns. Hope that clarifies my comment for you. Obviously, they are my opinions, not facts. The future will determine if I was seeing clearly or was mistaken in how these things might unfold. However, I think a discourse about these possibilities is helpful in driving consensus and that's one of the valuable things about mailing lists like this. On Mar 18, 2010, at 8:20 PM, Christopher Morrow wrote: > On Thu, Mar 18, 2010 at 7:36 PM, Stan Barber wrote: >> Ok. Let's get back to some basics to be sure we are talking about the same things. >> >> First, do you believe that a residential customer of an ISP will get an IPv6 /56 assigned for use in their home? Do >> you believe that residential customer will often choose to multihome using that prefix? Do you believe that on an >> Internet that has its primary layer 3 protocol is IPv6 that a residential customer will still desire to do NAT for reaching > > how are nat and ipv6 and multihoming related here? (also 'that has a > primary layer 3 protocol as ipv6' ... that's a LONG ways off) > > -chris > >> IPv6 destinations? >> >> I am looking forward to your response. >> >> >> >> >> On Mar 18, 2010, at 2:25 PM, William Herrin wrote: >> >>>> On Mar 5, 2010, at 7:24 AM, William Herrin wrote: >>>>> Joel made a remarkable assertion >>>>> that non-aggregable assignments to end users, the ones still needed >>>>> for multihoming, would go down under IPv6. I wondered about his >>>>> reasoning. Stan then offered the surprising clarification that a >>>>> reduction in the use of NAT would naturally result in a reduction of >>>>> multihoming. >>> >>> On Thu, Mar 18, 2010 at 11:07 AM, Stan Barber wrote: >>>> I was not trying to say there would be a reduction in multihoming. I was >>>> trying to say that the rate of increase in non-NATed single-homing >>>> would increase faster than multihoming. I guess I was not very clear. >>> >>> >>> Hi Stan, >>> >>> Your logic still escapes me. Network-wise there's not a lot of >>> difference between a single-homed IPv4 /32 and a single-homed IPv6 >>> /56. Host-wise there may be a difference but why would you expect that >>> to impact networks? >>> >>> Regards, >>> Bill Herrin >>> >>> >>> >>> -- >>> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >>> 3005 Crane Dr. ...................... Web: >>> Falls Church, VA 22042-3004 >> >> >> From randy at psg.com Mon Mar 22 18:43:17 2010 From: randy at psg.com (Randy Bush) Date: Mon, 22 Mar 2010 16:43:17 -0700 Subject: NSP-SEC In-Reply-To: References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> <18013.1269263315@localhost> Message-ID: From morrowc.lists at gmail.com Mon Mar 22 19:42:31 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 22 Mar 2010 17:42:31 -0700 Subject: IP4 Space In-Reply-To: <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> Message-ID: <75cb24521003221742j3b375debg3c40c29f1e0b770e@mail.gmail.com> On Mon, Mar 22, 2010 at 3:53 PM, Stan Barber wrote: > In this case, I am talking about an IPv6<->IPv6 NAT analogue to the current IPv4<->IPv4 > NAT that is widely used with residential Internet service delivery today. I don't necessarily see 6-6 nat being used as 4-4 is today, but I do think you'll see 6-6 nat in places. the current ietf draft for 'simple cpe security' (draft-ietf-v6ops-cpe-simple-security-09.txt) is potentially calling for some measures like nat, not nat today but... > I believe that with IPv6 having much larger pool of addresses and each residential > customer getting a large chunk of addresses will make ?IPv6<->IPv6 NAT unnecessary. I > also believe that there will be IPv6 applications that require end-to-end communications > that would be broken where NAT of that type used. Generally speaking, many users of I think you'll see apps like this die... quickly, but that's just my opinion. > the Internet today have not had the luxury to experience the end-to-end model because of > the wide use of NAT. > > Given that these customers today don't routinely multihome ?today, I currently believe > that behavior will continue. Multihoming is generally more complicated and expensive That's not obvious. if a low-cost (low pain, low price) means to multihome became available I'm sure it'd change... things like shim-6/mip-6 could do this. > than just having a single connection with a default route and most residential customers > don't have the time, expertise or financial support to do that. So, the rate of multihoming > will stay about the same even though the number of potential sites that could multihome > could increase dramatically as IPv6 takes hold. > > Now, there are clearly lots of specifics here that may change over time concerning what > the minimum prefix length for IPv6 advertisements might be acceptable in the DFZ (some > want that to be /32, other are ok with something longer). I don't know how that will change > over time. I also think that that peering will continue to increase and that the prefix > lengths that peers will exchange with each other are and will continue to be less > constrained by the conventions of the DFZ since the whole point of peering is to be > mutually beneficial to those two peers and their customers. But, that being said, I don't > think residential customers will routinely do native IPv6 peering either. I think IP6-in-IPv4 > tunneling is and will continue to be popular and that already makes for some interesting > IPv6 routing concerns. I firmly hope that ipv6-in-ipv4 dies... tunnel mtu problems are horrific to debug. (we'll see though!) -chris > Hope that clarifies my comment for you. Obviously, they are my opinions, not facts. The > future will determine if I was seeing clearly or was mistaken in how these things might > unfold. However, I think a discourse about these possibilities is helpful in driving > consensus and that's one of the valuable things about mailing lists like this. > > > On Mar 18, 2010, at 8:20 PM, Christopher Morrow wrote: > >> On Thu, Mar 18, 2010 at 7:36 PM, Stan Barber wrote: >>> Ok. Let's get back to some basics to be sure we are talking about the same things. >>> >>> ?First, do you believe that a residential customer of an ISP will get an IPv6 /56 assigned for use in their home? Do >>> you believe that residential customer will often choose to multihome using that prefix? Do you believe that on an >>> Internet that has its primary layer 3 protocol is IPv6 that a residential customer will still desire to do NAT for reaching >> >> how are nat and ipv6 and multihoming related here? (also 'that has a >> primary layer 3 protocol as ipv6' ... that's a LONG ways off) >> >> -chris >> >>> IPv6 destinations? >>> >>> I am looking forward to your response. >>> >>> >>> >>> >>> On Mar 18, 2010, at 2:25 PM, William Herrin wrote: >>> >>>>> On Mar 5, 2010, at 7:24 AM, William Herrin wrote: >>>>>> Joel made a remarkable assertion >>>>>> that non-aggregable assignments to end users, the ones still needed >>>>>> for multihoming, would go down under IPv6. I wondered about his >>>>>> reasoning. Stan then offered the surprising clarification that a >>>>>> reduction in the use of NAT would naturally result in a reduction of >>>>>> multihoming. >>>> >>>> On Thu, Mar 18, 2010 at 11:07 AM, Stan Barber wrote: >>>>> I was not trying to say there would be a reduction in multihoming. I was >>>>> trying to say that the rate of increase in non-NATed single-homing >>>>> would increase faster than multihoming. I guess I was not very clear. >>>> >>>> >>>> Hi Stan, >>>> >>>> Your logic still escapes me. Network-wise there's not a lot of >>>> difference between a single-homed ?IPv4 /32 and a single-homed IPv6 >>>> /56. Host-wise there may be a difference but why would you expect that >>>> to impact networks? >>>> >>>> Regards, >>>> Bill Herrin >>>> >>>> >>>> >>>> -- >>>> William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us >>>> 3005 Crane Dr. ...................... Web: >>>> Falls Church, VA 22042-3004 >>> >>> >>> > > From simon.perreault at viagenie.ca Mon Mar 22 19:51:14 2010 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Mon, 22 Mar 2010 17:51:14 -0700 Subject: IP4 Space In-Reply-To: <75cb24521003221742j3b375debg3c40c29f1e0b770e@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <75cb24521003221742j3b375debg3c40c29f1e0b770e@mail.gmail.com> Message-ID: <4BA81082.5010109@viagenie.ca> On 2010-03-22 17:42, Christopher Morrow wrote: > the current ietf draft for 'simple > cpe security' (draft-ietf-v6ops-cpe-simple-security-09.txt) is > potentially calling for some measures like nat, not nat today but... This is being reversed as we speak. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From morrowc.lists at gmail.com Mon Mar 22 20:18:17 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 22 Mar 2010 18:18:17 -0700 Subject: IP4 Space In-Reply-To: <4BA81082.5010109@viagenie.ca> References: <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <75cb24521003221742j3b375debg3c40c29f1e0b770e@mail.gmail.com> <4BA81082.5010109@viagenie.ca> Message-ID: <75cb24521003221818n5ef0d718gd4e17fd5a309907a@mail.gmail.com> On Mon, Mar 22, 2010 at 5:51 PM, Simon Perreault wrote: > On 2010-03-22 17:42, Christopher Morrow wrote: >> >> the current ietf draft for 'simple >> cpe security' (draft-ietf-v6ops-cpe-simple-security-09.txt) is >> potentially calling for some measures like nat, not nat today but... > > This is being reversed as we speak. yup, the 'simple' part of that proposal didn't stay 'simple'.. it's looking to get more simple (simple again?) but, my point was there are efforts to provide a not-wide-open-network for v6 deployments at the residential-cpe end. I think the goal of the author(s) intend to provide as much freedom as possible, but wanted a base level of security for the end users, so we dont re-learn 'lookie i have a dsl! Doh! i got pwned :(' again. -Chris From trelane at trelane.net Mon Mar 22 21:46:04 2010 From: trelane at trelane.net (Andrew D Kirch) Date: Mon, 22 Mar 2010 22:46:04 -0400 Subject: NSP-SEC In-Reply-To: References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> <18013.1269263315@localhost> Message-ID: <4BA82B6C.90708@trelane.net> Guillaume FORTAINE wrote: > > This is a very pertinent question. My reply would be : > > How much money would you evaluate a security incident on your Cisco > device ? > > Because, the fundamental questions are : > > a) How much value does your network bring to your business ? > > b) How much money are you ready to spend to ensure its security ? > > Conclusion : if you can't reply to these fundamental questions, hire a > CISO and build a CSIRT. > > Best Regards, > > Guillaume FORTAINE Folks, this is why you shouldn't let your kids do crystal meth, just in case you were wondering. Andrew From owen at delong.com Mon Mar 22 22:09:54 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 20:09:54 -0700 Subject: IP4 Space In-Reply-To: <75cb24521003221742j3b375debg3c40c29f1e0b770e@mail.gmail.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <75cb24521003221742j3b375debg3c40c29f1e0b770e@mail.gmail.com> Message-ID: <9141CE41-B874-4FE2-9C42-82A02CA2DB4D@delong.com> On Mar 22, 2010, at 5:42 PM, Christopher Morrow wrote: > On Mon, Mar 22, 2010 at 3:53 PM, Stan Barber wrote: >> In this case, I am talking about an IPv6<->IPv6 NAT analogue to the current IPv4<->IPv4 >> NAT that is widely used with residential Internet service delivery today. > > I don't necessarily see 6-6 nat being used as 4-4 is today, but I do > think you'll see 6-6 nat in places. the current ietf draft for 'simple > cpe security' (draft-ietf-v6ops-cpe-simple-security-09.txt) is > potentially calling for some measures like nat, not nat today but... > That would be unfortunate, but, not unlikely. >> I believe that with IPv6 having much larger pool of addresses and each residential >> customer getting a large chunk of addresses will make IPv6<->IPv6 NAT unnecessary. I >> also believe that there will be IPv6 applications that require end-to-end communications >> that would be broken where NAT of that type used. Generally speaking, many users of > > I think you'll see apps like this die... quickly, but that's just my opinion. > This I think is both unfortunate and unlikely. They haven't died yet in IPv4 land, we just use ridiculous heroic measures like STUN, SNAT, UPNP, etc. to attempt to circumvent the damage known as NAT. >> the Internet today have not had the luxury to experience the end-to-end model because of >> the wide use of NAT. >> >> Given that these customers today don't routinely multihome today, I currently believe >> that behavior will continue. Multihoming is generally more complicated and expensive > > That's not obvious. if a low-cost (low pain, low price) means to > multihome became available I'm sure it'd change... things like > shim-6/mip-6 could do this. > Heh.. I don't see shim-6 deployment as low-pain. I think we will eventually need a true ID/Locator split, and I have an idea how it might be accomplished without altering the packet size, but, time will tell. >> than just having a single connection with a default route and most residential customers >> don't have the time, expertise or financial support to do that. So, the rate of multihoming >> will stay about the same even though the number of potential sites that could multihome >> could increase dramatically as IPv6 takes hold. >> >> Now, there are clearly lots of specifics here that may change over time concerning what >> the minimum prefix length for IPv6 advertisements might be acceptable in the DFZ (some >> want that to be /32, other are ok with something longer). I don't know how that will change >> over time. I also think that that peering will continue to increase and that the prefix >> lengths that peers will exchange with each other are and will continue to be less >> constrained by the conventions of the DFZ since the whole point of peering is to be >> mutually beneficial to those two peers and their customers. But, that being said, I don't >> think residential customers will routinely do native IPv6 peering either. I think IP6-in-IPv4 >> tunneling is and will continue to be popular and that already makes for some interesting >> IPv6 routing concerns. > > I firmly hope that ipv6-in-ipv4 dies... tunnel mtu problems are > horrific to debug. Indeed. I think at worst, IPv6-in-IPv4 will advance to a state where IPv4 MTU problems become largely historic. This will occur because as IPv6 gains popularity, an increasing number of IPv4-only users will be forced to this as their only means of achieving IPv6 connections in many cases. I wish it weren't so, but, it'll be a wonderful surprise if 6in4 dies any time soon. Arguably, having it become popular enough to force resolution to the various IPv4 MTU issues by default would be just as useful. Owen From nanog at daork.net Mon Mar 22 22:45:34 2010 From: nanog at daork.net (Nathan Ward) Date: Tue, 23 Mar 2010 16:45:34 +1300 Subject: IP4 Space In-Reply-To: <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> Message-ID: <967D6106-CA93-4B2A-993E-DCDAE00EE557@daork.net> On 19/03/2010, at 4:07 AM, Stan Barber wrote: > 1. Almost all home users (not businesses) that are connected to the Internet today via IPv4 are behind some kind of NAT box. In some cases, two NATs (one provided by the home user's router and one provided by some kind of ISP). There is no need for this using IPv6 to communicate with other IPv6 sites. There are a large number of users, here in NZ at least, but I imagine in other places, that have a single ethernet port "ADSL Modem" which terminates PPP, does IPv4 NAT, DHCP, etc. and then a "Wireless Router" which has its ethernet "Internet" plug connected to the "ADSL Modem", and does IPv4 NAT, DHCP to end hosts, etc. This means that they have double NAT inside the home, and then in the future a potential third NAT. We did some looking at packets, and 17% of outbound packets from customers at an ISP had TTLs that indicated two L3 hops in the home - which for the majority of cases would mean double NAT. In NZ the most popular ADSL deployment is PPPoATM, so the ADSL unit the ISP ships (either loaned, or included in the install cost) is an IPv4 router terminating a PPPoATM connection, not a bridge or anything. -- Nathan Ward From dts at senie.com Mon Mar 22 23:39:26 2010 From: dts at senie.com (Daniel Senie) Date: Tue, 23 Mar 2010 00:39:26 -0400 Subject: IP4 Space In-Reply-To: <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> Message-ID: <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> On Mar 22, 2010, at 6:53 PM, Stan Barber wrote: > In this case, I am talking about an IPv6<->IPv6 NAT analogue to the current IPv4<->IPv4 NAT that is widely used with residential Internet service delivery today. > > I believe that with IPv6 having much larger pool of addresses and each residential customer getting a large chunk of addresses will make IPv6<->IPv6 NAT unnecessary. I also believe that there will be IPv6 applications that require end-to-end communications that would be broken where NAT of that type used. Generally speaking, many users of the Internet today have not had the luxury to experience the end-to-end model because of the wide use of NAT. End-to-end applications will face much of the same interruption issues in the future as today. They will face firewall equipment that inspects the packet stream and purposefully blocks applications that are potentially harmful (e.g. vectors for systems infection). While the address translation part of stateful inspection firewall processing may not be used for IPv6, all other aspects of firewall function will be as applicable to IPv6 packets as they are to IPv4. > > Given that these customers today don't routinely multihome today, I currently believe that behavior will continue. Multihoming is generally more complicated and expensive than just having a single connection with a default route and most residential customers don't have the time, expertise or financial support to do that. So, the rate of multihoming will stay about the same even though the number of potential sites that could multihome could increase dramatically as IPv6 takes hold. I deal more with small businesses than residences, but I will take issue with the premise presented. Today there are many products, especially firewalls that allow "multihoming" of a sort using multiple upstream connections in conjunction with IPv4 and NAT. This is fairly simple, and can allow smaller offices, such as a company's field offices to combine multiple broadband connections, such as a cable modem and a DSL connection, to attain higher reliability and increased bandwidth. Because these appear to be just two broadband customer modems in one location (whether small business or residence), you cannot easily determine that such combining is being done. As this is a VERY useful, and well-used capability, it will be interesting to see what the vendors choose to offer in their equipment as IPv6 support improves. From owen at delong.com Tue Mar 23 00:13:27 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Mar 2010 22:13:27 -0700 Subject: IP4 Space In-Reply-To: <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> Message-ID: <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> On Mar 22, 2010, at 9:39 PM, Daniel Senie wrote: > > On Mar 22, 2010, at 6:53 PM, Stan Barber wrote: > >> In this case, I am talking about an IPv6<->IPv6 NAT analogue to the current IPv4<->IPv4 NAT that is widely used with residential Internet service delivery today. >> >> I believe that with IPv6 having much larger pool of addresses and each residential customer getting a large chunk of addresses will make IPv6<->IPv6 NAT unnecessary. I also believe that there will be IPv6 applications that require end-to-end communications that would be broken where NAT of that type used. Generally speaking, many users of the Internet today have not had the luxury to experience the end-to-end model because of the wide use of NAT. > > End-to-end applications will face much of the same interruption issues in the future as today. They will face firewall equipment that inspects the packet stream and purposefully blocks applications that are potentially harmful (e.g. vectors for systems infection). While the address translation part of stateful inspection firewall processing may not be used for IPv6, all other aspects of firewall function will be as applicable to IPv6 packets as they are to IPv4. > Sure, but, for the most part, it is the address translation part that does unintended damage to end-to-end protocols. The stateful inspection is intended interference, so usually a work-around is undesirable. In the case of NAT, there's often a need for a workaround due to the unintended consequences. Hence the creation of STUN, SNAT, UPNP, etc. >> >> Given that these customers today don't routinely multihome today, I currently believe that behavior will continue. Multihoming is generally more complicated and expensive than just having a single connection with a default route and most residential customers don't have the time, expertise or financial support to do that. So, the rate of multihoming will stay about the same even though the number of potential sites that could multihome could increase dramatically as IPv6 takes hold. > > I deal more with small businesses than residences, but I will take issue with the premise presented. Today there are many products, especially firewalls that allow "multihoming" of a sort using multiple upstream connections in conjunction with IPv4 and NAT. This is fairly simple, and can allow smaller offices, such as a company's field offices to combine multiple broadband connections, such as a cable modem and a DSL connection, to attain higher reliability and increased bandwidth. > Albeit with a number of less than ideal tradeoffs vs. a BGP-based multihoming solution. With the smaller routing table afforded by IPv6, this will be less expensive. As a result, I suspect there will be more IPv6 small multihomers. That's generally a good thing. > Because these appear to be just two broadband customer modems in one location (whether small business or residence), you cannot easily determine that such combining is being done. > > As this is a VERY useful, and well-used capability, it will be interesting to see what the vendors choose to offer in their equipment as IPv6 support improves. > It's pretty easy to do this in IPv6 without NAT. Just advertise both prefixes in the RA from the device and you're done. Owen From newton at internode.com.au Tue Mar 23 00:27:27 2010 From: newton at internode.com.au (Mark Newton) Date: Tue, 23 Mar 2010 15:57:27 +1030 Subject: IP4 Space In-Reply-To: <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> Message-ID: <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> On 23/03/2010, at 3:43 PM, Owen DeLong wrote: > > With the smaller routing table afforded by IPv6, this will be less expensive. As a result, I suspect there will be more IPv6 small multihomers. > That's generally a good thing. Puzzled: How does the IPv6 routing table get smaller? There's currently social pressure against deaggregation, but given time why do you think the same drivers that lead to v4 deaggregation won't also lead to v6 deaggregation? (small multihomers means more discontiguous blocks of PI space too, right?) - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From Valdis.Kletnieks at vt.edu Tue Mar 23 01:53:50 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 23 Mar 2010 02:53:50 -0400 Subject: NSP-SEC In-Reply-To: Your message of "Mon, 22 Mar 2010 23:02:02 BST." References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> <18013.1269263315@localhost> Message-ID: <18662.1269327230@localhost> On Mon, 22 Mar 2010 23:02:02 BST, Guillaume FORTAINE said: > How much money would you evaluate a security incident on your Cisco device ? It would depend on which of the 3,000+ Cisco devices on our network had the incident. And yes, we've got a pretty good estimate (to within $1.57 or so) of what an incident on any given device would cost. > Because, the fundamental questions are : > a) How much value does your network bring to your business ? > b) How much money are you ready to spend to ensure its security ? We've got a pretty good idea what value our network brings us. We also know how much we're *ready* to spend. However, that's not the critical number. You missed the most important question of all: (c) How much money do you need to spend to minimize the total cost of protection plus losses. If you're currently spending $50K, but you're *willing* to spend $250K, it only makes actual sense to do so if the additional spending prevents more than $200K of additional losses. And this calculation needs to include second-order effects - if Cisco starts shipping monthly updates rather than every 6 months, it doesn't do any *actual* good unless our internal test lab ramps up so it can vet a new release in a few weeks rather than a few months. That's an additional cost. Meanwhile, there are a *lot* of sites that find themselves stuck on a specific build of IOS because it's the only one that fixes bug A but also doesn't suffer from bug B. If you deploy a new release of IOS that contains a fix for a security hole, and the fix eliminates an expectation value of $10K of losses, but contains a non-security bug that starts your help desk phone ringing and racks up $20K of support costs, it's a net loss. Those second-order effect costs are a bitch. And a half. I'm pretty sure that most of the other big Cisco shops have done exactly the same risk calculus, and decided that the added expense of moving to a monthly rather than bi-annual wasn't worth it. And since the sites aren't clamoring to buy it, Cisco isn't offering it. (For the record, for many large shops, Microsoft's "Patch Tuesday" has similar cost-benefit issues - updating your "crown jewel" production servers once a month is a truly scary amount of code churn. The only reason Microsoft does it is for the millions of consumer-grade boxes that auto-update, a use case that doesn't exist for most of Cisco's product line.) > Conclusion : if you can't reply to these fundamental questions, hire a > CISO and build a CSIRT. I *so* hate making an argument from authority (other than "I think smb published a paper on that already"), but in your case I'll make an exception. Go read http://www.sans.org/dosstep/roadmap.php Read the date, read the signatories. Ask yourself if you *really* want to be telling me that we need to build a CSIRT. (Answer - our CIRT was up and running back in 1991, and was well-known in 2000. So no, we don't need advice on how to start one. We've got literally man-centuries of experience in running one already. By the way, where were you in 1991?) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Tue Mar 23 02:40:00 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 23 Mar 2010 00:40:00 -0700 Subject: IP4 Space In-Reply-To: <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> Message-ID: On Mar 22, 2010, at 10:27 PM, Mark Newton wrote: > > On 23/03/2010, at 3:43 PM, Owen DeLong wrote: >> >> With the smaller routing table afforded by IPv6, this will be less expensive. As a result, I suspect there will be more IPv6 small multihomers. >> That's generally a good thing. > > Puzzled: How does the IPv6 routing table get smaller? > Compared to IPv4? Because we don't do slow start, so, major providers won't be advertising 50-5,000 prefixes for a single autonomous system. > There's currently social pressure against deaggregation, but given time > why do you think the same drivers that lead to v4 deaggregation won't also > lead to v6 deaggregation? > I think that the same drivers will apply, but, think of IPv6 as a Big 10->1 reset button on those drivers. Sure, in 30 years, we may be back to a 300,000 prefix table, but, in 30 years, a 300,000 prefix table will be well within the hardware capabilities instead of on the ragged edge we face today. > (small multihomers means more discontiguous blocks of PI space too, right?) > Yep. It does. However, IPv6 gives us a 30-50,000 prefix table now (when we get there) and 10-30 years to solve either the TCAM scaling issue or come up with a better routing paradigm. I think that eventually an ID/Locator split paradigm will emerge that is deployable. I think that SHIM6 and the others proposed so far are far too complex and end-host dependent to ever be deployable. Likely we will need to modify the packet header to be able to incorporate a locator in the header in the DFZ and do some translation at the edge. I haven't fully figured out the ideal solution, but, I think several others are working on it, too. Owen From gfortaine at live.com Tue Mar 23 05:13:48 2010 From: gfortaine at live.com (Guillaume FORTAINE) Date: Tue, 23 Mar 2010 11:13:48 +0100 Subject: NSP-SEC In-Reply-To: <18662.1269327230@localhost> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> <18013.1269263315@localhost> <18662.1269327230@localhost> Message-ID: >> Conclusion : if you can't reply to these fundamental questions, hire a >> CISO and build a CSIRT. >> > I *so* hate making an argument from authority (other than "I think smb > published a paper on that already"), but in your case I'll make an exception. > > Go read http://www.sans.org/dosstep/roadmap.php > > Read the date, read the signatories. I have read with interest this document. 1) Remarks : -Bill Clinton is no longer the president of USA . Howard Schmidt is the new cybersecurity czar : http://www.facebook.com/howardas (By the way, Gadi Evron is in his Facebook friends ?!?) 2) Notes : a) Problem 1: Spoofing & Problem 2: Broadcast Amplification http://docs.google.com/viewer?url=http://www.dca.fee.unicamp.br/~chesteve/pubs/LIPSIN_sigcomm2009_jokela.pdf b) Problem 3: Lack of Appropriate Response To Attacks http://docs.google.com/viewer?url=http://nanog.org/meetings/nanog47/presentations/Sunday/Green_Top10_Security_N47_Sun.pdf c) Problem 4: Unprotected Computers http://docs.google.com/viewer?url=http://www.whitehouse.gov/files/documents/cyber/Gourley_Bob_Open_Source_Software_and_Cyber_Defense_01_April_2009.pdf > Ask yourself if you *really* want to be > telling me that we need to build a CSIRT. (Answer - our CIRT was up and > running back in 1991, and was well-known in 2000. So no, we don't need advice > on how to start one. VT-CIRT : http://docs.google.com/viewer?url=http://www.it.vt.edu/publications/annualreports/annualreport2007-2008.pdf o Students designed, built, and are maintaining the vulnerability scan engines that are the core of the www.ids.cirt.vt.edu site. CSIRT-MU : http://docs.google.com/viewer?url=http://www.vabo.cz/spi/2009/presentations/03/02-celeda_rehak_CAMNEP_no_video.pdf Project Results Further Information: 3 Journal papers, including IEEE Intelligent Systems 20+ conference papers (RAID, AAMAS, IAT, FloCon,...) How to get it? University startups: -INVEA-TECH a.s. - FlowMon probes, collectors for high-speed data monitoring (with MU, VUT and CESNET) -Cognitive Security s.r.o. - CAMNEP system for real-time data mining (with CTU) Supported by: U.S. ARMY RDECOM-CERDEC, CESNET, Czech MOD > We've got literally man-centuries of experience in running > one already. By the way, where were you in 1991?) > > In 1991, I was in primary school. In 2000, the date of your link, I got my first access to Internet. And now ? ;) ! Best Regards, Guillaume FORTAINE From stmagconsulting at gmail.com Tue Mar 23 05:43:47 2010 From: stmagconsulting at gmail.com (Stephane MAGAND) Date: Tue, 23 Mar 2010 11:43:47 +0100 Subject: MPLS Provider at New York ? Message-ID: Hi I don't see on google a list of MPLS Provider at New York City. Anyone know a small mpls provider in this city ? Bye Stephane From bill at herrin.us Tue Mar 23 07:17:13 2010 From: bill at herrin.us (William Herrin) Date: Tue, 23 Mar 2010 08:17:13 -0400 Subject: IP4 Space In-Reply-To: References: <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> Message-ID: <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> On Tue, Mar 23, 2010 at 3:40 AM, Owen DeLong wrote: > On Mar 22, 2010, at 10:27 PM, Mark Newton wrote: >> On 23/03/2010, at 3:43 PM, Owen DeLong wrote: >>> With the smaller routing table afforded by IPv6, this will be less expensive. As a result, I suspect there will be more IPv6 small multihomers. >>> That's generally a good thing. >> >> Puzzled: ?How does the IPv6 routing table get smaller? >> > Compared to IPv4? ?Because we don't do slow start, so, major providers won't be > advertising 50-5,000 prefixes for a single autonomous system. On the other hand, smaller ASes still announce the same number, the hardware resource consumption for an IPv6 route is at least double that of an IPv4 entry, RIR policy implies more bits for TE disaggregation than is often possible in IPv4 and dual-stack means that the IPv6 routing table is strictly additive to the IPv4 routing table for the foreseeable future. Your thesis has some weaknesses. 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 Tue Mar 23 07:59:26 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 23 Mar 2010 08:59:26 -0400 Subject: NSP-SEC In-Reply-To: Your message of "Tue, 23 Mar 2010 11:13:48 BST." References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> <18013.1269263315@localhost> <18662.1269327230@localhost> Message-ID: <332.1269349166@localhost> On Tue, 23 Mar 2010 11:13:48 BST, Guillaume FORTAINE said: > I have read with interest this document. (lots of irrelevant commentary elided - the vast majority of which merely confirms the point that a lot of people have been doing further research on issues that we identified a decade and more ago) > In 1991, I was in primary school. In 2000, the date of your link, I got > my first access to Internet. And now ? ;) ! And now, you're still acting like you've got new unique insights and going out of your way to irritate the very same more experienced people that you probably should be trying to learn from, when you haven't bothered to find out that you're once again 10 and 20 years behind the curve: http://en.wikipedia.org/wiki/Plonk_%28Usenet%29 Wow. Rich Sexton really *did* contribute something important to the Net. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tdurack at gmail.com Tue Mar 23 08:25:29 2010 From: tdurack at gmail.com (Tim Durack) Date: Tue, 23 Mar 2010 09:25:29 -0400 Subject: IP4 Space In-Reply-To: <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> References: <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> Message-ID: <9e246b4d1003230625i443fc0k6a930635f5f743aa@mail.gmail.com> On Tue, Mar 23, 2010 at 8:17 AM, William Herrin wrote: > On Tue, Mar 23, 2010 at 3:40 AM, Owen DeLong wrote: >> On Mar 22, 2010, at 10:27 PM, Mark Newton wrote: >>> On 23/03/2010, at 3:43 PM, Owen DeLong wrote: >>>> With the smaller routing table afforded by IPv6, this will be less expensive. As a result, I suspect there will be more IPv6 small multihomers. >>>> That's generally a good thing. >>> >>> Puzzled: ?How does the IPv6 routing table get smaller? >>> >> Compared to IPv4? ?Because we don't do slow start, so, major providers won't be >> advertising 50-5,000 prefixes for a single autonomous system. > > On the other hand, smaller ASes still announce the same number, the > hardware resource consumption for an IPv6 route is at least double > that of an IPv4 entry, RIR policy implies more bits for TE > disaggregation than is often possible in IPv4 and dual-stack means > that the IPv6 routing table is strictly additive to the IPv4 routing > table for the foreseeable future. Your thesis has some weaknesses. Plus the RIRs are currently applying pressure to assign only the bare minimum IPv6 address space to PI multi-homers (at least, the RIR I deal with.) I can see this quickly leading to non-contiguous assignments in the not to distant future. Today I have enough address space to easily allocate /48s per site, assuming a /64 per VLAN. But I can see the need to assign /56s per switch port for dhcp-pd. If I were to assign a /48 per switch stack (seems like a reasonable engineering decision), I'm quickly going to burn through lots of /48s. I'm sure I could come up with clever ways to save address space, but I'm wondering why when one of the promises of IPv6 is to avoid having to think too hard about individual assignments. -- Tim:> From nick at foobar.org Tue Mar 23 08:30:46 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 23 Mar 2010 13:30:46 +0000 Subject: NSP-SEC In-Reply-To: <332.1269349166@localhost> References: <20100319083143.553b0111@t61p> <1269006269.1220.135.camel@petrie> <1269110278.1220.147.camel@petrie> <18013.1269263315@localhost> <18662.1269327230@localhost> <332.1269349166@localhost> Message-ID: <4BA8C286.705@foobar.org> On 23/03/2010 12:59, Valdis.Kletnieks at vt.edu wrote: > And now, you're still acting like you've got new unique insights and going out > of your way to irritate the very same more experienced people that you probably > should be trying to learn from, when you haven't bothered to find out that > you're once again 10 and 20 years behind the curve: Do not feed the troll. Nick From cldeluna at yahoo.com Tue Mar 23 10:30:02 2010 From: cldeluna at yahoo.com (Claudia de Luna) Date: Tue, 23 Mar 2010 08:30:02 -0700 (PDT) Subject: Cisco Unified Computing System Message-ID: <130832.45681.qm@web52504.mail.re2.yahoo.com> Hello, Does anyone have any hands on experience with Cisco's Unified Computing System? Knowing some of the issues it purports to address the solution seems compelling but the devil is in the details. I generally lean towards the "best of breed" approach and am wary of any solution that claims to do many things (often poorly) vs. one thing very well. I'm particularly interested in the hooks that the system is supposed to have for 3rd party tools. In my experience Cisco has not led the way in network management and a large part of this solution is the management system to provision end to end services. Any experience with this solution would be most welcome, on or off list. Thank You, Claudia From pauldotwall at gmail.com Tue Mar 23 10:34:35 2010 From: pauldotwall at gmail.com (Paul WALL) Date: Tue, 23 Mar 2010 11:34:35 -0400 Subject: MPLS Provider at New York ? In-Reply-To: References: Message-ID: <620fd17c1003230834v1a141062oecc02251a3e4cd8a@mail.gmail.com> On Tue, Mar 23, 2010 at 6:43 AM, Stephane MAGAND wrote: > I don't see on google a list of MPLS Provider at New York City. > > Anyone know a small mpls provider in this city ? It would probably help if you'd provide particulars such as desired A/Z locations and connection speeds. Drive Slow, Paul WALL From isabeldias1 at yahoo.com Tue Mar 23 11:00:26 2010 From: isabeldias1 at yahoo.com (isabel dias) Date: Tue, 23 Mar 2010 09:00:26 -0700 (PDT) Subject: IP4 Space In-Reply-To: <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> References: <3c3e3fca1003041130v7691ea97r48cb48cdd92fe7b0@mail.gmail.com> <5BE3CF7E-961C-42E3-9262-92439B994428@virtualized.org> <3c3e3fca1003050524k76837083t9620b397da37c99e@mail.gmail.com> <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> Message-ID: <616356.22220.qm@web52604.mail.re2.yahoo.com> "IPv6 routing table 7-10 times smaller than the IPv4 routing table" http://lists.arin.net/pipermail/arin-ppml/2009-May/014240.html :-) ? a bit of old stuff to get to the bottom line....? http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-plenary-bgp.pdf ? ----- Original Message ---- From: Mark Newton To: Owen DeLong Cc: NANOG list Sent: Tue, March 23, 2010 5:27:27 AM Subject: Re: IP4 Space On 23/03/2010, at 3:43 PM, Owen DeLong wrote: > > With the smaller routing table afforded by IPv6, this will be less expensive. As a result, I suspect there will be more IPv6 small multihomers. > That's generally a good thing. Puzzled:? How does the IPv6 routing table get smaller? There's currently social pressure against deaggregation, but given time why do you think the same drivers that lead to v4 deaggregation won't also lead to v6 deaggregation? (small multihomers means more discontiguous blocks of PI space too, right?) ? - mark -- Mark Newton? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Email:? newton at internode.com.au (W) Network Engineer? ? ? ? ? ? ? ? ? ? ? ? ? Email:? newton at atdot.dotat.org? (H) Internode Pty Ltd? ? ? ? ? ? ? ? ? ? ? ? Desk:? +61-8-82282999 "Network Man" - Anagram of "Mark Newton"? Mobile: +61-416-202-223 From owen at delong.com Tue Mar 23 12:27:53 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 23 Mar 2010 10:27:53 -0700 Subject: IP4 Space In-Reply-To: <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> References: <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> Message-ID: On Mar 23, 2010, at 5:17 AM, William Herrin wrote: > On Tue, Mar 23, 2010 at 3:40 AM, Owen DeLong wrote: >> On Mar 22, 2010, at 10:27 PM, Mark Newton wrote: >>> On 23/03/2010, at 3:43 PM, Owen DeLong wrote: >>>> With the smaller routing table afforded by IPv6, this will be less expensive. As a result, I suspect there will be more IPv6 small multihomers. >>>> That's generally a good thing. >>> >>> Puzzled: How does the IPv6 routing table get smaller? >>> >> Compared to IPv4? Because we don't do slow start, so, major providers won't be >> advertising 50-5,000 prefixes for a single autonomous system. > > On the other hand, smaller ASes still announce the same number, the > hardware resource consumption for an IPv6 route is at least double > that of an IPv4 entry, RIR policy implies more bits for TE > disaggregation than is often possible in IPv4 and dual-stack means > that the IPv6 routing table is strictly additive to the IPv4 routing > table for the foreseeable future. Your thesis has some weaknesses. > With 30,000 active AS right now, assuming an average of 2 instead of 9.5, even if we double the number of active AS every 5 years, we're still looking at 10 years for the IPv6 routing table to catch up. 30,000 * 2 = 60,000 prefixes today 120,000 prefixes in 5 years (60,000 active AS) 240,000 prefixes in 10 years (120,000 active AS) I think that the additive nature of the IPv6/IPv4 routing tables will be the driving factor for deprecation of IPv4 pretty quickly once IPv6 starts to reach critical mass. The problem is that we are so early on the IPv6 adoption curve right now that nobody believes IPv6 will become ubiquitous fast enough to be relevant. I think that IPv6 deployment is already showing signs of acceleration. I think that it will lurch forward suddenly shortly after (~6-12 months) IPv4 finally hits the runout wall in a couple of years. Owen From mehmet at icann.org Tue Mar 23 12:29:35 2010 From: mehmet at icann.org (Mehmet Akcin) Date: Tue, 23 Mar 2010 10:29:35 -0700 Subject: CHINANET-JX Contact Message-ID: inetnum: 59.52.0.0 - 59.55.255.255 netname: CHINANET-JX descr: CHINANET Jiangxi province network descr: China Telecom Anyone from China Telecom , can you please contact me off-list? Thanks Mehmet From morrowc.lists at gmail.com Tue Mar 23 12:40:28 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 23 Mar 2010 10:40:28 -0700 Subject: IP4 Space In-Reply-To: References: <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> Message-ID: <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> On Tue, Mar 23, 2010 at 10:27 AM, Owen DeLong wrote: > I think that the additive nature of the IPv6/IPv4 routing tables ?will be the > driving factor for deprecation of IPv4 pretty quickly once IPv6 starts to > reach critical mass. ?The problem is that we are so early on the IPv6 > adoption curve right now that nobody believes IPv6 will become > ubiquitous fast enough to be relevant. it seems to me that we'll have widespread ipv4 for +10 years at least, potentially there will be enough ipv4 alive in 20 years to still consider it 'widespread'. I also think we'll see more v4 routes (longer prefixes) show up in the first 10yrs, before it gets better :( I could be wrong, I hope I am, but... > I think that IPv6 deployment is already showing signs of acceleration. > I think that it will lurch forward suddenly shortly after (~6-12 months) > IPv4 finally hits the runout wall in a couple of years. I agree that v6 deployments seem to be getting better/faster/stronger... I think that's good news, but we'll still be paying the v4 piper for a while. -Chris > Owen > > > From owen at delong.com Tue Mar 23 14:10:36 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 23 Mar 2010 12:10:36 -0700 Subject: IP4 Space In-Reply-To: <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> References: <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> Message-ID: On Mar 23, 2010, at 10:40 AM, Christopher Morrow wrote: > On Tue, Mar 23, 2010 at 10:27 AM, Owen DeLong wrote: > >> I think that the additive nature of the IPv6/IPv4 routing tables will be the >> driving factor for deprecation of IPv4 pretty quickly once IPv6 starts to >> reach critical mass. The problem is that we are so early on the IPv6 >> adoption curve right now that nobody believes IPv6 will become >> ubiquitous fast enough to be relevant. > > it seems to me that we'll have widespread ipv4 for +10 years at least, > potentially there will be enough ipv4 alive in 20 years to still > consider it 'widespread'. I also think we'll see more v4 routes > (longer prefixes) show up in the first 10yrs, before it gets better :( > I think the pressure to start deprecating IPv4 will start in approximately 11-12 years... Now = T0 T+3 years -- IPv4 runs out - Completely, not just IANA or RIRs, but, ISPs, too. T+8 years -- IPv6 nears ubiquity at least on the public internet T+11 years -- Economic pressures begin to drive the deprecation of IPv4. > I could be wrong, I hope I am, but... > >> I think that IPv6 deployment is already showing signs of acceleration. >> I think that it will lurch forward suddenly shortly after (~6-12 months) >> IPv4 finally hits the runout wall in a couple of years. > > I agree that v6 deployments seem to be getting > better/faster/stronger... I think that's good news, but we'll still be > paying the v4 piper for a while. > Yep. I completely agree. Owen From drc at virtualized.org Tue Mar 23 15:57:08 2010 From: drc at virtualized.org (David Conrad) Date: Tue, 23 Mar 2010 13:57:08 -0700 Subject: IP4 Space In-Reply-To: References: <3B128C1B-B1AE-4927-A1CD-208A5BBDB590@academ.com> <3c3e3fca1003181225g7b5049b9s4d1080b317c546db@mail.gmail.com> <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> Message-ID: On Mar 23, 2010, at 10:27 AM, Owen DeLong wrote: > With 30,000 active AS right now, assuming an average of 2 instead of 9.5, You appear to be assuming ISPs (like the ones that have received /18s, /19s, /20s, etc.) aren't going to deaggregate for traffic engineering purposes. Or do I misunderstand? Regards, -drc From jeroen at mompl.net Tue Mar 23 16:43:45 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 23 Mar 2010 14:43:45 -0700 Subject: 2009 IPv4 Address Use Report In-Reply-To: <5943D71A-865D-4B31-AC1A-FADA5498DB60@muada.com> References: <5943D71A-865D-4B31-AC1A-FADA5498DB60@muada.com> Message-ID: <4BA93611.3030708@mompl.net> Iljitsch van Beijnum wrote: > [ (Non-cross)posted to NANOG, PPML, RIPE IPv6 wg, Dutch IPv6 TF. Web version for the monospace font impaired and with some links: > http://www.bgpexpert.com/addrspace2009.php ] > > 2009 IPv4 Address Use Report > > As of January first, 2010, the number of unused IPv4 addresses is 722.18 million. On January 1, 2009, this was 925.58 million. So in 2009, 203.4 million addresses were used up. This is the first time since the introduction of CIDR in 1993 that the number of addresses used in a year has topped 200 million. With 3706.65 million usable addresses, 80.5% of the available IPv4 addresses are now in some kind of use, up from 75.3% a year ago. So the depletion of the IPv4 address reserves is continuing in much the same way as in previous years: > > Date Addresses free Used up > 2006-01-01 1468.61 M > 2007-01-01 1300.65 M 167.96 M > 2008-01-01 1122.85 M 177.80 M (with return of 16.78 M to IANA) > 2009-01-01 925.58 M 197.27 M > 2010-01-01 722.18 M 203.40 M > > These figures are derived from from the Internet Assigned Numbers Authority's IANA IPv4 Address Space Registry page and the records published on the FTP servers of the five Regional Internet Registries (RIRs): AfriNIC, which gives out address space in Africa, APNIC (Asia-Pacific region), ARIN (North America), LACNIC (Latin American and the Caribbean) and the RIPE NCC (Europe, the former Soviet Union and the Middle East). > > The IANA list shows the status of all 256 blocks of 16777216 addresses identified by the first 8-bit number in the IPv4 address. > http://www.bgpexpert.com/ianaglobalpool.php is a graphical representation of the IANA global pool (updated weekly). The RIR data indicates how much address space the RIRs have delegated to internet service providers (and sometimes end-users). The changes over the course of 2009 are as follows: Interesting statistics. It'd be interesting to know what % of newly assigned addresses are used for fraudulent and illegal purposes such as spam and scamming (how soon and how frequently will the newly assigned 1.1.1.0/8 block start appearing in block lists and spam reports?). From morrowc.lists at gmail.com Tue Mar 23 16:49:30 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 23 Mar 2010 14:49:30 -0700 Subject: 2009 IPv4 Address Use Report In-Reply-To: <4BA93611.3030708@mompl.net> References: <5943D71A-865D-4B31-AC1A-FADA5498DB60@muada.com> <4BA93611.3030708@mompl.net> Message-ID: <75cb24521003231449j5672b32dy5357af26aa565d87@mail.gmail.com> On Tue, Mar 23, 2010 at 2:43 PM, Jeroen van Aart wrote: > Interesting statistics. > > It'd be interesting to know what % of newly assigned addresses are used for > fraudulent and illegal purposes such as spam and scamming (how soon and how > frequently will the newly assigned 1.1.1.0/8 block start appearing in block > lists and spam reports?). it's not clear that 1.1.1.0/24 is actually assigned to anyone, RIPE/APNIC were just using for some experiments. Did you actually mean 1.0.0.0/8? From jdfalk-lists at cybernothing.org Tue Mar 23 17:15:22 2010 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Tue, 23 Mar 2010 15:15:22 -0700 Subject: AOL Postmaster In-Reply-To: <4BA7C3C9.4060707@cox.net> References: <4BA7BF1E.8000101@viviotech.net> <4BA7C3C9.4060707@cox.net> Message-ID: On Mar 22, 2010, at 12:23 PM, Larry Sheldon wrote: > On 3/22/2010 14:03, Mark Keymer wrote: >> Hi, >> >> If at all possible can a AOL Postmaster please get a hold of me. I have >> a client that co-lo's with use and we do the support for them and we >> need some help on getting mail to be delivering again to AOL. > > Didn't I read that all of the AOL Postmasters had been....what is the > word this week...made redundant? Most, but not all. You can reach those who remain via http://postmaster.aol.net/, just as before. -- J.D. Falk Return Path Inc From jeroen at mompl.net Tue Mar 23 17:44:11 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 23 Mar 2010 15:44:11 -0700 Subject: 2009 IPv4 Address Use Report In-Reply-To: <75cb24521003231449j5672b32dy5357af26aa565d87@mail.gmail.com> References: <5943D71A-865D-4B31-AC1A-FADA5498DB60@muada.com> <4BA93611.3030708@mompl.net> <75cb24521003231449j5672b32dy5357af26aa565d87@mail.gmail.com> Message-ID: <4BA9443B.7080504@mompl.net> Christopher Morrow wrote: > it's not clear that 1.1.1.0/24 is actually assigned to anyone, > RIPE/APNIC were just using for some experiments. Did you actually mean > 1.0.0.0/8? Uhm, yes of course. Thanks :-) From Bryan.Welch at arrisi.com Tue Mar 23 20:35:13 2010 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Tue, 23 Mar 2010 18:35:13 -0700 Subject: Experiences with A10 AX series Load Balancers? Message-ID: Does anyone have any experiences good/bad/indifferent with this company and their products? They claim 2x the performance at ? the cost and am a bit leery as you can imagine. We are looking to replace our aging F5 BigIP LTM's and will be evaluating these along with the Netscaler and new generation F5 boxes. Regards, Bryan From newton at internode.com.au Tue Mar 23 21:59:31 2010 From: newton at internode.com.au (Mark Newton) Date: Wed, 24 Mar 2010 13:29:31 +1030 Subject: IP4 Space In-Reply-To: <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> References: <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> Message-ID: <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> On 24/03/2010, at 4:10 AM, Christopher Morrow wrote: > > it seems to me that we'll have widespread ipv4 for +10 years at least, How many 10 year old pieces of kit do you have on your network? Ten years ago we were routing appletalk and IPX. Still doing that now? Ten years ago companies were still selling ISDN routers which still insisted on classful addressing. Got any of them left on the network? I'd expect that v4 will still exist in legacy form behind firewalls, but I think its deprecation on the public internet will happen a lot faster than anyone expects. > I agree that v6 deployments seem to be getting > better/faster/stronger... I think that's good news, but we'll still be > paying the v4 piper for a while. Only until v4 becomes more expensive (using whatever metric matters to you) than v6. After you pass that tipping point, v4 deployment will stop dead. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From bmanning at vacation.karoshi.com Tue Mar 23 22:16:11 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 24 Mar 2010 03:16:11 +0000 Subject: IP4 Space In-Reply-To: <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> References: <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> Message-ID: <20100324031611.GB4441@vacation.karoshi.com.> tell me Mark, when will you turn off -all- IPv4 in your network? no snmp/aaa, no syslog, no radius, no licensed s/w keyed to a v4 address, no need to keep logs for leos' (whats the data retention law in your jurisdiction?) etc... simple switching of datagrams over non-v4 transport is trivial. th O&M behnd running production is a slightly longer path and the legal requirements these days didn't exisit a decade ago. Chris was optimistic at 10+ years. imho --bill On Wed, Mar 24, 2010 at 01:29:31PM +1030, Mark Newton wrote: > > On 24/03/2010, at 4:10 AM, Christopher Morrow wrote: > > > > it seems to me that we'll have widespread ipv4 for +10 years at least, > > How many 10 year old pieces of kit do you have on your network? > > Ten years ago we were routing appletalk and IPX. Still doing that > now? > > Ten years ago companies were still selling ISDN routers which still > insisted on classful addressing. Got any of them left on the network? > > I'd expect that v4 will still exist in legacy form behind firewalls, > but I think its deprecation on the public internet will happen a lot > faster than anyone expects. > > > I agree that v6 deployments seem to be getting > > better/faster/stronger... I think that's good news, but we'll still be > > paying the v4 piper for a while. > > Only until v4 becomes more expensive (using whatever metric matters to > you) than v6. > > After you pass that tipping point, v4 deployment will stop dead. > > - mark > > -- > Mark Newton Email: newton at internode.com.au (W) > Network Engineer Email: newton at atdot.dotat.org (H) > Internode Pty Ltd Desk: +61-8-82282999 > "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 > > > > > > From bill at herrin.us Tue Mar 23 22:37:27 2010 From: bill at herrin.us (William Herrin) Date: Tue, 23 Mar 2010 23:37:27 -0400 Subject: IP4 Space In-Reply-To: <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> References: <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> Message-ID: <3c3e3fca1003232037v25294156m8b2183a93f017d9e@mail.gmail.com> On Tue, Mar 23, 2010 at 10:59 PM, Mark Newton wrote: > Only until v4 becomes more expensive (using whatever metric matters to > you) than v6. > > After you pass that tipping point, v4 deployment will stop dead. Mark, You offer an accurate but incomplete assessment. IPv4 allocation's upcoming transition to a zero-sum game might not push it above the "cost" of IPv6. The economics in play haven't ruled out the possibility. Should that occur, IPv6 will tend to fade to the background during the following table-size driven router upgrade cycle. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From newton at internode.com.au Tue Mar 23 22:54:45 2010 From: newton at internode.com.au (Mark Newton) Date: Wed, 24 Mar 2010 14:24:45 +1030 Subject: IP4 Space In-Reply-To: <20100324031611.GB4441@vacation.karoshi.com.> References: <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> <20100324031611.GB4441@vacation.karoshi.com.> Message-ID: <977BEB7E-9E88-4E17-98CC-5EFDCA9F0ADF@internode.com.au> On 24/03/2010, at 1:46 PM, wrote: > > tell me Mark, > > when will you turn off -all- IPv4 in your network? I don't imagine there'll be a date as such; We'll just enable IPv6 versions of the services you've mentioned on equipment which supports it, and note that over time the number of systems still using v6 to perform those functions diminishes. > simple switching of datagrams over non-v4 transport is trivial. th O&M behnd > running production is a slightly longer path and the legal requirements these > days didn't exisit a decade ago. Chris was optimistic at 10+ years. There seems to be an assumption that continuing to run v4 on a v6 internet will be free, or at least cheap. I don't think it will be. I think it'll rapidly become horrendously expensive in operational support terms, and that we'll all see significant pressure from our CFOs and CTOs to get rid of it well before the ten-year estimate expires. ... and if we don't, our customers will. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From bmanning at vacation.karoshi.com Tue Mar 23 23:04:41 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 24 Mar 2010 04:04:41 +0000 Subject: IP4 Space In-Reply-To: <977BEB7E-9E88-4E17-98CC-5EFDCA9F0ADF@internode.com.au> References: <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> <20100324031611.GB4441@vacation.karoshi.com.> <977BEB7E-9E88-4E17-98CC-5EFDCA9F0ADF@internode.com.au> Message-ID: <20100324040441.GA5577@vacation.karoshi.com.> On Wed, Mar 24, 2010 at 02:24:45PM +1030, Mark Newton wrote: > > On 24/03/2010, at 1:46 PM, wrote: > > > > > tell me Mark, > > > > when will you turn off -all- IPv4 in your network? > > I don't imagine there'll be a date as such; We'll just enable > IPv6 versions of the services you've mentioned on equipment which > supports it, and note that over time the number of systems still > using v6 to perform those functions diminishes. so 10+ years then... since most of those systems are not ported to IPv6 yet, even in alpha-stage software. I still am interested in what the AU legal requirements for data retention are regarding traceablity of records. Seven years? or was it ten? Can you afford to purge legally mandated data records just because you move to new transport? > > > simple switching of datagrams over non-v4 transport is trivial. th O&M behnd > > running production is a slightly longer path and the legal requirements these > > days didn't exisit a decade ago. Chris was optimistic at 10+ years. > > There seems to be an assumption that continuing to run v4 on a v6 internet > will be free, or at least cheap. > > I don't think it will be. I think it'll rapidly become horrendously expensive > in operational support terms, and that we'll all see significant pressure from > our CFOs and CTOs to get rid of it well before the ten-year estimate expires. perhaps - the horrendously expensive costs come with dual-stacking. and it is true that the least costly systems will gain market share, be it v6 or v4... both will be using NAT and NAT-like technologies (reference the doubleNAT discourse from our friend Nathan Ward and the active discussion in the IETF on "simple security") > ... and if we don't, our customers will. in my experience with networks running IPX, Appletalk, DECnet, DECnet-PhaseV, VTAM and IP... customers could cre less about the transport protocol. Can they get to the things they want and in a timely fashion is the obvious criteria. > - mark > > -- > Mark Newton Email: newton at internode.com.au (W) > Network Engineer Email: newton at atdot.dotat.org (H) > Internode Pty Ltd Desk: +61-8-82282999 > "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 > > > > > From morrowc.lists at gmail.com Wed Mar 24 00:46:54 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 23 Mar 2010 22:46:54 -0700 Subject: IP4 Space In-Reply-To: <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> References: <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> Message-ID: <75cb24521003232246q32ea5ccen1e81ef7e91a97946@mail.gmail.com> On Tue, Mar 23, 2010 at 7:59 PM, Mark Newton wrote: > > On 24/03/2010, at 4:10 AM, Christopher Morrow wrote: >> >> it seems to me that we'll have widespread ipv4 for +10 years at least, > > How many 10 year old pieces of kit do you have on your network? it's not my network anymore (or not the one I work on anymore) but... 702 had +400 7500's of 1996 vintage when I left, 703 had somewhere near 200 or so of similar vintage 7500's and 7200's... Sprint still does T1 agg on 7500's. ATT I'm sure has 75's in the network as well. If there's low margin and no 'cost' to run the gear, why would I upgrade?? > Ten years ago we were routing appletalk and IPX. ?Still doing that > now? apples and oranges. > I'd expect that v4 will still exist in legacy form behind firewalls, > but I think its deprecation on the public internet will happen a lot > faster than anyone expects. maybe you're right, but... I doubt it. >> I agree that v6 deployments seem to be getting >> better/faster/stronger... I think that's good news, but we'll still be >> paying the v4 piper for a while. > > Only until v4 becomes more expensive (using whatever metric matters to > you) than v6. I have v4, it's not going to be anymore expensive than it is today for me... for new folks sure, but I've got mine. > After you pass that tipping point, v4 deployment will stop dead. doubtful. we could go back and forth with this pingpong ball for ... ever, but the point here is no one knows, it's likely different than either of us think, and in the mean time fun will ensue! -chris > ?- mark > > -- > Mark Newton ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Email: ?newton at internode.com.au (W) > Network Engineer ? ? ? ? ? ? ? ? ? ? ? ? ?Email: ?newton at atdot.dotat.org ?(H) > Internode Pty Ltd ? ? ? ? ? ? ? ? ? ? ? ? Desk: ? +61-8-82282999 > "Network Man" - Anagram of "Mark Newton" ?Mobile: +61-416-202-223 > > > > > > From owen at delong.com Wed Mar 24 02:35:38 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 24 Mar 2010 00:35:38 -0700 Subject: IP4 Space In-Reply-To: <75cb24521003232246q32ea5ccen1e81ef7e91a97946@mail.gmail.com> References: <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> <75cb24521003232246q32ea5ccen1e81ef7e91a97946@mail.gmail.com> Message-ID: > > apples and oranges. > When did novell turn orange? I thought they were red. ;-) >> I'd expect that v4 will still exist in legacy form behind firewalls, >> but I think its deprecation on the public internet will happen a lot >> faster than anyone expects. > > maybe you're right, but... I doubt it. > >>> I agree that v6 deployments seem to be getting >>> better/faster/stronger... I think that's good news, but we'll still be >>> paying the v4 piper for a while. >> >> Only until v4 becomes more expensive (using whatever metric matters to >> you) than v6. > > I have v4, it's not going to be anymore expensive than it is today for > me... for new folks sure, but I've got mine. > If you start deploying IPv6, then, the cost of maintaining duplicate security policies (v4 and v6), duplicate host mappings, duplicate DNS, duplicate configurations on all your routers, etc. does eventually add up, as does the need for even more TCAM. These costs may be trivial in small environments, but, for major enterprises and large backbones, these costs will become significant. An additional not-yet recognized cost of IPv4 will come to light as the various transfer policies start super-fragmenting the address space and our TCAMs begin exploding with new IPv4 routes. Likely there will be scenarios where ISPs need a /16 but they can only find 240 non-aggregable /24s. They'll snap them up and bam... 240 new IPv4 routes. The ARIN transfer policies has some safeguards against this, but, most of the RIRs passed transfer policies without these safeguards. Owen From mir at ripe.net Wed Mar 24 03:24:37 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 24 Mar 2010 09:24:37 +0100 Subject: RIPE Database Query API on RIPE Labs Message-ID: <4BA9CC45.2020508@ripe.net> Dear colleagues, The RIPE NCC implemented a RIPE Database Query API in form of a RESTful Web Service. See a detailed description on RIPE Labs: http://labs.ripe.net/content/ripe-database-api We are curious to find out if this is useful or if you have any suggestions. You can leave comments in the forum on RIPE Labs or send mail directly to me. Kind Regards, Mirjam Kuehne RIPE NCC From bmanning at vacation.karoshi.com Wed Mar 24 04:18:53 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 24 Mar 2010 09:18:53 +0000 Subject: IP4 Space In-Reply-To: References: <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> <75cb24521003232246q32ea5ccen1e81ef7e91a97946@mail.gmail.com> Message-ID: <20100324091853.GB6391@vacation.karoshi.com.> On Wed, Mar 24, 2010 at 12:35:38AM -0700, Owen DeLong wrote: > > > >> Only until v4 becomes more expensive (using whatever metric matters to > >> you) than v6. > > > > I have v4, it's not going to be anymore expensive than it is today for > > me... for new folks sure, but I've got mine. > > > If you start deploying IPv6, then, the cost of maintaining duplicate security > policies (v4 and v6), duplicate host mappings, duplicate DNS, duplicate > configurations on all your routers, etc. does eventually add up, as does the > need for even more TCAM. bingo. to move -from- a single stack system (IPv4) to a dual stack system (v4 & v6) is horrifically expensive. and to justify it based on the eventual cost savings of returning to a single-stack system "someday" might be problematic. one will pay those costs -if- there is an acceptable cost/benefit tradeoff. > These costs may be trivial in small environments, but, for major enterprises > and large backbones, these costs will become significant. > > An additional not-yet recognized cost of IPv4 will come to light as the various > transfer policies start super-fragmenting the address space and our TCAMs > begin exploding with new IPv4 routes. Likely there will be scenarios where > ISPs need a /16 but they can only find 240 non-aggregable /24s. They'll > snap them up and bam... 240 new IPv4 routes. i will note in passing that an ipv6 /32 is the functional equivalent of an ipv4 /32... with the community accepting /48's, we will exceed the potential route injection capability of ipv4. we will potentially have more ipv6 routes than we could have ipv4... simply because we can't get any finer grained in IPv4 than a /32... while we can in IPv6. > The ARIN transfer policies has some safeguards against this, but, most of > the RIRs passed transfer policies without these safeguards. last I checked ARIN transfer policies didn't really talk to routing deaggregation much. in part because ARIN has (to date) almost no leverage on who announces what. > > Owen > From frnkblk at iname.com Wed Mar 24 08:59:38 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Wed, 24 Mar 2010 08:59:38 -0500 Subject: IP4 Space In-Reply-To: <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> References: <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> Message-ID: When we were running AppleTalk and IPX not many of us had corporate access to the internet. I remember those IPX days, and one of the driving reasons to move to IP was to get internet access. I remember adding IP to our Netware 4.x servers. Because IPv4 is the lingua franca of the internet, I don't think we can directly compare it to AppleTalk and IPX. Frank -----Original Message----- From: Mark Newton [mailto:newton at internode.com.au] Sent: Tuesday, March 23, 2010 10:00 PM To: Christopher Morrow Cc: NANOG list Subject: Re: IP4 Space On 24/03/2010, at 4:10 AM, Christopher Morrow wrote: > > it seems to me that we'll have widespread ipv4 for +10 years at least, How many 10 year old pieces of kit do you have on your network? Ten years ago we were routing appletalk and IPX. Still doing that now? Ten years ago companies were still selling ISDN routers which still insisted on classful addressing. Got any of them left on the network? I'd expect that v4 will still exist in legacy form behind firewalls, but I think its deprecation on the public internet will happen a lot faster than anyone expects. > I agree that v6 deployments seem to be getting > better/faster/stronger... I think that's good news, but we'll still be > paying the v4 piper for a while. Only until v4 becomes more expensive (using whatever metric matters to you) than v6. After you pass that tipping point, v4 deployment will stop dead. - mark -- Mark Newton Email: newton at internode.com.au (W) Network Engineer Email: newton at atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 From davei at otd.com Wed Mar 24 09:49:32 2010 From: davei at otd.com (Dave Israel) Date: Wed, 24 Mar 2010 10:49:32 -0400 Subject: IP4 Space In-Reply-To: <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> References: <782A77E3-D21E-4E50-98CA-1CD5A25E7018@academ.com> <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> Message-ID: <4BAA267C.8090007@otd.com> On 3/23/2010 10:59 PM, Mark Newton wrote: > On 24/03/2010, at 4:10 AM, Christopher Morrow wrote: > >> it seems to me that we'll have widespread ipv4 for +10 years at least, >> > How many 10 year old pieces of kit do you have on your network? > Are you kidding? I'm in state education these days. I probably still have one or two 2500 series routers hiding in my network. > Ten years ago we were routing appletalk and IPX. Still doing that > now? > Ten years ago we were routing ipv4, which was going to die of address exhaustion and/or be replaced by ipv6 within two years. Fifteen years ago we were running ipv4, which was going to die of address exhaustion and/or be replaced by OSI within two years. I remember a (telco) engineer, after a presentation on MPLS in the late 90s, saying that it was all very interesting, but all this IP stuff was a fad, and everything was going to be ATM in the near future. > I'd expect that v4 will still exist in legacy form behind firewalls, > but I think its deprecation on the public internet will happen a lot > faster than anyone expects. > You may be right; past experience is not always correct in predicting future behavior. But there has to be a reason why it will be different this time. >> I agree that v6 deployments seem to be getting >> better/faster/stronger... I think that's good news, but we'll still be >> paying the v4 piper for a while. >> > Only until v4 becomes more expensive (using whatever metric matters to > you) than v6. > > After you pass that tipping point, v4 deployment will stop dead. > Sure. But the key phrase is "whatever metric matters to you." You're going to find people whose "expense" metrics are neither dollars nor sense. 1) For some people, that might mean what you think it means: "Hey, to deploy ipv4, we have to pay for this expensive translator box. Lets do v6." 2) On the other hand, there'll be "Hey, we already bought the translator box, because we had an emergency and had to deploy it. So let's stick to v4, because it is what we know." 3) In a lot of places, there will be "Everything I want is v4. v6 is the expensive option, because it means deploying new router software and/or configurations." 4) For others, it will be "I know v4, and not v6. My management knows nothing, and buys what I tell them." 5) Because of groups 2-4, there will be plenty of "Everybody else is still doing v4, and so v4 is what I need to reach them." 6) And finally, there will be a lot of "I need to talk to people in groups 2-5, so I need to deploy v4 regardless." Remember, a new protocol is a lot harder to sell than a new hack that makes the old protocol live longer. And all the protestations of "It can't keep going on like this" ignores history again. Just because we don't *want* NAT to be "fixed" to support more people doesn't make it un"fix"able. If you want v6 deployed, you cannot expect to sit around and wait for everybody to admit you're right; you must make deploying v6 easier/cheaper/less painful than pumping life into v4. -Dave From psirt at cisco.com Wed Mar 24 11:00:00 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Mar 2010 12:00:00 -0400 Subject: Cisco Security Advisory: Cisco IOS Software IPsec Vulnerability Message-ID: <201003241200.ipsec@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software IPsec Vulnerability Advisory ID: cisco-sa-20100324-ipsec Revision 1.0 For Public Release 2010 March 24 1600 UTC (GMT) +--------------------------------------------------------------------- Summary ======= A malformed Internet Key Exchange (IKE) packet may cause a device running Cisco IOS Software to reload. Only Cisco 7200 Series and Cisco 7301 routers running Cisco IOS software with a VPN Acceleration Module 2+ (VAM2+) installed are affected. Cisco has released free software updates that address this vulnerability. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20100324-ipsec.shtml Note: The March 24, 2010, Cisco IOS Software Security Advisory bundled publication includes seven Security Advisories. All the advisories address vulnerabilities in Cisco IOS Software. Each advisory lists the releases that correct the vulnerability or vulnerabilities detailed in the advisory. The table at the following URL lists releases that correct all Cisco IOS Software vulnerabilities that have been published on March 24, 2010, or earlier: http://www.cisco.com/warp/public/707/cisco-sa-20100324-bundle.shtml Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar10.html Affected Products ================= Vulnerable Products +------------------ Only Cisco 7200 Series and Cisco 7301 routers with VPN Acceleration Module 2+ (VAM2+) are affected by this vulnerability. To display a summary of the configuration information for the crypto engines and to determine if a VAM is present and used in the device, use the "show crypto engine brief" command, as shown in the following example: Router#show crypto engine brief crypto engine name: Virtual Private Network (VPN) Module crypto engine type: hardware State: Enabled Location: slot 4 VPN Module in slot: 4 Product Name: VAM2+ Software Serial #: 55AA Device ID: 001F - revision 0000 Vendor ID: 0000 Revision No: 0x001F0000 VSK revision: 0 Boot version: 902 DPU version: 0 HSP version: 3.4(3) (PRODUCTION) Time running: 00:00:10 Compression: Yes DES: Yes 3 DES: Yes AES CBC: Yes (128,192,256) AES CNTR: No Maximum buffer length: 4096 Maximum DH index: 5120 Maximum SA index: 5120 Maximum Flow index: 10230 Note: In the previous example, the "Product Name" VAM2+ is displayed, indicating that the router has the VAM2+ installed. The Enabled keyword under "State" indicates that the VAM2+ is enabled and active. IKE is enabled by default if IPsec is used. Cisco IOS devices that are configured for IKE will listen on UDP port 500, UDP port 4500 if the device is configured for NAT Traversal (NAT-T), or UDP ports 848 or 4848 if the device is configured for Group Domain of Interpretation (GDOI). The following outputs show a router that is listening on UDP port 500: Router#show ip sockets Proto Remote Port Local Port In Out Stat TTY OutputIF .... 17 --listen-- 192.168.66.129 500 0 0 11 0 .... Or Router#show udp Proto Remote Port Local Port In Out Stat TTY OutputIF 17 --listen-- 192.0.2.1 500 0 0 1011 0 17(v6) --listen-- --any-- 500 0 0 20011 0 Router# To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih !--- output truncated The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(20)T with an installed image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/web/about/security/intelligence/ios-ref.html Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS XE and Cisco IOS XR Software are not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= IPsec is an IP security feature that provides robust authentication and encryption of IP packets. IKE is a key management protocol standard that is used with the IPsec standard. IKE is a hybrid protocol that implements the Oakley and SKEME key exchanges inside the Internet Security Association and Key Management Protocol (ISAKMP) framework. (ISAKMP, Oakley, and SKEME are security protocols that are implemented by IKE.). More information on IKE is available at the following link: http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_key_exch_ipsec.html A vulnerability exists in the Cisco IOS Software implementation of IKE where a malformed packet may cause a device running Cisco IOS Software to reload. Only Cisco 7200 Series and Cisco 7301 routers running Cisco IOS software with a VPN Acceleration Module 2+ (VAM2+) installed are affected. This vulnerability is documented in Cisco Bug ID CSCtb13491 and has been assigned CVE ID CVE-2010-0578. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss CSCtb13491 - Malformed IKE packet may cause reload CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability may cause the affected device to reload. Repeated exploitation will result in a denial of service (DoS) condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Bundle First Fixed Release" column indicates the earliest possible releases which have fixes for all the published vulnerabilities in this Cisco IOS Security Advisory bundled publication. Cisco recommends upgrading to the latest available release where possible. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | First Fixed Release for | | 12.0-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.1-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.2-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |------------+---------------------------+--------------------------| | 12.2 | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2B | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2BC | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2BW | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2BX | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2BY | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2BZ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2CX | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2CY | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.2CZ | Not Vulnerable | Vulnerable; migrate to | | | | any release in 12.2SRE | |------------+---------------------------+--------------------------| | 12.2DA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2DD | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2DX | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.2EW | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2EWA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Releases up to and | | | | including 12.2(37)EX are | | | | not vulnerable. | | 12.2EX | Not Vulnerable | | | | | Releases 12.2(44)EX and | | | | later are not | | | | vulnerable; first fixed | | | | in 12.2SE | |------------+---------------------------+--------------------------| | | | Releases prior to 12.2 | | 12.2EY | Not Vulnerable | (37)EY are vulnerable, | | | | release 12.2(37)EY and | | | | later are not vulnerable | |------------+---------------------------+--------------------------| | 12.2EZ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2FX | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2FY | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2FZ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2IRA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SRC | |------------+---------------------------+--------------------------| | 12.2IRB | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SRC | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IRD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXF | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXG | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2IXH | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Releases up to and | | 12.2JA | Not Vulnerable | including 12.2(4)JA1 are | | | | not vulnerable. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2JK | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.2MB | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2MC | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4 | |------------+---------------------------+--------------------------| | 12.2MRA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Releases prior to 12.2 | | | | (30)S are vulnerable, | | 12.2S | Not Vulnerable | release 12.2(30)S and | | | | later are not | | | | vulnerable; | |------------+---------------------------+--------------------------| | | Releases prior to 12.2 | | | | (33)SB5 are vulnerable, | | | | release 12.2(33)SB5 and | 12.2(33)SB8 | | | later are not vulnerable; | | | 12.2SB | migrate to any release in | 12.2(31)SB18; Available | | | 12.2SRE | on 24-MAR-10 | | | | | | | Releases up to 12.2(31) | | | | SB18 are not vulnerable. | | |------------+---------------------------+--------------------------| | 12.2SBC | Not Vulnerable | Vulnerable; migrate to | | | | any release in 12.2SRE | |------------+---------------------------+--------------------------| | 12.2SCA | Vulnerable; first fixed | Vulnerable; first fixed | | | in 12.2SCB | in 12.2SCB | |------------+---------------------------+--------------------------| | 12.2SCB | 12.2(33)SCB6 | 12.2(33)SCB6 | |------------+---------------------------+--------------------------| | 12.2SCC | 12.2(33)SCC1 | 12.2(33)SCC1 | |------------+---------------------------+--------------------------| | 12.2SCD | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2SE | Not Vulnerable | 12.2(50)SE4; Available | | | | on 25-MAR-10 | |------------+---------------------------+--------------------------| | 12.2SEA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2SEB | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2SEC | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2SED | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SE | |------------+---------------------------+--------------------------| | 12.2SEE | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SE | |------------+---------------------------+--------------------------| | 12.2SEF | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Releases prior to 12.2 | | | | (25)SEG4 are vulnerable, | | 12.2SEG | Not Vulnerable | release 12.2(25)SEG4 and | | | | later are not | | | | vulnerable; first fixed | | | | in 12.2SE | |------------+---------------------------+--------------------------| | | | Releases up to 12.2(31) | | | | SG1 are not vulnerable; | | 12.2SG | Not Vulnerable | releases 12.2(40)SG and | | | | later are not | | | | vulnerable. | |------------+---------------------------+--------------------------| | 12.2SGA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2SL | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2SM | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SO | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.2SQ | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | Releases prior to 12.2 | | | | (33)SRA6 are vulnerable, | | | 12.2SRA | release 12.2(33)SRA6 and | Vulnerable; first fixed | | | later are not vulnerable; | in 12.2SRD | | | migrate to any release in | | | | 12.2SRB | | |------------+---------------------------+--------------------------| | 12.2SRB | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SRD | |------------+---------------------------+--------------------------| | 12.2SRC | Not Vulnerable | 12.2(33)SRC5 | |------------+---------------------------+--------------------------| | 12.2SRD | Not Vulnerable | 12.2(33)SRD3 | |------------+---------------------------+--------------------------| | 12.2SRE | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | 12.2STE | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2SU | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Releases up to and | | 12.2SV | Not Vulnerable | including 12.2(18)SV2 | | | | are not vulnerable. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SVA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SVC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SVD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2SVE | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Releases up to and | | | | including 12.2(25)SW3 | | | | are not vulnerable. | | 12.2SW | Not Vulnerable | | | | | Releases 12.2(25)SW12 | | | | and later are not | | | | vulnerable; first fixed | | | | in 15.0M | |------------+---------------------------+--------------------------| | 12.2SX | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SXF | |------------+---------------------------+--------------------------| | 12.2SXA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SXF | |------------+---------------------------+--------------------------| | 12.2SXB | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SXF | |------------+---------------------------+--------------------------| | 12.2SXD | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SXF | |------------+---------------------------+--------------------------| | 12.2SXE | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SXF | |------------+---------------------------+--------------------------| | 12.2SXF | Not Vulnerable | 12.2(18)SXF17a | |------------+---------------------------+--------------------------| | 12.2SXH | Not Vulnerable | 12.2(33)SXH6 | |------------+---------------------------+--------------------------| | | | 12.2(33)SXI2a | | 12.2SXI | Not Vulnerable | | | | | 12.2(33)SXI3 | |------------+---------------------------+--------------------------| | 12.2SY | Not Vulnerable | Vulnerable; migrate to | | | | any release in 12.2SRE | |------------+---------------------------+--------------------------| | 12.2SZ | Not Vulnerable | Vulnerable; migrate to | | | | any release in 12.2SRE | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2T | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2TPC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XA | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XB | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XC | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XD | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.2XE | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XF | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XG | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XH | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XI | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XJ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XK | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XL | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XM | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Releases prior to 12.2 | | | | (33)XN1 are vulnerable, | | 12.2XN | Not Vulnerable | release 12.2(33)XN1 and | | | | later are not | | | | vulnerable; first fixed | | | | in 12.2SRC | |------------+---------------------------+--------------------------| | 12.2XNA | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+--------------------------| | 12.2XNB | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+--------------------------| | 12.2XNC | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+--------------------------| | 12.2XND | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+--------------------------| | 12.2XNE | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+--------------------------| | 12.2XNF | Please see Cisco IOS-XE | Please see Cisco IOS-XE | | | Software Availability | Software Availability | |------------+---------------------------+--------------------------| | 12.2XO | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XQ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XR | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.2XS | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XT | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XU | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XV | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2XW | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2YA | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.2YE | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YF | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YG | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YH | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YJ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.2YK | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2YM | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YN | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YO | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2YP | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YQ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YR | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.2YS | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YT | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YU | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YV | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YW | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YX | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YY | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2YZ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.2ZA | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SXF | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2ZE | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2ZF | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2ZG | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.2ZH | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZJ | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZP | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.2ZU | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SXH | |------------+---------------------------+--------------------------| | 12.2ZX | Not Vulnerable | Vulnerable; migrate to | | | | any release in 12.2SRE | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZY | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.2ZYA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | Affected | | First Fixed Release for | | 12.3-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3 | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3B | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.3BC | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SCB | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3BW | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.3EU | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Releases prior to 12.3 | | 12.3JA | Not Vulnerable | (11)JA5 are vulnerable, | | | | release 12.3(11)JA5 and | | | | later are not vulnerable | |------------+---------------------------+--------------------------| | | | Releases prior to 12.3 | | 12.3JEA | Not Vulnerable | (8)JEA4 are vulnerable, | | | | release 12.3(8)JEA4 and | | | | later are not vulnerable | |------------+---------------------------+--------------------------| | | | Releases prior to 12.3 | | 12.3JEB | Not Vulnerable | (8)JEB2 are vulnerable, | | | | release 12.3(8)JEB2 and | | | | later are not vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3JEC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3JED | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | Releases up to and | | | | including 12.3(2)JK3 are | | | | not vulnerable. | Vulnerable; migrate to | | 12.3JK | | any release in 15.0M or | | | Releases 12.3(8)JK1 and | a fixed 12.4 release. | | | later are not vulnerable; | | | | first fixed in 12.4 | | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3JL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3JX | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3T | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | Releases up to and | support organization per | | 12.3TPC | including 12.3(4)TPC11a | the instructions in | | | are not vulnerable. | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.3VA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XA | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3XB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XC | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XD | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; first fixed | | | Vulnerable; migrate to | in 12.4 | | 12.3XE | any release in 15.0M or a | | | | fixed 12.4 release. | Vulnerable; migrate to | | | | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3XF | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XG | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Releases prior to 12.3 | | 12.3XI | Not Vulnerable | (7)XI11 are vulnerable, | | | | release 12.3(7)XI11 and | | | | later are not vulnerable | |------------+---------------------------+--------------------------| | 12.3XJ | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4XR | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XK | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XL | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XQ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3XR | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XS | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3XU | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.3XW | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4XR | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3XX | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XY | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XZ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YA | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YD | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.3YF | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4XR | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3YG | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YH | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YI | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YJ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Releases prior to 12.3 | Vulnerable; migrate to | | 12.3YK | (11)YK1 are vulnerable, | any release in 15.0M or | | | release 12.3(11)YK1 and | a fixed 12.4 release. | | | later are not vulnerable. | | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YM | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3YQ | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3YS | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YT | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3YU | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.3YX | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4XR | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | Releases up to and | support organization per | | 12.3YZ | including 12.3(11)YZ1 are | the instructions in | | | not vulnerable. | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3ZA | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | Affected | | First Fixed Release for | | 12.4-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |------------+---------------------------+--------------------------| | | 12.4(25b) | | | | | 12.4(25c) | | 12.4 | 15.0(1)M1 | | | | | 15.0(1)M1 | | | 15.0(1)M2 ; Available on | | | | 26-MAR-10 | | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4GC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JDA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JDC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.4JDD | Not Vulnerable | 12.4(10b)JDD1 | |------------+---------------------------+--------------------------| | 12.4JHA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JK | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Releases prior to 12.4 | | 12.4JMA | Not Vulnerable | (3g)JMA2 are vulnerable, | | | | release 12.4(3g)JMA2 and | | | | later are not vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JMB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.4JX | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4JA | |------------+---------------------------+--------------------------| | 12.4MD | Not Vulnerable | 12.4(24)MD | |------------+---------------------------+--------------------------| | 12.4MDA | Not Vulnerable | 12.4(22)MDA2 | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4MR | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4SW | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | 12.4(15)T12 | | | | | | | Releases prior to 12.4 | 12.4(20)T5 | | 12.4T | (15)T are vulnerable, | | | | release 12.4(15)T and | 12.4(24)T3; Available on | | | later are not vulnerable | 26-MAR-10 | | | | | | | | 12.4(22)T4 | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XA | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XB | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XC | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | | | | any release in 15.0M | Vulnerable; migrate to | | 12.4XD | | any release in 15.0M or | | | Vulnerable; migrate to | a fixed 12.4 release. | | | any release in 15.0M or a | | | | fixed 12.4 release. | | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XE | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XF | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XG | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Releases prior to 12.4 | Vulnerable; migrate to | | 12.4XJ | (11)XJ4 are vulnerable, | any release in 15.0M or | | | release 12.4(11)XJ4 and | a fixed 12.4 release. | | | later are not vulnerable | | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XK | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4XL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XM | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4XN | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XP | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XQ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.4XR | Not Vulnerable | 12.4(22)XR3 | |------------+---------------------------+--------------------------| | | Releases prior to 12.4 | Vulnerable; migrate to | | 12.4XT | (11)XJ4 are vulnerable, | any release in 15.0M or | | | release 12.4(11)XJ4 and | a fixed 12.4 release. | | | later are not vulnerable | | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4XV | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XW | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XY | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XZ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4YA | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4YB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4YD | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | 12.4(22)YE2 | | 12.4YE | Not Vulnerable | | | | | 12.4(24)YE | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4YG | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | Affected | | First Fixed Release for | | 15.0-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 15.0 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 15.1-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 15.1 based releases | +-------------------------------------------------------------------+ Cisco IOS-XE Software +-------------------- +-------------------------------------------------------------------+ | IOS-XE Release | First Fixed Release | |----------------------------+--------------------------------------| | 2.1.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.2.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.3.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.4.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.5.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.6.x | Not Vulnerable | +-------------------------------------------------------------------+ Workarounds =========== There are no workarounds available. Obtaining Fixed Software ======================== Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at: http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was found during the resolution of customer service requests. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20100324-ipsec.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +-------------------------------------------------------------------+ | Revision 1.0 | 2010-March-24 | Initial public release | +-------------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at: http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- iD8DBQFLqO4X86n/Gc8U/uARAvMeAKCLz6zc5smzEqvz29iaH2iWvtrd/wCcCGII F9PGfhb2rz3jNVjWPnlhgu8= =K78N -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 24 11:00:00 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Mar 2010 12:00:00 -0400 Subject: Cisco Security Advisory: Cisco IOS Software NAT Skinny Call Control Protocol Vulnerability Message-ID: <201003241200.sccp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software NAT Skinny Call Control Protocol Vulnerability Advisory ID: cisco-sa-20100324-sccp Revision 1.0 For Public Release 2010 March 24 1600 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Skinny Client Control Protocol (SCCP) crafted messages may cause a Cisco IOS device that is configured with the Network Address Translation (NAT) SCCP Fragmentation Support feature to reload. Cisco has released free software updates that address this vulnerability. A workaround that mitigates this vulnerability is available. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20100324-sccp.shtml Note: The March 24, 2010, Cisco IOS Software Security Advisory bundled publication includes seven Security Advisories. All the advisories address vulnerabilities in Cisco IOS Software. Each advisory lists the releases that correct the vulnerability or vulnerabilities detailed in the advisory. The table at the following URL lists releases that correct all Cisco IOS Software vulnerabilities that have been published on March 24, 2010, or earlier: http://www.cisco.com/warp/public/707/cisco-sa-20100324-bundle.shtml Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar10.html Affected Products ================= Vulnerable Products +------------------ This security advisory applies to all Cisco products that run Cisco IOS Software configured for Network Address Translation (NAT) and that support the NAT SCCP Fragmentation Support feature. This feature was first introduced in Cisco IOS Software Release 12.4(6)T. To verify if NAT is enabled on a Cisco IOS device, log into the device and issue the command "show ip nat statistics". The following example shows a device configured with NAT: Router# show ip nat statistics Total translations: 2 (0 static, 2 dynamic; 0 extended) Outside interfaces: Serial0 Inside interfaces: Ethernet1 Hits: 135 Misses: 5 Expired translations: 2 Dynamic mappings: -- Inside Source access-list 1 pool mypool refcount 2 pool mypool: netmask 255.255.255.0 start 192.168.10.1 end 192.168.10.254 type generic, total addresses 14, allocated 2 (14%), misses 0 You can also use the "show running-config | include ip nat" command to verify if NAT has been enabled on the device. In NAT traditional configurations, the term "inside" refers to those networks that will be translated. Inside this domain, hosts will have addresses in one address space, while on the "outside", they will appear to have addresses in another address space when NAT is configured. The first address space is referred to as the local address space and the second is referred to as the global address space. The "ip nat inside" and "ip nat outside" interface commands must be present on the corresponding router interfaces in order for NAT to be enabled. The NAT Virtual Interface (NVI) feature removes the requirement to configure an interface as either NAT inside or NAT outside. If the device is configured for NVI, you can use the show ip nat nvi statistics command in user EXEC or privileged EXEC mode, as shown in the following example. Router# show ip nat nvi statistics Total active translations: 0 (0 static, 0 dynamic; 0 extended) NAT Enabled interfaces: Hits: 0 Misses: 0 CEF Translated packets: 0, CEF Punted packets: 0 Expired translations: 0 Dynamic mappings: -- Inside Source [Id: 1] access-list 1 pool pool1 refcount 1213 pool pool1: netmask 255.255.255.0 start 192.168.1.10 end 192.168.1.253 start 192.168.2.10 end 192.168.2.253 start 192.168.3.10 end 192.168.3.253 start 192.168.4.10 end 192.168.4.253 type generic, total addresses 976, allocated 222 (22%), misses 0 !---output truncated In order to determine the software that is running on a Cisco IOS product, log in to the device and issue the "show version" command to display the system banner. Cisco IOS software identifies itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name displays between parentheses, followed by "Version" and the Cisco IOS release name. Other Cisco devices do not have the show version command or give different output. router>show version Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(6)T2, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by Cisco Systems, Inc. Compiled Tue 16-May-06 16:09 by kellythw !---output truncated Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS XR Software and IOS XE Software are not affected by this vulnerability. Cisco IOS devices not explicitly configured for NAT are not vulnerable. No other Cisco products are currently known to be affected by this vulnerability. Details ======= The Skinny Client Control Protocol (SCCP) enables voice communication between an SCCP client and a Call Manager (CM). Typically, the CM provides service to the SCCP clients on TCP Port 2000 by default. Initially, an SCCP client connects to the CM by establishing a TCP connection; the client will also establish a TCP connection with a secondary CM, if available. The NAT SCCP Fragmentation Support feature enables the Skinny Application Layer Gateway (ALG) to reassemble skinny control messages. Since this feature was introduced in Cisco IOS version 12.4 (6)T, SCCP payloads requiring reassembly and NAT are no longer dropped. A series of crafted SCCP packets may cause a Cisco IOS router that is running the NAT SCCP Fragmentation Support feature to reload. This vulnerability is documented in Cisco Bug ID CSCsy09250 and has been assigned the CVE ID CVE-2010-0584. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss CSCsy09250 - Bus error and crash when crafted packet is sent to device CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability may cause the affected device to reload. Repeated exploitation will result in a denial of service (DoS) condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Bundle First Fixed Release" column indicates the earliest possible releases which have fixes for all the published vulnerabilities in this Cisco IOS Security Advisory bundled publication. Cisco recommends upgrading to the latest available release where possible. +--------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+-------------------------------------------------------| | Affected | | First Fixed Release for | | 12.0-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |--------------------------------------------------------------------| | There are no affected 12.0 based releases | |--------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.1-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |--------------------------------------------------------------------| | There are no affected 12.1 based releases | |--------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.2-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |--------------------------------------------------------------------| | There are no affected 12.2 based releases | |--------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.3-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |--------------------------------------------------------------------| | There are no affected 12.3 based releases | |--------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.4-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |------------+---------------------------+---------------------------| | | | 12.4(25c) | | 12.4 | Not Vulnerable | | | | | 15.0(1)M1 | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4GC | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JDA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JDC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | 12.4JDD | Not Vulnerable | 12.4(10b)JDD1 | |------------+---------------------------+---------------------------| | 12.4JHA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JK | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | | Releases prior to 12.4 | | 12.4JMA | Not Vulnerable | (3g)JMA2 are vulnerable, | | | | release 12.4(3g)JMA2 and | | | | later are not vulnerable | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JMB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | 12.4JX | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4JA | |------------+---------------------------+---------------------------| | 12.4MD | 12.4(11)MD10 | 12.4(24)MD | |------------+---------------------------+---------------------------| | 12.4MDA | 12.4(22)MDA2 | 12.4(22)MDA2 | |------------+---------------------------+---------------------------| | | | Vulnerable; Contact your | | | Releases up to and | support organization per | | 12.4MR | including 12.4(4)MR1 are | the instructions in | | | not vulnerable. | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4SW | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | 12.4(20)T4 | 12.4(15)T12 | | | | | | | 12.4(22)T3 | 12.4(20)T5 | | 12.4T | | | | | 12.4(15)T10 | 12.4(24)T3; Available on | | | | 26-MAR-10 | | | 12.4(24)T2 | | | | | 12.4(22)T4 | |------------+---------------------------+---------------------------| | | | Vulnerable; migrate to | | 12.4XA | Not Vulnerable | any release in 15.0M or a | | | | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | | Vulnerable; migrate to | | 12.4XB | Not Vulnerable | any release in 15.0M or a | | | | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XC | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | | Vulnerable; migrate to | | 12.4XD | Not Vulnerable | any release in 15.0M or a | | | | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XE | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XF | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XG | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XJ | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XK | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XL | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XM | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XN | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XP | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XQ | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | 12.4XR | 12.4(22)XR3 | 12.4(22)XR3 | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XT | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XV | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XW | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XY | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XZ | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4YA | any release in 15.0M or a | any release in 15.0M or a | | | fixed 12.4T release. | fixed 12.4 release. | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4YB | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4YD | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | | | 12.4(22)YE2 | | 12.4YE | 12.4(22)YE2 | | | | | 12.4(24)YE | |------------+---------------------------+---------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4YG | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+---------------------------| | Affected | | First Fixed Release for | | 15.0-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |--------------------------------------------------------------------| | There are no affected 15.0 based releases | |--------------------------------------------------------------------| | Affected | | First Fixed Release for | | 15.1-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |--------------------------------------------------------------------| | There are no affected 15.1 based releases | +--------------------------------------------------------------------+ Cisco IOS-XE Software +-------------------- +-------------------------------------------------------------------+ | IOS-XE Release | First Fixed Release | |----------------------------+--------------------------------------| | 2.1.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.2.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.3.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.4.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.5.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.6.x | Not Vulnerable | +-------------------------------------------------------------------+ Workarounds =========== As workaround, an administrator can disable SCCP NAT support using the "no ip nat service skinny tcp port 2000" command, as shown in the following example: Router(config)# no ip nat service skinny tcp port 2000 Note: If your Cisco CallManager is using a TCP port for skinny signaling different from the default port (2000), you need to adjust this command accordingly. Caution: This workaround is only feasible on networks where SCCP traffic does not need to be processed by NAT. Please confirm before implementing this workaround. Obtaining Fixed Software ======================== Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at: http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was found during the resolution of customer service requests. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20100324-sccp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +-------------------------------------------------------------------+ | Revision 1.0 | 2010-March-24 | Initial public release | +-------------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at: http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- iD8DBQFLqO4X86n/Gc8U/uARArHuAKCNnTQkJtzQiDJ1RY0ERYFGDffpcwCdHruh U/8efv1qDpFghQLXNjqnSIg= =NuJi -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 24 11:00:00 2010 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Mar 2010 12:00:00 -0400 Subject: Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerabilities Message-ID: <201003241200.sip@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerabilities Advisory ID: cisco-sa-20100324-sip Revision 1.0 For Public Release 2010 March 24 1600 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Multiple vulnerabilities exist in the Session Initiation Protocol (SIP) implementation in Cisco IOS Software that could allow an unauthenticated, remote attacker to cause a reload of an affected device when SIP operation is enabled. Remote code execution may also be possible. Cisco has released free software updates that address these vulnerabilities. For devices that must run SIP there are no workarounds; however, mitigations are available to limit exposure of the vulnerabilities. This advisory is posted at: http://www.cisco.com/warp/public/707/cisco-sa-20100324-sip.shtml Note: The March 24, 2010, Cisco IOS Software Security Advisory bundled publication includes seven Security Advisories. All the advisories address vulnerabilities in Cisco IOS Software. Each advisory lists the releases that correct the vulnerability or vulnerabilities detailed in the advisory. The table at the following URL lists releases that correct all Cisco IOS Software vulnerabilities that have been published on March 24, 2010, or earlier: http://www.cisco.com/warp/public/707/cisco-sa-20100324-bundle.shtml Individual publication links are in "Cisco Event Response: Semiannual Cisco IOS Software Security Advisory Bundled Publication" at the following link: http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar10.html Affected Products ================= These vulnerabilities only affect devices running Cisco IOS Software with SIP voice services enabled. Vulnerable Products +------------------ Cisco devices running affected Cisco IOS Software versions that are configured to process SIP messages are affected. Recent versions of Cisco IOS Software do not process SIP messages by default. Creating a dial peer by issuing the command "dial-peer voice" will start the SIP processes, causing the Cisco IOS device to process SIP messages. In addition, several features within Cisco Unified Communications Manager Express, such as ePhones, once configured will also automatically start the SIP process, which will cause the device to start processing SIP messages. An example of an affected configuration follows: dial-peer voice voip ... ! In addition to inspecting the Cisco IOS device configuration for a "dial-peer" command that causes the device to process SIP messages, administrators can also use the command "show processes | include SIP" to determine whether Cisco IOS Software is running the processes that handle SIP messages. In the following example, the presence of the processes "CCSIP_UDP_SOCKET" or "CCSIP_TCP_SOCKET" indicates that the Cisco IOS device will process SIP messages: Router#show processes | include SIP 149 Mwe 40F48254 4 1 400023108/24000 0 CCSIP_UDP_SOCKET 150 Mwe 40F48034 4 1 400023388/24000 0 CCSIP_TCP_SOCKET Warning: Because there are several ways a device running Cisco IOS Software can start processing SIP messages, it is recommended that the "show processes | include SIP" command be used to determine whether the device is processing SIP messages instead of relying on the presence of specific configuration commands. Cisco Unified Border Element images are also affected by these vulnerabilities. Note: The Cisco Unified Border Element feature (previously known as the Cisco Multiservice IP-to-IP Gateway) is a special Cisco IOS Software image that runs on Cisco multiservice gateway platforms. It provides a network-to-network interface point for billing, security, call admission control, quality of service, and signaling interworking. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih !--- output truncated The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(20)T with an installed image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html. Products Confirmed Not Vulnerable +-------------------------------- The SIP Application Layer Gateway (ALG), which is used by the Cisco IOS NAT and firewall features of Cisco IOS Software, is not affected by these vulnerabilities. Cisco IOS XE Software and Cisco IOS XR Software are not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= SIP is a popular signaling protocol that is used to manage voice and video calls across IP networks such as the Internet. SIP is responsible for handling all aspects of call setup and termination. Voice and video are the most popular types of sessions that SIP handles, but the protocol has the flexibility to accommodate other applications that require call setup and termination. SIP call signaling can use UDP (port 5060), TCP (port 5060), or TLS (TCP port 5061) as the underlying transport protocol. Three vulnerabilities exist in the SIP implementation in Cisco IOS Software that may allow a remote attacker to cause a device reload, or execute arbitrary code. These vulnerabilities are triggered when the device running Cisco IOS Software processes malformed SIP messages. In cases where SIP is running over TCP transport, a TCP three-way handshake is necessary to exploit these vulnerabilities. These vulnerabilities are addressed by Cisco bug IDs CSCsz48680, CSCsz89904, and CSCtb93416, and have been assigned Common Vulnerabilities and Exposures (CVE) IDs CVE-2010-0580, CVE-2010-0581, and CVE-2010-0579, respectively. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerabilities in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss CSCsz89904 and CSCtb93416 CVSS Base Score - 10 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 8.3 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsz48680 CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerabilities in this advisory may result in a reload of the device. Repeated exploitation could result in a sustained denial of service condition. There is a potential to execute arbitrary code. In the event of successful remote code execution, device integrity could be completely compromised. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release for this Advisory" column of the table. The "First Fixed Release for all Advisories in 24 March 2010 Bundle Publication" column indicates the earliest possible releases which have fixes for all the published vulnerabilities in this Cisco IOS Security Advisory bundled publication. Cisco recommends upgrading to the latest available release where possible. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | First Fixed Release for | | 12.0-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.1-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.2-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 12.2 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 12.3-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3 | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3B | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.3BC | Not Vulnerable | Vulnerable; first fixed | | | | in 12.2SCB | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3BW | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.3EU | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Releases prior to 12.3 | | 12.3JA | Not Vulnerable | (11)JA5 are vulnerable, | | | | release 12.3(11)JA5 and | | | | later are not vulnerable | |------------+---------------------------+--------------------------| | | | Releases prior to 12.3 | | 12.3JEA | Not Vulnerable | (8)JEA4 are vulnerable, | | | | release 12.3(8)JEA4 and | | | | later are not vulnerable | |------------+---------------------------+--------------------------| | | | Releases prior to 12.3 | | 12.3JEB | Not Vulnerable | (8)JEB2 are vulnerable, | | | | release 12.3(8)JEB2 and | | | | later are not vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3JEC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3JED | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | Releases up to and | | | | including 12.3(2)JK3 are | | | | not vulnerable. | Vulnerable; migrate to | | 12.3JK | | any release in 15.0M or | | | Releases 12.3(8)JK1 and | a fixed 12.4 release. | | | later are not vulnerable; | | | | first fixed in 12.4 | | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3JL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3JX | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | | | | any release in 15.0M or a | Vulnerable; migrate to | | 12.3T | fixed 12.4 release. | any release in 15.0M or | | | Releases up to and | a fixed 12.4 release. | | | including 12.3(4)T11 are | | | | not vulnerable. | | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3TPC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.3VA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XA | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.3XB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XC | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3XD | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; first fixed | | | | in 12.4 | | 12.3XE | Not Vulnerable | | | | | Vulnerable; migrate to | | | | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.3XF | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3XG | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Releases prior to 12.3 | | 12.3XI | any release in 15.0M or a | (7)XI11 are vulnerable, | | | fixed 12.4 release. | release 12.3(7)XI11 and | | | | later are not vulnerable | |------------+---------------------------+--------------------------| | 12.3XJ | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4XR | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3XK | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3XL | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3XQ | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3XR | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XS | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | | | | any release in 15.0M or a | | | | fixed 12.4T release. | Vulnerable; migrate to | | 12.3XU | | any release in 15.0M or | | | Releases up to and | a fixed 12.4 release. | | | including 12.3(8)XU1 are | | | | not vulnerable. | | |------------+---------------------------+--------------------------| | 12.3XW | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4XR | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3XX | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3XY | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3XZ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YA | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YD | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.3YF | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4XR | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3YG | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YH | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YI | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.3YJ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Releases prior to 12.3 | Vulnerable; migrate to | | 12.3YK | (11)YK3 are vulnerable, | any release in 15.0M or | | | release 12.3(11)YK3 and | a fixed 12.4 release. | | | later are not vulnerable; | | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3YM | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3YQ | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | | | | any release in 15.0M or a | | | | fixed 12.4T release. | Vulnerable; migrate to | | 12.3YS | | any release in 15.0M or | | | Releases up to and | a fixed 12.4 release. | | | including 12.3(11)YS1 are | | | | not vulnerable. | | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3YT | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3YU | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | 12.3YX | Vulnerable; migrate to | Vulnerable; first fixed | | | any release in 12.4XN | in 12.4XR | |------------+---------------------------+--------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.3YZ | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.3ZA | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | Affected | | First Fixed Release for | | 12.4-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |------------+---------------------------+--------------------------| | | 12.4(25c) | | | | | 12.4(25c) | | 12.4 | 15.0(1)M1 | | | | | 15.0(1)M1 | | | 15.0(1)M2 ; Available on | | | | 26-MAR-10 | | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | Vulnerable; migrate to | support organization per | | 12.4GC | any release in 15.0M or a | the instructions in | | | fixed 12.4 release. | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JDA | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JDC | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.4JDD | Not Vulnerable | 12.4(10b)JDD1 | |------------+---------------------------+--------------------------| | 12.4JHA | Not Vulnerable | Not Vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JK | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Releases prior to 12.4 | | 12.4JMA | Not Vulnerable | (3g)JMA2 are vulnerable, | | | | release 12.4(3g)JMA2 and | | | | later are not vulnerable | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4JMB | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | 12.4JX | Not Vulnerable | Vulnerable; first fixed | | | | in 12.4JA | |------------+---------------------------+--------------------------| | | 12.4(24)MD | | | | | | | | Releases prior to 12.4 | | | 12.4MD | (22)MD are not | 12.4(24)MD | | | vulnerable; Releases | | | | after 12.4(22)MD1 are not | | | | vulnerable; | | |------------+---------------------------+--------------------------| | 12.4MDA | 12.4(22)MDA2 | 12.4(22)MDA2 | |------------+---------------------------+--------------------------| | | Releases prior to 12.4(9) | Vulnerable; Contact your | | | MR are vulnerable, | support organization per | | 12.4MR | release 12.4(9)MR and | the instructions in | | | later are not vulnerable | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4SW | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | 12.4(15)T12 | | | 12.4(24)T3; Releases | | | | prior to 12.4(24)T3 are | 12.4(20)T5 | | 12.4T | vulnerable, release 12.4 | | | | (24)T3 and later are not | 12.4(24)T3; Available on | | | vulnerable; | 26-MAR-10 | | | | | | | | 12.4(22)T4 | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XA | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XB | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XC | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XD | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XE | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XF | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XG | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XJ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XK | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4XL | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XM | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4XN | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4XP | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XQ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | 12.4(22)XR3; | | | | | | | | Vulnerable; migrate to | | | | any release in 15.0M or a | | | 12.4XR | fixed 12.4T release. | 12.4(22)XR3 | | | | | | | Releases up to and | | | | including 12.4(15)XR8 are | | | | not vulnerable. | | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4XT | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4XV | Not Vulnerable | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XW | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XY | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; migrate to | | 12.4XZ | Not Vulnerable | any release in 15.0M or | | | | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | Vulnerable; migrate to | Vulnerable; migrate to | | 12.4YA | any release in 15.0M or a | any release in 15.0M or | | | fixed 12.4 release. | a fixed 12.4 release. | |------------+---------------------------+--------------------------| | | | Vulnerable; Contact your | | | | support organization per | | 12.4YB | 12.4(22)YB5 | the instructions in | | | | Obtaining Fixed Software | | | | section of this advisory | |------------+---------------------------+--------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4YD | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+--------------------------| | | 12.4(22)YE2 | 12.4(22)YE2 | | 12.4YE | | | | | 12.4(24)YE | 12.4(24)YE | |------------+---------------------------+--------------------------| | | Vulnerable; Contact your | Vulnerable; Contact your | | | support organization per | support organization per | | 12.4YG | the instructions in | the instructions in | | | Obtaining Fixed Software | Obtaining Fixed Software | | | section of this advisory | section of this advisory | |------------+---------------------------+--------------------------| | Affected | | First Fixed Release for | | 15.0-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 15.0 based releases | |-------------------------------------------------------------------| | Affected | | First Fixed Release for | | 15.1-Based | First Fixed Release for | all Advisories in 24 | | Releases | this Advisory | March 2010 Bundle | | | | Publication | |-------------------------------------------------------------------| | There are no affected 15.1 based releases | +-------------------------------------------------------------------+ Cisco IOS-XE Software +-------------------- +-------------------------------------------------------------------+ | IOS-XE Release | First Fixed Release | |----------------------------+--------------------------------------| | 2.1.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.2.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.3.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.4.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.5.x | Not Vulnerable | |----------------------------+--------------------------------------| | 2.6.x | Not Vulnerable | +-------------------------------------------------------------------+ Workarounds =========== If the affected Cisco IOS device requires SIP for VoIP services, SIP cannot be disabled, and no workarounds are available. Users are advised to apply mitigation techniques to help limit exposure to the vulnerabilities. Mitigation consists of allowing only legitimate devices to connect to affected devices. To increase effectiveness, the mitigation must be coupled with anti-spoofing measures on the network edge. This action is required because SIP can use UDP as the transport protocol. Additional mitigations that can be deployed on Cisco devices within the network are available in the companion document "Cisco Applied Mitigation Bulletin: Identifying and Mitigating Exploitation of the Cisco Unified Communications Manager Express and Cisco IOS Software H.323 and Session Initiation Protocol Denial of Service Vulnerabilities", which is available at the following location: http://www.cisco.com/warp/public/707/cisco-amb-20100324-voice.shtml Disable SIP Listening Ports +-------------------------- For devices that do not require SIP to be enabled, the simplest and most effective workaround is to disable SIP processing on the device. Some versions of Cisco IOS Software allow administrators to disable SIP with the following commands: sip-ua no transport udp no transport tcp no transport tcp tls Warning: When applying this workaround to devices that are processing Media Gateway Control Protocol (MGCP) or H.323 calls, the device will not stop SIP processing while active calls are being processed. Under these circumstances, this workaround should be implemented during a maintenance window when active calls can be briefly stopped. The "show udp connections", "show tcp brief all", and "show processes | include SIP" commands can be used to confirm that the SIP UDP and TCP ports are closed after applying this workaround. Depending on the Cisco IOS Software version in use, the output from the "show ip sockets" command may still show the SIP ports open, but sending traffic to them will cause the SIP process to emit the following message: *Feb 2 11:36:47.691: sip_udp_sock_process_read: SIP UDP Listener is DISABLED Control Plane Policing +--------------------- For devices that need to offer SIP services it is possible to use Control Plane Policing (CoPP) to block SIP traffic to the device from untrusted sources. Cisco IOS Releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP may be configured on a device to protect the management and control planes to minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to specific network configurations: !-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted. !-- Everything else is not trusted. The following access list is used !-- to determine what traffic needs to be dropped by a control plane !-- policy (the CoPP feature.) If the access list matches (permit) !-- then traffic will be dropped and if the access list does not !-- match (deny) then traffic will be processed by the router. access-list 100 deny udp 192.168.1.0 0.0.0.255 any eq 5060 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5060 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5061 access-list 100 deny udp host 172.16.1.1 any eq 5060 access-list 100 deny tcp host 172.16.1.1 any eq 5060 access-list 100 deny tcp host 172.16.1.1 any eq 5061 access-list 100 permit udp any any eq 5060 access-list 100 permit tcp any any eq 5060 access-list 100 permit tcp any any eq 5061 !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !-- traffic in accordance with existing security policies and !-- configurations for traffic that is authorized to be sent !-- to infrastructure devices. !-- Create a Class-Map for traffic to be policed by !-- the CoPP feature. class-map match-all drop-sip-class match access-group 100 !-- Create a Policy-Map that will be applied to the !-- Control-Plane of the device. policy-map control-plane-policy class drop-sip-class drop !-- Apply the Policy-Map to the Control-Plane of the !-- device. control-plane service-policy input control-plane-policy Warning: Because SIP can use UDP as a transport protocol, it is possible to easily spoof the IP address of the sender, which may defeat access control lists that permit communication to these ports from trusted IP addresses. In the above CoPP example, the access control entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Additional information on the configuration and use of the CoPP feature can be found at: http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at: http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at: http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to: http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerabilities described in this advisory. The vulnerability addressed by CSCsz48680 was discovered during the resolution of customer service requests. The vulnerabilities addressed by CSCtb93416 and CSCsz89904 were discovered by Cisco during internal testing. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20100324-sip.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +-------------------------------------------------------------------+ | Revision 1.0 | 2010-March-24 | Initial public release | +-------------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at: http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- iD8DBQFLqifP86n/Gc8U/uARAmSTAJ9mz3TsxB4ykZ5wDkmmwhVBytw/CQCfcWhi GlwhypRpbcfyfEhe/zBbIxw= =orFq -----END PGP SIGNATURE----- From fiberoptic at rizon.net Wed Mar 24 12:27:37 2010 From: fiberoptic at rizon.net (fiberOptiC) Date: Wed, 24 Mar 2010 11:27:37 -0600 Subject: Hotmail mail admin Message-ID: <6f7f98121003241027y75f83a24t2067ccdd1a635add@mail.gmail.com> I'm looking for a hotmail mail admin or someone with the information I'm looking for. I have a client that is trying to block the world, but only allow certain ip addresses through. It looks like hotmail uses a large pool of ip addresses for attachments so we've had a hard time determining what ip addresses to allow. My client specifically is requesting this be allowed. Does anyone know what addresses hotmail users for their attachment servers or would a hotmail admin be willing to contact me off list with this information? Thanks! From dhill at mindcry.org Wed Mar 24 13:00:38 2010 From: dhill at mindcry.org (David Hill) Date: Wed, 24 Mar 2010 14:00:38 -0400 Subject: Hotmail mail admin In-Reply-To: <6f7f98121003241027y75f83a24t2067ccdd1a635add@mail.gmail.com> References: <6f7f98121003241027y75f83a24t2067ccdd1a635add@mail.gmail.com> Message-ID: <20100324180038.GA2312@olive.mindcry.lan> On Wed, Mar 24, 2010 at 11:27:37AM -0600, fiberOptiC wrote: > I'm looking for a hotmail mail admin or someone with the information I'm > looking for. > I have a client that is trying to block the world, but only allow certain ip > addresses through. It looks like hotmail uses a large pool of ip addresses > for attachments so we've had a hard time determining what ip addresses to > allow. My client specifically is requesting this be allowed. Does anyone > know what addresses hotmail users for their attachment servers or would a > hotmail admin be willing to contact me off list with this information? > > Thanks! $ host -t txt hotmail.com hotmail.com descriptive text "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all" $ host -t txt spf-a.hotmail.com spf-a.hotmail.com descriptive text "v=spf1 ip4:209.240.192.0/19 ip4:65.52.0.0/14 ip4:131.107.0.0/16 ip4:157.54.0.0/15 ip4:157.56.0.0/14 ip4:157.60.0.0/16 ip4:167.220.0.0/16 ip4:204.79.135.0/24 ip4:204.79.188.0/24 ip4:204.79.252.0/24 ip4:207.46.0.0/16 ip4:199.2.137.0/24 ~all" $ host -t txt spf-b.hotmail.com spf-b.hotmail.com descriptive text "v=spf1 ip4:199.103.90.0/23 ip4:204.182.144.0/24 ip4:204.255.244.0/23 ip4:206.138.168.0/21 ip4:64.4.0.0/18 ip4:65.54.128.0/17 ip4:207.68.128.0/18 ip4:207.68.192.0/20 ip4:207.82.250.0/23 ip4:207.82.252.0/23 ip4:209.1.112.0/23 ~all" $ host -t txt spf-c.hotmail.com spf-c.hotmail.com descriptive text "v=spf1 ip4:209.185.128.0/23 ip4:209.185.130.0/23 ip4:209.185.240.0/22 ip4:216.32.180.0/22 ip4:216.32.240.0/22 ip4:216.33.148.0/22 ip4:216.33.151.0/24 ip4:216.33.236.0/22 ip4:216.33.240.0/22 ip4:216.200.206.0/24 ip4:204.95.96.0/20 ~all" $ host -t txt spf-d.hotmail.com spf-d.hotmail.com descriptive text "v=spf1 ip4:65.59.232.0/23 ip4:65.59.234.0/24 ip4:209.1.15.0/24 ip4:64.41.193.0/24 ip4:216.34.51.0/24 ~all" From jeroen at mompl.net Wed Mar 24 14:31:24 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 24 Mar 2010 12:31:24 -0700 Subject: Earthquakes Message-ID: <4BAA688C.2020406@mompl.net> I saw a recent(-ish) short thread about a mag. 4 quake in the SF Bay Area. This http://earthquake.usgs.gov/earthquakes/recenteqsus/Maps/US2/36.38.-123.-121.php should provide with everything you need to know. I check it on a daily basis and it's been rather quiet the past week or 2 or so. Actually I guess it's been rather quiet ever since the 1989 quake, but then a year or so ago I woke up in the morning from some rattling doors so I guess it all depends on your perspective. So far the "worst" quake ever I experienced was in the Netherlands back around 1988. Magn. 5.2 or something. Which is interesting considering these happen like once every 6 million years or thereabouts ;-) Actually I slept through it so I don't know if one can call it "experiencing". Greetings, Jeroen From ken.gilmour at gmail.com Wed Mar 24 15:12:26 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Wed, 24 Mar 2010 14:12:26 -0600 Subject: Earthquakes In-Reply-To: <4BAA688C.2020406@mompl.net> References: <4BAA688C.2020406@mompl.net> Message-ID: <5b6f80201003241312w5111a55bi8335efd82a82e1c3@mail.gmail.com> We had a 6.2 last year in Costa Rica... We immediately regretted where we had placed our racks and are almost finished a project to move them to a concrete floor (rather than that compressed cardboard stuff). Lost a lot of hard drives that day! We regularly have quakes between the 4-5 region here. By regularly, i mean a minimum of 5 times a year in different parts of the country. Interesting, the epicenter was only a few km (about 30) from the capital city and no communications were knocked out (except within a 6 km radius of the epicenter which was affected more by mud slides knocking things over. Here's what it looked like... http://www.youtube.com/watch?v=F8udXyyqUiw On 24 March 2010 13:31, Jeroen van Aart wrote: > I saw a recent(-ish) short thread about a mag. 4 quake in the SF Bay Area. > This > http://earthquake.usgs.gov/earthquakes/recenteqsus/Maps/US2/36.38.-123.-121.php > should provide with everything you need to know. > > I check it on a daily basis and it's been rather quiet the past week or 2 > or so. Actually I guess it's been rather quiet ever since the 1989 quake, > but then a year or so ago I woke up in the morning from some rattling doors > so I guess it all depends on your perspective. > > So far the "worst" quake ever I experienced was in the Netherlands back > around 1988. Magn. 5.2 or something. Which is interesting considering these > happen like once every 6 million years or thereabouts ;-) > Actually I slept through it so I don't know if one can call it > "experiencing". > > Greetings, > Jeroen > > From leah.lynch at clearwire.com Wed Mar 24 15:17:17 2010 From: leah.lynch at clearwire.com (Leah Lynch (Contractor)) Date: Wed, 24 Mar 2010 13:17:17 -0700 Subject: Earthquakes In-Reply-To: <5b6f80201003241312w5111a55bi8335efd82a82e1c3@mail.gmail.com> References: <4BAA688C.2020406@mompl.net> <5b6f80201003241312w5111a55bi8335efd82a82e1c3@mail.gmail.com> Message-ID: <7289FBE3BD07AB4A9D04D466715138FFF71A70@corexchange8.corp.clearwire.com> When I lived in the Bay Area, I noticed that 4.x quakes only tended to shake the room ever-so-slightly. You could only really tell if they happened, if you happened to see liquid in a glass moving. Leah -----Original Message----- From: Ken Gilmour [mailto:ken.gilmour at gmail.com] Sent: Wednesday, March 24, 2010 1:12 PM To: Jeroen van Aart Cc: NANOG list Subject: Re: Earthquakes We had a 6.2 last year in Costa Rica... We immediately regretted where we had placed our racks and are almost finished a project to move them to a concrete floor (rather than that compressed cardboard stuff). Lost a lot of hard drives that day! We regularly have quakes between the 4-5 region here. By regularly, i mean a minimum of 5 times a year in different parts of the country. Interesting, the epicenter was only a few km (about 30) from the capital city and no communications were knocked out (except within a 6 km radius of the epicenter which was affected more by mud slides knocking things over. Here's what it looked like... http://www.youtube.com/watch?v=F8udXyyqUiw On 24 March 2010 13:31, Jeroen van Aart wrote: > I saw a recent(-ish) short thread about a mag. 4 quake in the SF Bay Area. > This > http://earthquake.usgs.gov/earthquakes/recenteqsus/Maps/US2/36.38.-123.- 121.php > should provide with everything you need to know. > > I check it on a daily basis and it's been rather quiet the past week or 2 > or so. Actually I guess it's been rather quiet ever since the 1989 quake, > but then a year or so ago I woke up in the morning from some rattling doors > so I guess it all depends on your perspective. > > So far the "worst" quake ever I experienced was in the Netherlands back > around 1988. Magn. 5.2 or something. Which is interesting considering these > happen like once every 6 million years or thereabouts ;-) > Actually I slept through it so I don't know if one can call it > "experiencing". > > Greetings, > Jeroen > > This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. From owen at delong.com Wed Mar 24 15:20:27 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 24 Mar 2010 13:20:27 -0700 Subject: Earthquakes In-Reply-To: <4BAA688C.2020406@mompl.net> References: <4BAA688C.2020406@mompl.net> Message-ID: <3FAF6448-8D74-4108-B331-FAD8A74B76AC@delong.com> In California, 4s are a regular occurrence and we have 2-3s every day. I rarely notice anything less than a 5, and, often do not notice up to a 5.5 in my area. The worst quake I have personally experienced was the 1989 Loma Prietta quake which was a 7.9 IIRC. It caused some significant damage to some substandard (by modern measure, not when they were built) structures, most notably the bay bridge and the cypress and embarcadero elevated freeways and a brick-and-morter (literally) mall in Santa Cruz. Other than that, the damage from the 7.9 was minimal outside of a relatively contained zone rather close to the epicenter. I've been through more than one quake in the 5.2-5.5 range, so, perhaps they are rare in the Netherlands (6 million years or so), but, in California they are much more frequent, perhaps 5-7 years or so. Owen On Mar 24, 2010, at 12:31 PM, Jeroen van Aart wrote: > I saw a recent(-ish) short thread about a mag. 4 quake in the SF Bay Area. This http://earthquake.usgs.gov/earthquakes/recenteqsus/Maps/US2/36.38.-123.-121.php > should provide with everything you need to know. > > I check it on a daily basis and it's been rather quiet the past week or 2 or so. Actually I guess it's been rather quiet ever since the 1989 quake, but then a year or so ago I woke up in the morning from some rattling doors so I guess it all depends on your perspective. > > So far the "worst" quake ever I experienced was in the Netherlands back around 1988. Magn. 5.2 or something. Which is interesting considering these happen like once every 6 million years or thereabouts ;-) > Actually I slept through it so I don't know if one can call it "experiencing". > > Greetings, > Jeroen From jbfixurpc at gmail.com Wed Mar 24 15:30:04 2010 From: jbfixurpc at gmail.com (Joe) Date: Wed, 24 Mar 2010 16:30:04 -0400 Subject: Earthquakes In-Reply-To: <7289FBE3BD07AB4A9D04D466715138FFF71A70@corexchange8.corp.clearwire.com> Message-ID: <000801cacb90$ca742960$4401a8c0@jgbpc> When I was living in San Jose/Sunnyvale and we had a 5.2 in 2001? (can't remember the date, was a bit ago). The only effect I felt from it was as if someone had taken the back of my chair and pushed it forward, that was about it. Of course at the same time there was a large Earthquake in Turkey being broadcast on the News, so thought it was just me, but when it came on the news a few minutes later.... Since than I believe there have been several 5.0+ in that area, obviously none have been as significant as the one in 1988, but I think its only a matter of time till a large one occurs. Regards, -Joe Blanchard From mike at mtcc.com Wed Mar 24 15:32:49 2010 From: mike at mtcc.com (Michael Thomas) Date: Wed, 24 Mar 2010 13:32:49 -0700 Subject: Earthquakes In-Reply-To: <3FAF6448-8D74-4108-B331-FAD8A74B76AC@delong.com> References: <4BAA688C.2020406@mompl.net> <3FAF6448-8D74-4108-B331-FAD8A74B76AC@delong.com> Message-ID: <4BAA76F1.8000400@mtcc.com> Something to keep in mind is that raw magnitude isn't the whole story. The ground composition is *much* more important when it comes to destructiveness. A 5.0 earthquake in the Netherlands might be extremely damaging because of liquifaction. Also: California since we get quakes all the time, our rock is more "shattered" which damps the seismic waves. Back east, on the other hand, the bedrock is more solid which is why the New Madrid earthquakes traveled so far (ringing bells in Boston, IIRC). Of course New Madrid were huge earthquakes by any standard. Mike On 03/24/2010 01:20 PM, Owen DeLong wrote: > In California, 4s are a regular occurrence and we have 2-3s every day. > > I rarely notice anything less than a 5, and, often do not notice up to a 5.5 in my area. > > The worst quake I have personally experienced was the 1989 Loma Prietta quake > which was a 7.9 IIRC. It caused some significant damage to some substandard > (by modern measure, not when they were built) structures, most notably the bay > bridge and the cypress and embarcadero elevated freeways and a brick-and-morter > (literally) mall in Santa Cruz. Other than that, the damage from the 7.9 was minimal > outside of a relatively contained zone rather close to the epicenter. > > I've been through more than one quake in the 5.2-5.5 range, so, perhaps they are > rare in the Netherlands (6 million years or so), but, in California they are much more > frequent, perhaps 5-7 years or so. > > Owen > > On Mar 24, 2010, at 12:31 PM, Jeroen van Aart wrote: > >> I saw a recent(-ish) short thread about a mag. 4 quake in the SF Bay Area. This http://earthquake.usgs.gov/earthquakes/recenteqsus/Maps/US2/36.38.-123.-121.php >> should provide with everything you need to know. >> >> I check it on a daily basis and it's been rather quiet the past week or 2 or so. Actually I guess it's been rather quiet ever since the 1989 quake, but then a year or so ago I woke up in the morning from some rattling doors so I guess it all depends on your perspective. >> >> So far the "worst" quake ever I experienced was in the Netherlands back around 1988. Magn. 5.2 or something. Which is interesting considering these happen like once every 6 million years or thereabouts ;-) >> Actually I slept through it so I don't know if one can call it "experiencing". >> >> Greetings, >> Jeroen > From joe at via.net Wed Mar 24 15:33:53 2010 From: joe at via.net (joe mcguckin) Date: Wed, 24 Mar 2010 13:33:53 -0700 Subject: NEED ANY LINK OR SAMPLE TEMPLATE FOR ROUTINE NETWORK (ISP) In-Reply-To: References: <201003170122.o2H1M2un098425@aurora.sol.net> Message-ID: <0363665C-6913-444A-BF23-8D980DACBC8A@via.net> Folks, Since the last internet cleaning day, we've discovered that straightening the ethernet cables as much as possible, eliminating unnecessary bends and kinks significantly speeds up the network. Also, taking a cue from my sports car, we've contracted with a supplier to make all our new cabling with steel braided sheathing on the exterior. Now, if I could only figure out how to install a Cooler Master CPU cooler on my AGS+ core router... Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax On Mar 16, 2010, at 6:34 PM, Ingo Flaschberger wrote: > > and never forget to check the circuit breakers for good grounding, > prefered use an etherkill(tm) cable - but be aware, that there is currently no such cable available for fiber optics. > > If you are unshure if your fiber cables are properly grounded try to use > an optical isolation transformer. > > Kind regards, > ingo flaschberger From wavetossed at googlemail.com Wed Mar 24 16:24:39 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 24 Mar 2010 21:24:39 +0000 Subject: IP4 Space In-Reply-To: <20100324031611.GB4441@vacation.karoshi.com.> References: <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> <20100324031611.GB4441@vacation.karoshi.com.> Message-ID: <877585b01003241424y63c9e63bh1883cbe61c52eacc@mail.gmail.com> > ? ? ? ?when will you turn off -all- IPv4 in your network? > ? ? ? ?no snmp/aaa, no syslog, no radius, no licensed s/w keyed to a v4 address, > ? ? ? ?no need to keep logs for leos' (whats the data retention law in your jurisdiction?) > ? ? ? ?etc... The same day that we stop using RS-232C point-to-point protocol devices. The day that IPv4 is turned off, is not an interesting date. What *IS* interesting is when IPv4 disappears into the woodwork and is only used inside boxes and on internal management networks. For comparison look at the z-80 CPU which powered the early desktop computers. When the IBM PC came out, people thought that the Intel 8086 would make the Z-80 obsolete. But it didn't. The Z-80 just disappeared into all sorts of electronic devices where it serves as a controller for some function, perhaps the video display or the disk drive servos. And you can still buy them. Here is a development kit in case you want to use Z-80s in new devices: The same thing will happen to IPv4. In a hundred years some engineer will be surprised to discover that IPv4 is running inside residential HVAC systems, carrying messages from thermostats and temperature sensors to the heating system, the air conditioners, and the ground heat exchangers. But within 10 years, IPv4 will no longer be doing the heavy-lifting in carrying packets across the public Internet, and that is what counts for most of us. --Michael Dillon P.S. If you are in the market for a buggy whip, here is a list of manufacturers/sellers as well as some advice on choosing the whip. From jeroen at mompl.net Wed Mar 24 17:32:14 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 24 Mar 2010 15:32:14 -0700 Subject: Earthquakes In-Reply-To: <3FAF6448-8D74-4108-B331-FAD8A74B76AC@delong.com> References: <4BAA688C.2020406@mompl.net> <3FAF6448-8D74-4108-B331-FAD8A74B76AC@delong.com> Message-ID: <4BAA92EE.5010309@mompl.net> Owen DeLong wrote: > I've been through more than one quake in the 5.2-5.5 range, so, perhaps they are > rare in the Netherlands (6 million years or so), but, in California they are much more > frequent, perhaps 5-7 years or so. Well, 6 million years was a "slight" exaggeration to get a point across. The Netherlands doesn't really have any quakes due to faultlines (there aren't any). But it does have the occasional quake due to coal/gas mining. Where the ground compacts or something like it. From jhorstman at adknowledge.com Wed Mar 24 17:33:08 2010 From: jhorstman at adknowledge.com (Justin Horstman) Date: Wed, 24 Mar 2010 17:33:08 -0500 Subject: Experiences with A10 AX series Load Balancers? In-Reply-To: References: Message-ID: The boxes do alright at low load levels. They do not have an asic tech like the F5s so choke on large amounts of traffic. Management is a bit immature and you will find yourself having to use the CLI and the Gui to accomplish most advanced tasks. When we put them head to head A10 AX3200 vs F5 6400 ltm (note: 6400 was what we were looking to replace) Test: 1000 concurrent users from Gomez's Networks Loadtesting platform hitting as fast as the requests would close, going through our standard vip config on the f5, and the A10 engineering teams 3 best efforts to beat that config that balanced between two Identical Dell 1950 servers serving a php page that responded with a random number (to avoid caching). The 6400 we used was in production at the time, and was older so we were expecting to get blown away, see the results here: F5 - Peaked 160k completed transactions a minute sustained for 10 minutes, 0 errors, 112ms average transaction response time A10 - Held 60k completed transactions a minute sustained for 10 minutes, 0 errors, 360ms average transaction response time If anyone is interested in the graphs I think I can still pull them out of gomez. Though notable that this was all done a year ago, so things might be different now. ~J -----Original Message----- From: Welch, Bryan [mailto:Bryan.Welch at arrisi.com] Sent: Tuesday, March 23, 2010 8:35 PM To: nanog at nanog.org Subject: Experiences with A10 AX series Load Balancers? Does anyone have any experiences good/bad/indifferent with this company and their products? They claim 2x the performance at ? the cost and am a bit leery as you can imagine. We are looking to replace our aging F5 BigIP LTM's and will be evaluating these along with the Netscaler and new generation F5 boxes. Regards, Bryan From jeroen at mompl.net Wed Mar 24 17:35:31 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 24 Mar 2010 15:35:31 -0700 Subject: Earthquakes In-Reply-To: <4BAA76F1.8000400@mtcc.com> References: <4BAA688C.2020406@mompl.net> <3FAF6448-8D74-4108-B331-FAD8A74B76AC@delong.com> <4BAA76F1.8000400@mtcc.com> Message-ID: <4BAA93B3.1000901@mompl.net> Michael Thomas wrote: > Something to keep in mind is that raw magnitude isn't the whole story. The > ground composition is *much* more important when it comes to > destructiveness. > A 5.0 earthquake in the Netherlands might be extremely damaging because of > liquifaction. Yes the one I mentioned from the late 80s damaged buildings quite a bit around the epi centre in the SE. That would be damage such as falling roof tiles and cracks in walls. But then the Dutch do build a lot with brick and mortar. That's a big no no in places like California. From owen at delong.com Wed Mar 24 17:47:58 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 24 Mar 2010 15:47:58 -0700 Subject: Earthquakes In-Reply-To: <4BAA92EE.5010309@mompl.net> References: <4BAA688C.2020406@mompl.net> <3FAF6448-8D74-4108-B331-FAD8A74B76AC@delong.com> <4BAA92EE.5010309@mompl.net> Message-ID: On Mar 24, 2010, at 3:32 PM, Jeroen van Aart wrote: > Owen DeLong wrote: >> I've been through more than one quake in the 5.2-5.5 range, so, perhaps they are >> rare in the Netherlands (6 million years or so), but, in California they are much more >> frequent, perhaps 5-7 years or so. > > Well, 6 million years was a "slight" exaggeration to get a point across. The Netherlands doesn't really have any quakes due to faultlines (there aren't any). But it does have the occasional quake due to coal/gas mining. Where the ground compacts or something like it. LOL @ NL creating artificial earthquake faults because they're Jealous of California's natural seismic events. ;-) Owen From mark at streamservice.nl Wed Mar 24 18:00:16 2010 From: mark at streamservice.nl (Mark Scholten) Date: Thu, 25 Mar 2010 00:00:16 +0100 Subject: Earthquakes In-Reply-To: References: <4BAA688C.2020406@mompl.net> <3FAF6448-8D74-4108-B331-FAD8A74B76AC@delong.com> <4BAA92EE.5010309@mompl.net> Message-ID: <027001cacba5$c5461fb0$4fd25f10$@nl> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, March 24, 2010 11:48 PM > To: Jeroen van Aart > Cc: NANOG list > Subject: Re: Earthquakes > > > On Mar 24, 2010, at 3:32 PM, Jeroen van Aart wrote: > > > Owen DeLong wrote: > >> I've been through more than one quake in the 5.2-5.5 range, so, > perhaps they are > >> rare in the Netherlands (6 million years or so), but, in California > they are much more > >> frequent, perhaps 5-7 years or so. > > > > Well, 6 million years was a "slight" exaggeration to get a point > across. The Netherlands doesn't really have any quakes due to > faultlines (there aren't any). But it does have the occasional quake > due to coal/gas mining. Where the ground compacts or something like it. > > LOL @ NL creating artificial earthquake faults because they're Jealous > of California's natural seismic events. ;-) Sorry for being jealous ;) At least we create them and in California they just happen. Mark From jabley at hopcount.ca Wed Mar 24 19:14:12 2010 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 24 Mar 2010 17:14:12 -0700 Subject: Earthquakes In-Reply-To: <5b6f80201003241312w5111a55bi8335efd82a82e1c3@mail.gmail.com> References: <4BAA688C.2020406@mompl.net> <5b6f80201003241312w5111a55bi8335efd82a82e1c3@mail.gmail.com> Message-ID: <69CB2FCE-3D0E-44FE-93F4-8F3776DAD18D@hopcount.ca> On 2010-03-24, at 13:12, Ken Gilmour wrote: > We had a 6.2 last year in Costa Rica... We immediately regretted where we > had placed our racks and are almost finished a project to move them to a > concrete floor (rather than that compressed cardboard stuff). Lost a lot of > hard drives that day! We regularly have quakes between the 4-5 region here. > By regularly, i mean a minimum of 5 times a year in different parts of the > country. If there is interest in data centre provisioning or construction, disaster planning or inside/outside plant strategies intended to mitigate damage by earthquakes then the NZNOG list might well be a good English-language place to get some advice. Earthquakes of magnitude 4 and up happen pretty regularly (several times per week is common). http://www.geonet.org.nz/earthquake/quakes/recent_quakes.html http://www.nznog.org/ Joe From rocca at start.ca Wed Mar 24 19:19:54 2010 From: rocca at start.ca (Peter Rocca) Date: Wed, 24 Mar 2010 20:19:54 -0400 Subject: Cogeco Contact...? Message-ID: Can someone from the Cogeco NOC please contact me off-list at roccap2005 at yahoo.com? I have tried ipservices at cogeco.net and 1-905-333-7055 without luck. Thank you. From rocca at start.ca Wed Mar 24 19:34:52 2010 From: rocca at start.ca (Peter Rocca) Date: Wed, 24 Mar 2010 20:34:52 -0400 Subject: Cogeco Contact...? In-Reply-To: References: Message-ID: Thanks all, success. -----Original Message----- From: Peter Rocca [mailto:rocca at start.ca] Sent: March 24, 2010 8:20 PM To: nanog at nanog.org Subject: Cogeco Contact...? Can someone from the Cogeco NOC please contact me off-list at roccap2005 at yahoo.com? I have tried ipservices at cogeco.net and 1-905-333-7055 without luck. Thank you. From darren at bolding.org Wed Mar 24 20:46:27 2010 From: darren at bolding.org (Darren Bolding) Date: Wed, 24 Mar 2010 18:46:27 -0700 Subject: Experiences with A10 AX series Load Balancers? In-Reply-To: References: Message-ID: <5a318d411003241846ue709334icce03515da414d3e@mail.gmail.com> Very interesting to see about A10's performance- I've heard mixed things about them. Just an FYI, the newer F5 platforms don't utilize the ASIC's- the performance curve of general-purpose CPU's has once again eclipsed what can be done with specialized silicon without aggressive (and expensive) revision cycles. The ASIC's also could only be used in simpler virtual server configurations and with certain subsets of iRules. That said, nothing else I'm aware of provides the functionality of iRules. I've used netscalers only a relatively small amount- and they are nice- particularly if your requirements are within their feature set- but my experience has been that things I take for granted using an iRule are seriously painful to implement on a netscaler. --D On Wed, Mar 24, 2010 at 3:33 PM, Justin Horstman wrote: > The boxes do alright at low load levels. They do not have an asic tech like > the F5s so choke on large amounts of traffic. Management is a bit immature > and you will find yourself having to use the CLI and the Gui to accomplish > most advanced tasks. > > When we put them head to head A10 AX3200 vs F5 6400 ltm (note: 6400 was > what we were looking to replace) > > Test: > 1000 concurrent users from Gomez's Networks Loadtesting platform hitting as > fast as the requests would close, going through our standard vip config on > the f5, and the A10 engineering teams 3 best efforts to beat that config > that balanced between two Identical Dell 1950 servers serving a php page > that responded with a random number (to avoid caching). The 6400 we used was > in production at the time, and was older so we were expecting to get blown > away, see the results here: > > F5 - Peaked 160k completed transactions a minute sustained for 10 minutes, > 0 errors, 112ms average transaction response time > A10 - Held 60k completed transactions a minute sustained for 10 minutes, 0 > errors, 360ms average transaction response time > > If anyone is interested in the graphs I think I can still pull them out of > gomez. Though notable that this was all done a year ago, so things might be > different now. > > ~J > > > -----Original Message----- > From: Welch, Bryan [mailto:Bryan.Welch at arrisi.com] > Sent: Tuesday, March 23, 2010 8:35 PM > To: nanog at nanog.org > Subject: Experiences with A10 AX series Load Balancers? > > Does anyone have any experiences good/bad/indifferent with this company and > their products? They claim 2x the performance at ? the cost and am a bit > leery as you can imagine. > > We are looking to replace our aging F5 BigIP LTM's and will be evaluating > these along with the Netscaler and new generation F5 boxes. > > > > > Regards, > > Bryan > > > -- -- Darren Bolding -- -- darren at bolding.org -- From Bryan.Welch at arrisi.com Wed Mar 24 20:50:42 2010 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Wed, 24 Mar 2010 18:50:42 -0700 Subject: Experiences with A10 AX series Load Balancers? In-Reply-To: <5a318d411003241846ue709334icce03515da414d3e@mail.gmail.com> References: <5a318d411003241846ue709334icce03515da414d3e@mail.gmail.com> Message-ID: Yes, agreed. I think the Netscaler falls into the category of the Cisco in this respect . Seems the F5 gear is the 1000lb gorilla in this category and for the most part we have no reason to look anywhere else other than doing our own due diligence with respect to the other vendor offerings in this space. Regards, Bryan From: packetmonger at gmail.com [mailto:packetmonger at gmail.com] On Behalf Of Darren Bolding Sent: Wednesday, March 24, 2010 6:46 PM To: Justin Horstman Cc: Welch, Bryan; nanog at nanog.org Subject: Re: Experiences with A10 AX series Load Balancers? Very interesting to see about A10's performance- I've heard mixed things about them. Just an FYI, the newer F5 platforms don't utilize the ASIC's- the performance curve of general-purpose CPU's has once again eclipsed what can be done with specialized silicon without aggressive (and expensive) revision cycles. The ASIC's also could only be used in simpler virtual server configurations and with certain subsets of iRules. That said, nothing else I'm aware of provides the functionality of iRules. I've used netscalers only a relatively small amount- and they are nice- particularly if your requirements are within their feature set- but my experience has been that things I take for granted using an iRule are seriously painful to implement on a netscaler. --D On Wed, Mar 24, 2010 at 3:33 PM, Justin Horstman > wrote: The boxes do alright at low load levels. They do not have an asic tech like the F5s so choke on large amounts of traffic. Management is a bit immature and you will find yourself having to use the CLI and the Gui to accomplish most advanced tasks. When we put them head to head A10 AX3200 vs F5 6400 ltm (note: 6400 was what we were looking to replace) Test: 1000 concurrent users from Gomez's Networks Loadtesting platform hitting as fast as the requests would close, going through our standard vip config on the f5, and the A10 engineering teams 3 best efforts to beat that config that balanced between two Identical Dell 1950 servers serving a php page that responded with a random number (to avoid caching). The 6400 we used was in production at the time, and was older so we were expecting to get blown away, see the results here: F5 - Peaked 160k completed transactions a minute sustained for 10 minutes, 0 errors, 112ms average transaction response time A10 - Held 60k completed transactions a minute sustained for 10 minutes, 0 errors, 360ms average transaction response time If anyone is interested in the graphs I think I can still pull them out of gomez. Though notable that this was all done a year ago, so things might be different now. ~J -----Original Message----- From: Welch, Bryan [mailto:Bryan.Welch at arrisi.com] Sent: Tuesday, March 23, 2010 8:35 PM To: nanog at nanog.org Subject: Experiences with A10 AX series Load Balancers? Does anyone have any experiences good/bad/indifferent with this company and their products? They claim 2x the performance at ? the cost and am a bit leery as you can imagine. We are looking to replace our aging F5 BigIP LTM's and will be evaluating these along with the Netscaler and new generation F5 boxes. Regards, Bryan -- -- Darren Bolding -- -- darren at bolding.org -- From nonobvious at gmail.com Wed Mar 24 21:14:48 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Wed, 24 Mar 2010 19:14:48 -0700 Subject: IP4 Space In-Reply-To: <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> References: <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> Message-ID: <18a5e7cb1003241914j5f57a64dk5d7f279e25abd525@mail.gmail.com> >> it seems to me that we'll have widespread ipv4 for +10 years at least, > How many 10 year old pieces of kit do you have on your network? > Ten years ago we were routing appletalk and IPX. ?Still doing that now? Ten years ago I was still telling a few customers that Novell Netware had supported TCP/IP since the early 90s and it was really time to shut off IPX, and the Appletalk users were at least running over IP, not LocalTalk, so I didn't have to care much, and the Windows people were probably already arguing about Active Directory and LDAP and whether to do DNS, DLSW was Not Dead Yet, and 1/3 of my X.25 customers acknowledged that it was way obsolete and time to join the 1990s (the other two were state governments who viewed it as Somebody Else's Emulation Problem.) The last time I was dealing with high-end Layer 1 access problems was a couple of years ago, but in addition to normal IPv4 and MPLS, I had customers running Fiber Channel and other SAN protocols on the WAN. There'll be enough IPv4 to keep antiques dealers in business for a while yet. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From smb at cs.columbia.edu Wed Mar 24 21:44:03 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 24 Mar 2010 22:44:03 -0400 Subject: IP4 Space In-Reply-To: <18a5e7cb1003241914j5f57a64dk5d7f279e25abd525@mail.gmail.com> References: <5F1787CD-3F1D-481A-86F7-4310C8559797@academ.com> <2DC364E3-EC9C-405C-8463-BC6935A09EC4@senie.com> <330AC06A-2719-4159-A7C9-EB13FFB2B13B@delong.com> <290C0D04-9161-4AF6-898B-FCD795556539@internode.com.au> <3c3e3fca1003230517s1454dfb6vc7b72e85fe431f52@mail.gmail.com> <75cb24521003231040m6006b254y4c4043de8540e1d3@mail.gmail.com> <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> <18a5e7cb1003241914j5f57a64dk5d7f279e25abd525@mail.gmail.com> Message-ID: On Mar 24, 2010, at 10:14 PM, Bill Stewart wrote: >>> it seems to me that we'll have widespread ipv4 for +10 years at least, >> How many 10 year old pieces of kit do you have on your network? >> Ten years ago we were routing appletalk and IPX. Still doing that now? > > Ten years ago I was still telling a few customers that Novell Netware had > supported TCP/IP since the early 90s and it was really time to shut off IPX, > and the Appletalk users were at least running over IP, not LocalTalk, > so I didn't have to care much, and the Windows people were probably > already arguing about Active Directory and LDAP and whether to do DNS, > DLSW was Not Dead Yet, and 1/3 of my X.25 customers acknowledged > that it was way obsolete and time to join the 1990s (the other two were > state governments who viewed it as Somebody Else's Emulation Problem.) > > The last time I was dealing with high-end Layer 1 access problems was > a couple of years ago, but in addition to normal IPv4 and MPLS, > I had customers running Fiber Channel and other SAN protocols on the WAN. > > There'll be enough IPv4 to keep antiques dealers in business for a while yet. As of (at least) 2002, the FBI was still using bisync for communications. If you're a data communications professional and haven't heard of bisync, that proves my point... I suspect that some members of this list weren't born by the time it was considered obsolete. --Steve Bellovin, http://www.cs.columbia.edu/~smb From ck at sandcastl.es Wed Mar 24 22:06:39 2010 From: ck at sandcastl.es (ck) Date: Wed, 24 Mar 2010 20:06:39 -0700 Subject: Experiences with A10 AX series Load Balancers? In-Reply-To: References: Message-ID: <8c308e8b1003242006p15fe6acdr21931f67b7a84057@mail.gmail.com> the a10s actually do pretty good at relatively high load levels as well, and they do have an asic(multiple), fyi.. On Wed, Mar 24, 2010 at 3:33 PM, Justin Horstman wrote: > The boxes do alright at low load levels. They do not have an asic tech like > the F5s so choke on large amounts of traffic. Management is a bit immature > and you will find yourself having to use the CLI and the Gui to accomplish > most advanced tasks. > > When we put them head to head A10 AX3200 vs F5 6400 ltm (note: 6400 was > what we were looking to replace) > > Test: > 1000 concurrent users from Gomez's Networks Loadtesting platform hitting as > fast as the requests would close, going through our standard vip config on > the f5, and the A10 engineering teams 3 best efforts to beat that config > that balanced between two Identical Dell 1950 servers serving a php page > that responded with a random number (to avoid caching). The 6400 we used was > in production at the time, and was older so we were expecting to get blown > away, see the results here: > > F5 - Peaked 160k completed transactions a minute sustained for 10 minutes, > 0 errors, 112ms average transaction response time > A10 - Held 60k completed transactions a minute sustained for 10 minutes, 0 > errors, 360ms average transaction response time > > If anyone is interested in the graphs I think I can still pull them out of > gomez. Though notable that this was all done a year ago, so things might be > different now. > > ~J > > > -----Original Message----- > From: Welch, Bryan [mailto:Bryan.Welch at arrisi.com] > Sent: Tuesday, March 23, 2010 8:35 PM > To: nanog at nanog.org > Subject: Experiences with A10 AX series Load Balancers? > > Does anyone have any experiences good/bad/indifferent with this company and > their products? They claim 2x the performance at ? the cost and am a bit > leery as you can imagine. > > We are looking to replace our aging F5 BigIP LTM's and will be evaluating > these along with the Netscaler and new generation F5 boxes. > > > > > Regards, > > Bryan > > > From rudi.daniel at gmail.com Wed Mar 24 22:32:38 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Wed, 24 Mar 2010 23:32:38 -0400 Subject: NANOG Digest, Vol 26, Issue 122 In-Reply-To: References: Message-ID: <8aeeaff61003242032k3f582889ub438d1d3b9726531@mail.gmail.com> Hi Joe You guys ever mount your racks on Barry mounts= vibration mounts..with so many shakes you may need to. RD > > Message: 6 > Date: Wed, 24 Mar 2010 17:14:12 -0700 > From: Joe Abley > Subject: Re: Earthquakes > To: Ken Gilmour > Cc: NANOG list > Message-ID: <69CB2FCE-3D0E-44FE-93F4-8F3776DAD18D at hopcount.ca> > Content-Type: text/plain; charset=us-ascii > > > On 2010-03-24, at 13:12, Ken Gilmour wrote: > > > We had a 6.2 last year in Costa Rica... We immediately regretted where we > > had placed our racks and are almost finished a project to move them to a > > concrete floor (rather than that compressed cardboard stuff). Lost a lot > of > > hard drives that day! We regularly have quakes between the 4-5 region > here. > > By regularly, i mean a minimum of 5 times a year in different parts of > the > > country. > > If there is interest in data centre provisioning or construction, disaster > planning or inside/outside plant strategies intended to mitigate damage by > earthquakes then the NZNOG list might well be a good English-language place > to get some advice. > > Earthquakes of magnitude 4 and up happen pretty regularly (several times > per week is common). > > http://www.geonet.org.nz/earthquake/quakes/recent_quakes.html > http://www.nznog.org/ > > > Joe > > > > > ------------------------------ > > Message: 7 > Date: Wed, 24 Mar 2010 20:19:54 -0400 > From: "Peter Rocca" > Subject: Cogeco Contact...? > To: > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Can someone from the Cogeco NOC please contact me off-list at > roccap2005 at yahoo.com? I have tried ipservices at cogeco.net and > 1-905-333-7055 without luck. Thank you. > > > > ------------------------------ > > Message: 8 > Date: Wed, 24 Mar 2010 20:34:52 -0400 > From: "Peter Rocca" > Subject: RE: Cogeco Contact...? > To: > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Thanks all, success. > > -----Original Message----- > From: Peter Rocca [mailto:rocca at start.ca] > Sent: March 24, 2010 8:20 PM > To: nanog at nanog.org > Subject: Cogeco Contact...? > > Can someone from the Cogeco NOC please contact me off-list at > roccap2005 at yahoo.com? I have tried ipservices at cogeco.net and > 1-905-333-7055 without luck. Thank you. > > > > > ------------------------------ > > Message: 9 > Date: Wed, 24 Mar 2010 18:46:27 -0700 > From: Darren Bolding > Subject: Re: Experiences with A10 AX series Load Balancers? > To: Justin Horstman > Cc: "Welch, Bryan" , "nanog at nanog.org" > > Message-ID: > <5a318d411003241846ue709334icce03515da414d3e at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Very interesting to see about A10's performance- I've heard mixed things > about them. > > Just an FYI, the newer F5 platforms don't utilize the ASIC's- the > performance curve of general-purpose CPU's has once again eclipsed what can > be done with specialized silicon without aggressive (and expensive) > revision > cycles. The ASIC's also could only be used in simpler virtual server > configurations and with certain subsets of iRules. > > That said, nothing else I'm aware of provides the functionality of iRules. > I've used netscalers only a relatively small amount- and they are nice- > particularly if your requirements are within their feature set- but my > experience has been that things I take for granted using an iRule are > seriously painful to implement on a netscaler. > > --D > > On Wed, Mar 24, 2010 at 3:33 PM, Justin Horstman > wrote: > > > The boxes do alright at low load levels. They do not have an asic tech > like > > the F5s so choke on large amounts of traffic. Management is a bit > immature > > and you will find yourself having to use the CLI and the Gui to > accomplish > > most advanced tasks. > > > > When we put them head to head A10 AX3200 vs F5 6400 ltm (note: 6400 was > > what we were looking to replace) > > > > Test: > > 1000 concurrent users from Gomez's Networks Loadtesting platform hitting > as > > fast as the requests would close, going through our standard vip config > on > > the f5, and the A10 engineering teams 3 best efforts to beat that config > > that balanced between two Identical Dell 1950 servers serving a php page > > that responded with a random number (to avoid caching). The 6400 we used > was > > in production at the time, and was older so we were expecting to get > blown > > away, see the results here: > > > > F5 - Peaked 160k completed transactions a minute sustained for 10 > minutes, > > 0 errors, 112ms average transaction response time > > A10 - Held 60k completed transactions a minute sustained for 10 minutes, > 0 > > errors, 360ms average transaction response time > > > > If anyone is interested in the graphs I think I can still pull them out > of > > gomez. Though notable that this was all done a year ago, so things might > be > > different now. > > > > ~J > > > > > > -----Original Message----- > > From: Welch, Bryan [mailto:Bryan.Welch at arrisi.com] > > Sent: Tuesday, March 23, 2010 8:35 PM > > To: nanog at nanog.org > > Subject: Experiences with A10 AX series Load Balancers? > > > > Does anyone have any experiences good/bad/indifferent with this company > and > > their products? They claim 2x the performance at ? the cost and am a bit > > leery as you can imagine. > > > > We are looking to replace our aging F5 BigIP LTM's and will be evaluating > > these along with the Netscaler and new generation F5 boxes. > > > > > > > > > > Regards, > > > > Bryan > > > > > > > > > -- > -- Darren Bolding -- > -- darren at bolding.org -- > > > ------------------------------ > > Message: 10 > Date: Wed, 24 Mar 2010 18:50:42 -0700 > From: "Welch, Bryan" > Subject: RE: Experiences with A10 AX series Load Balancers? > To: Darren Bolding , Justin Horstman > > Cc: "nanog at nanog.org" > Message-ID: > < > DFA5AECDEC85EE4087D45C463C19B375134183938E at KWAEXMAIL1.ARRS.ARRISI.COM> > > Content-Type: text/plain; charset="iso-8859-1" > > Yes, agreed. I think the Netscaler falls into the category of the Cisco in > this respect . Seems the F5 gear is the 1000lb gorilla in this > category and for the most part we have no reason to look anywhere else other > than doing our own due diligence with respect to the other vendor offerings > in this space. > > > > Regards, > > Bryan > > From: packetmonger at gmail.com [mailto:packetmonger at gmail.com] On Behalf Of > Darren Bolding > Sent: Wednesday, March 24, 2010 6:46 PM > To: Justin Horstman > Cc: Welch, Bryan; nanog at nanog.org > Subject: Re: Experiences with A10 AX series Load Balancers? > > Very interesting to see about A10's performance- I've heard mixed things > about them. > > Just an FYI, the newer F5 platforms don't utilize the ASIC's- the > performance curve of general-purpose CPU's has once again eclipsed what can > be done with specialized silicon without aggressive (and expensive) revision > cycles. The ASIC's also could only be used in simpler virtual server > configurations and with certain subsets of iRules. > > That said, nothing else I'm aware of provides the functionality of iRules. > I've used netscalers only a relatively small amount- and they are nice- > particularly if your requirements are within their feature set- but my > experience has been that things I take for granted using an iRule are > seriously painful to implement on a netscaler. > > --D > > On Wed, Mar 24, 2010 at 3:33 PM, Justin Horstman < > jhorstman at adknowledge.com> wrote: > The boxes do alright at low load levels. They do not have an asic tech like > the F5s so choke on large amounts of traffic. Management is a bit immature > and you will find yourself having to use the CLI and the Gui to accomplish > most advanced tasks. > > When we put them head to head A10 AX3200 vs F5 6400 ltm (note: 6400 was > what we were looking to replace) > > Test: > 1000 concurrent users from Gomez's Networks Loadtesting platform hitting as > fast as the requests would close, going through our standard vip config on > the f5, and the A10 engineering teams 3 best efforts to beat that config > that balanced between two Identical Dell 1950 servers serving a php page > that responded with a random number (to avoid caching). The 6400 we used was > in production at the time, and was older so we were expecting to get blown > away, see the results here: > > F5 - Peaked 160k completed transactions a minute sustained for 10 minutes, > 0 errors, 112ms average transaction response time > A10 - Held 60k completed transactions a minute sustained for 10 minutes, 0 > errors, 360ms average transaction response time > > If anyone is interested in the graphs I think I can still pull them out of > gomez. Though notable that this was all done a year ago, so things might be > different now. > > ~J > > > -----Original Message----- > From: Welch, Bryan [mailto:Bryan.Welch at arrisi.com Bryan.Welch at arrisi.com>] > Sent: Tuesday, March 23, 2010 8:35 PM > To: nanog at nanog.org > Subject: Experiences with A10 AX series Load Balancers? > > Does anyone have any experiences good/bad/indifferent with this company and > their products? They claim 2x the performance at ? the cost and am a bit > leery as you can imagine. > > We are looking to replace our aging F5 BigIP LTM's and will be evaluating > these along with the Netscaler and new generation F5 boxes. > > > > > Regards, > > Bryan > > > > > -- > -- Darren Bolding -- > -- darren at bolding.org -- > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 26, Issue 122 > ************************************** > -- Rudi Daniel e Business Consultant http://www.svgpso.org http://oecstimes.wordpress.com ?The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.? - Bertrand Russell From mrz at velvet.org Wed Mar 24 23:05:15 2010 From: mrz at velvet.org (matthew zeier) Date: Wed, 24 Mar 2010 21:05:15 -0700 Subject: Experiences with A10 AX series Load Balancers? In-Reply-To: <5a318d411003241846ue709334icce03515da414d3e@mail.gmail.com> References: <5a318d411003241846ue709334icce03515da414d3e@mail.gmail.com> Message-ID: <3FB4A212-E8A1-40E5-9470-9A61F1A29D89@velvet.org> > That said, nothing else I'm aware of provides the functionality of iRules. I'd argue that Zeus' TrafficScript is on par or better than iRules. From gbonser at seven.com Wed Mar 24 23:13:27 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 24 Mar 2010 21:13:27 -0700 Subject: Earthquakes In-Reply-To: <4BAA92EE.5010309@mompl.net> References: <4BAA688C.2020406@mompl.net><3FAF6448-8D74-4108-B331-FAD8A74B76AC@delong.com> <4BAA92EE.5010309@mompl.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6931@RWC-EX1.corp.seven.com> The West Eifel volcanic field (SW of Bonn, Germany) is not far from NL and the last spectacular eruption there was about 9000 or so years ago (rather recently in geological terms). And there have been other significant earthquakes in the region in recorded history. The Lisbon quake in the 18th century was felt across much of Europe. > -----Original Message----- > From: Jeroen van Aart [mailto:jeroen at mompl.net] > Sent: Wednesday, March 24, 2010 3:32 PM > To: NANOG list > Subject: Re: Earthquakes > > Owen DeLong wrote: > > I've been through more than one quake in the 5.2-5.5 range, so, > perhaps they are > > rare in the Netherlands (6 million years or so), but, in California > they are much more > > frequent, perhaps 5-7 years or so. > > Well, 6 million years was a "slight" exaggeration to get a point > across. > The Netherlands doesn't really have any quakes due to faultlines (there > aren't any). But it does have the occasional quake due to coal/gas > mining. Where the ground compacts or something like it. From nanog at daork.net Wed Mar 24 23:29:59 2010 From: nanog at daork.net (Nathan Ward) Date: Thu, 25 Mar 2010 17:29:59 +1300 Subject: NANOG Digest, Vol 26, Issue 122 In-Reply-To: <8aeeaff61003242032k3f582889ub438d1d3b9726531@mail.gmail.com> References: <8aeeaff61003242032k3f582889ub438d1d3b9726531@mail.gmail.com> Message-ID: <67F1822A-5E98-43E9-8DBE-35C135A080B4@daork.net> On 25/03/2010, at 4:32 PM, Rudolph Daniel wrote: > Hi Joe > You guys ever mount your racks on Barry mounts= vibration mounts..with so > many shakes you may need to. > RD Nope. Instead, we stick it at the top of big towers that buffer the vibrations as they go up the tower. http://en.wikipedia.org/wiki/Sky_Tower From memory, we can thank/blame Joe for much of that. Up that tower we have the main switches for the Auckland Peering Exchange (which has in the last few years become a bit more distributed), the (main, or only) POPs for a bunch of offshore transit, including Pacnet and Vocus, and also an F-root instance. From memory it's the highest AGL peering exchange in the world. Probably the highest F-Root instance in the world as well. When there are high winds, the service lift that stops at the right levels cannot run, because it's on a longer shaft and so moves around a lot more. So you have to take the regular tourist glass-bottomed lift and then walk down about 6 flights to the comms floors. Also in moderate winds any unfastened cabinet doors will move with the sway of the tower. Try going up there at 4am after watching a thriller. Also the floor to ceiling glass about 2 feet from the bottom of the ladder you're at the top of a 50RU rack with. Plus the swaying building. You get over your vertigo pretty quickly, or you just don't go up the tower more than once. -- Nathan Ward From lists at billfehring.com Thu Mar 25 02:41:54 2010 From: lists at billfehring.com (Bill Fehring) Date: Thu, 25 Mar 2010 00:41:54 -0700 Subject: Experiences with A10 AX series Load Balancers? In-Reply-To: <3FB4A212-E8A1-40E5-9470-9A61F1A29D89@velvet.org> References: <5a318d411003241846ue709334icce03515da414d3e@mail.gmail.com> <3FB4A212-E8A1-40E5-9470-9A61F1A29D89@velvet.org> Message-ID: On Wed, Mar 24, 2010 at 21:05, matthew zeier wrote: > I'd argue that Zeus' TrafficScript is on par or better than iRules. +1 I'm a fan of F5 myself, but Zeus TrafficScript is a worthy contender. From sinha008 at hotmail.com Thu Mar 25 05:27:28 2010 From: sinha008 at hotmail.com (Jack Sinha) Date: Thu, 25 Mar 2010 10:27:28 +0000 (UTC) Subject: 10GBase-t switch References: Your message of Message-ID: Another option you can look at is TwinAx copper cables. There are lots of products that support it including - TurboIron24X from Brocade/Foundry, Arista boxes and BNT boxes. Jack From sinha008 at hotmail.com Thu Mar 25 05:35:56 2010 From: sinha008 at hotmail.com (Jack Sinha) Date: Thu, 25 Mar 2010 10:35:56 +0000 (UTC) Subject: 10GBase-t switch References: <20100311060407.13AFB1CC0D@ptavv.es.net> <4B9957B4.7080009@gmail.com> <5A6D953473350C4B9995546AFE9939EE08FE6635@RWC-EX1.corp.seven.com> <4B9EC809.5000106@bogus.com> Message-ID: I was talking to the Brocade SE and he mentioned that TurboIron 24X will support Full L3 including multicast routing along with advanced L2 such as stp groups, vlan groups, MRP, ..etc From ASTONGE at travelers.com Thu Mar 25 07:12:37 2010 From: ASTONGE at travelers.com (St. Onge,Adam) Date: Thu, 25 Mar 2010 08:12:37 -0400 Subject: Yahoo Mail admin Message-ID: <768FB653686AE54A9B4FB9A1503F03F51C9BFF4F38@TENK7MVB.prod.travp.net> Does anyone have a contact for a yahoo mail admin that they could please provide offlist? We removed some mx records in late February but are still seeing yahoo servers attempting to deliver mail to these addresses. Thanks, Adam ============================================================================== This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies. From bpasdar at batblue.com Thu Mar 25 07:30:04 2010 From: bpasdar at batblue.com (Babak Pasdar) Date: Thu, 25 Mar 2010 08:30:04 -0400 Subject: =?iso-8859-1?Q?Experiences_with_A10_AX_series_Load_Balancers=3F=20?= Message-ID: <20100325123004.478ef1dc@concur.batblue.com> Bryan, We have built out our infrastructure around A10 and after doing our own due diligence on them, we like them for the following reasons: 1. The performance is outrageous (in a good way) in terms of: a. Total number of sessions supported b. Ramp Rate (New connections per second) c. Throughput, up to 37+ gig in our tests Quite frankly A10 is the only company we found that could help us deliver on a secure 100Gig plus network that we designed for a client. Their specs were 100Gig today with scalability to 200Gig. The AX-5200 delivered as advertised for us. F5 didn't even come close to scaling to these levels in our testing. 2. The interface is reasonably decent, but could stand some refinement. The aPolicy is for the most part a one-for-one replacement of the F5 TCL iPolicy. So transitioning should be pretty straight -forward. 3. The company is a good company with good support. Lee Chen, one of the founders of Foundry Networks started A10. I went to California and met with him and his engineering team to see the type of folks we would be engaging with. They were extremely pleasant to deal with, unlike a lot of the other companies out there today. The foundation of the system is that they came up with a process to make Parallelization far more efficient than the standard high-performance OSes like Linux and Unix. This lets them throttle through scenarios that bog down other systems. We have seen first-hand how the systems performance has addressed DNS DoS scenarios where F5 fell down on the job. 4. Finally, the cost is far more pleasant than the nickle and diming that F5 does for this license and that license. This is the one area F5 should really get dinged on. I don't at all care for the In our scenario it came in at roughly 40% less than F5. All-in-all my advice is you can't go wrong with the A10 unless there is some specific feature that is missing. We have not found any for our purposes. Quite frankly I feel that many people are unnecessarily afraid to migrate away from F5. Not that F5 is a bad product or company, but competition is good and A10 is a good competitor. We are very pleased with our decision to go with A10. I hope this is useful feedback for you. Best Regards, Babak -- Babak Pasdar President & CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability (p) 212.461.3322 x3005 | (f) 212.584.9999 | (w) www.BatBlue.com Receive Bat Blue's Daily Security Intelligence Report Bat Blue's AS: 25885 | BGP Policy | Peering Policy Bat Blue's Legal Notice Reducing IT Security Budget, Burden & Risk - Video | Article > -----Original Message----- > From: Welch, Bryan [mailto:Bryan.Welch at arrisi.com] > Sent: Tuesday, March 23, 2010 8:35 PM > To: nanog at nanog.org > Subject: Experiences with A10 AX series Load Balancers? > > Does anyone have any experiences good/bad/indifferent with this company and > their products? They claim 2x the performance at ? the cost and am a bit > leery as you can imagine. > > We are looking to replace our aging F5 BigIP LTM's and will be evaluating > these along with the Netscaler and new generation F5 boxes. > > > > > Regards, > > Bryan > > > From kyle.bader at gmail.com Thu Mar 25 07:51:56 2010 From: kyle.bader at gmail.com (Kyle Bader) Date: Thu, 25 Mar 2010 05:51:56 -0700 Subject: NTP clock source Message-ID: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Can anyone recommend a solid clock souce (stratum 0) that's not overly expensive? The only stuff I've found so far is ESE, can anyone recommend them or conversely has anyone had any problems with their hardware? -- Kyle From dga at cs.cmu.edu Thu Mar 25 07:58:02 2010 From: dga at cs.cmu.edu (David Andersen) Date: Thu, 25 Mar 2010 08:58:02 -0400 Subject: NTP clock source In-Reply-To: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Message-ID: <0014AAF3-8F5A-4876-80B1-9A86D97C15C6@cs.cmu.edu> Can you clarify your requirements when you say stratum 0? Accuracy, holdover time, needed outputs, do you want a standalone box or something that you plug in to an existing computer or router? -Dave On Mar 25, 2010, at 8:51 AM, Kyle Bader wrote: > Can anyone recommend a solid clock souce (stratum 0) that's not overly > expensive? The only stuff I've found so far is ESE, can anyone > recommend them or conversely has anyone had any problems with their > hardware? > > -- > > Kyle > > From mhuff at ox.com Thu Mar 25 08:27:09 2010 From: mhuff at ox.com (Matthew Huff) Date: Thu, 25 Mar 2010 09:27:09 -0400 Subject: NTP clock source In-Reply-To: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C6A@PUR-EXCH07.ox.com> http://www.symmetricom.com/ We have two of their S200 syncservers. Works great. ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: Kyle Bader [mailto:kyle.bader at gmail.com] > Sent: Thursday, March 25, 2010 8:52 AM > To: nanog at nanog.org > Subject: NTP clock source > > Can anyone recommend a solid clock souce (stratum 0) that's not overly > expensive? The only stuff I've found so far is ESE, can anyone > recommend them or conversely has anyone had any problems with their > hardware? > > -- > > Kyle From gerry at tape.net Thu Mar 25 08:28:56 2010 From: gerry at tape.net (Gerry Boudreaux) Date: Thu, 25 Mar 2010 08:28:56 -0500 Subject: NTP clock source In-Reply-To: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Message-ID: <678AEB6B-7850-41A4-92FD-78DAC1337643@tape.net> On Mar 25, 2010, at 07:51 , Kyle Bader wrote: > Can anyone recommend a solid clock souce (stratum 0) that's not overly > expensive? The only stuff I've found so far is ESE, can anyone > recommend them or conversely has anyone had any problems with their > hardware? You can look at the Tempus LX line from Endrun Tech. if a GPS based NTP server will work for you. They also have a CDMA version. http://www.endruntechnologies.com/time-server.htm HTH G From kwallace at pcconnection.com Thu Mar 25 08:48:05 2010 From: kwallace at pcconnection.com (Wallace Keith) Date: Thu, 25 Mar 2010 09:48:05 -0400 Subject: NTP clock source In-Reply-To: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Message-ID: <0E8773C725A1674E9F7B35EABB5EEEB1081F01EE@MKA134.pcc.int> -----Original Message----- From: Kyle Bader [mailto:kyle.bader at gmail.com] Sent: Thursday, March 25, 2010 8:52 AM To: nanog at nanog.org Subject: NTP clock source Can anyone recommend a solid clock souce (stratum 0) that's not overly expensive? The only stuff I've found so far is ESE, can anyone recommend them or conversely has anyone had any problems with their hardware? -- Kyle I'm very happy with Symmetricom's Time Provider 1100 series- these provide NTP as well as clocking for SONET and ATM gear. They have been rock solid. -Keith From davehart at gmail.com Thu Mar 25 09:03:22 2010 From: davehart at gmail.com (Dave Hart) Date: Thu, 25 Mar 2010 14:03:22 +0000 Subject: NTP clock source In-Reply-To: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Message-ID: <85d954181003250703l5d9930a2l6655a3ef244ebfd7@mail.gmail.com> On Thu, Mar 25, 2010 at 12:51 UTC, Kyle Bader wrote: > Can anyone recommend a solid clock souce (stratum 0) that's not overly > expensive? All the options I'm aware of have no prices posted, sadly. For me, that means "forget it, you don't want to spend that much", but then I'm not spending other people's money :) In addition to Symmetricom and EndRun Technologies, Meinberg has a solid reputation in this space: http://www.meinberg.de/english/products/#network_sync I'm biased toward Meinberg because several of their staff contribute their skills to the development and maintenance of the ntp.org reference implementation. They have also been generous donating hardware over the years to ntp.org and pool.ntp.org, and their Windows NTP binaries and GUI installer are widely used. The cheapest solution involves the Garmin GPS 18x LVC receiver and a soldering iron. Unlike the USB and "PC" (232) versions of the GPS 18x, the LVC version supplies a pulse-per-second signal which makes it suitable for sub-millisecond NTP sync. The supplied connector has to be cut off, a DB-9 serial hood wired in its place, and either a USB cable or other 5V power supply needs to be attached. Or you can do as I did and pay for the completed GPS 18x LVC with DB-9 and USB connectors from a third party. $105 from: http://psn.quake.net/gps/gps18.html You also need a junkbox PC with real serial ports (not via a USB adapter), or the capacity on an existing server. The GPS 18x cable is either 3m or 5m long, if your PC is not close enough to a southern-exposed window or to roof access for the 18x to lock, you may also need a RS-232 extension cable and USB power supply. Unlike timing-focused GPSes, the 18x needs 3 or more birds in view to provide a PPS signal. Good luck, Dave Hart From hrlinneweh at sbcglobal.net Thu Mar 25 09:24:46 2010 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Thu, 25 Mar 2010 07:24:46 -0700 (PDT) Subject: NTP clock source In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C6A@PUR-EXCH07.ox.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C6A@PUR-EXCH07.ox.com> Message-ID: <369772.93539.qm@web180311.mail.gq1.yahoo.com> http://www.brillianttelecom.com/ is another timing solutions provider -henry ________________________________ From: Matthew Huff To: Kyle Bader ; "nanog at nanog.org" Sent: Thu, March 25, 2010 5:27:09 AM Subject: RE: NTP clock source http://www.symmetricom.com/ We have two of their S200 syncservers. Works great. ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com? | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: Kyle Bader [mailto:kyle.bader at gmail.com] > Sent: Thursday, March 25, 2010 8:52 AM > To: nanog at nanog.org > Subject: NTP clock source > > Can anyone recommend a solid clock souce (stratum 0) that's not overly > expensive? The only stuff I've found so far is ESE, can anyone > recommend them or conversely has anyone had any problems with their > hardware? > > -- > > Kyle From meekjt at gmail.com Thu Mar 25 09:42:33 2010 From: meekjt at gmail.com (Jon Meek) Date: Thu, 25 Mar 2010 10:42:33 -0400 Subject: NTP clock source In-Reply-To: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Message-ID: I use both EndRun Technologies and the "Garmin 18x LVC + old PC" solution. I am currently seeing 8+ satellites out a North facing window almost all of the time with the Garmin. The window method may not work if the window is coated with a metallic layer (common in newer buildings). Also, be careful extending the serial line. The rise time of the PPS signal is already degraded by the length of wire that is supplied. Jon On Thu, Mar 25, 2010 at 8:51 AM, Kyle Bader wrote: > Can anyone recommend a solid clock souce (stratum 0) that's not overly > expensive? The only stuff I've found so far is ESE, can anyone > recommend them or conversely has anyone had any problems with their > hardware? > > -- > > Kyle > > From marty.anstey at sunwave.net Thu Mar 25 11:46:23 2010 From: marty.anstey at sunwave.net (Marty Anstey) Date: Thu, 25 Mar 2010 09:46:23 -0700 Subject: NTP clock source In-Reply-To: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Message-ID: <4BAB935F.2040509@sunwave.net> Kyle Bader wrote: > Can anyone recommend a solid clock souce (stratum 0) that's not overly > expensive? The only stuff I've found so far is ESE, can anyone > recommend them or conversely has anyone had any problems with their > hardware? > > If you are of the DIY persuasion, check out the following project: http://www.febo.com/pages/soekris/ -M From eriks at nationalfastfreight.com Thu Mar 25 12:10:11 2010 From: eriks at nationalfastfreight.com (Erik Soosalu) Date: Thu, 25 Mar 2010 13:10:11 -0400 Subject: NTP clock source In-Reply-To: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Message-ID: <0B224A2FE01CC54C860290D42474BF60042D1347@exchange.nff.local> Garmin 17HVS mounted on the top of the building attached to a old HP thin client (SSD with no fans) running FreeBSD. After implementation, I haven't thought about it since. Thanks, Erik -----Original Message----- From: Kyle Bader [mailto:kyle.bader at gmail.com] Sent: Thursday, March 25, 2010 8:52 AM To: nanog at nanog.org Subject: NTP clock source Can anyone recommend a solid clock souce (stratum 0) that's not overly expensive? The only stuff I've found so far is ESE, can anyone recommend them or conversely has anyone had any problems with their hardware? -- Kyle From shoop at iwiring.net Thu Mar 25 12:40:14 2010 From: shoop at iwiring.net (Dan Shoop) Date: Thu, 25 Mar 2010 13:40:14 -0400 Subject: NTP clock source In-Reply-To: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Message-ID: <98EECE82-8E77-471F-A6E3-EB54B3902241@iwiring.net> On Mar 25, 2010, at 8:51 AM, Kyle Bader wrote: > Can anyone recommend a solid clock souce (stratum 0) that's not overly > expensive? The only stuff I've found so far is ESE, can anyone > recommend them or conversely has anyone had any problems with their > hardware? > > -- > > Kyle We have several symmetricom time servers that we use in several location and I'd recommend them very highly. -d ------------------------------------------------------------------------ Dan Shoop Computer Scientist shoop at iwiring.net GoogleVoice: 1-646-402-5293 aim: iWiring twitter: @colonelmode From nanog at konadogs.net Thu Mar 25 15:12:23 2010 From: nanog at konadogs.net (Nate Itkin) Date: Thu, 25 Mar 2010 10:12:23 -1000 Subject: NTP clock source In-Reply-To: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Message-ID: <20100325201223.GA24585@li92-81.konadogs.net> On Thu, Mar 25, 2010 at 05:51:56AM -0700, Kyle Bader wrote: > Can anyone recommend a solid clock souce (stratum 0) that's not overly > expensive? The Endrun Technologies product worked well for me. After an initial set-up, it was maintenance free. I couldn't install a rooftop antenna so I needed the CDMA receiver. http://www.endruntechnologies.com/network-time-server.htm Nate Itkin From joesox at gmail.com Thu Mar 25 16:52:00 2010 From: joesox at gmail.com (JoeSox) Date: Thu, 25 Mar 2010 15:52:00 -0600 Subject: Hotmail and player.play.it Message-ID: <785694cd1003251452s6278a9e4tf5c610f0571913c4@mail.gmail.com> I just ran into this problem about two or so weeks ago hoping it would go away. I am denying 'player.play.it' [currently resolving to 67.148.71.9, 67.148.71.11] on my Juniper firewall. However I get denied navigating to 'hotmail.com' [policy says it is 67.148.71.11 causing the trouble] I don't see any player.play.it references in the html or anything (including the live.com sites unless I am missing something). Any hotmail admins fix this or something or maybe I am missing something else. -- Thanks, Joe From jmheralds at gmail.com Thu Mar 25 18:58:50 2010 From: jmheralds at gmail.com (James Heralds) Date: Thu, 25 Mar 2010 19:58:50 -0400 Subject: Call for papers (Deadline Extended): ISP-10, USA, July 2010 Message-ID: <739582dd1003251658w68a0f3a5x3fac4d397503e128@mail.gmail.com> It would be highly appreciated if you could share this announcement with your colleagues, students and individuals whose research is in information security, cryptography, privacy, and related areas. Call for papers (Deadline Extended): ISP-10, USA, July 2010 The 2010 International Conference on Information Security and Privacy (ISP-10) (website: http://www.PromoteResearch.org) will be held during 12-14 of July 2010 in Orlando, FL, USA. ISP is an important event in the areas of information security, privacy, cryptography and related topics. The conference will be held at the same time and location where several other major international conferences will be taking place. The conference will be held as part of 2010 multi-conference (MULTICONF-10). MULTICONF-10 will be held during July 12-14, 2010 in Orlando, Florida, USA. The primary goal of MULTICONF is to promote research and developmental activities in computer science, information technology, control engineering, and related fields. Another goal is to promote the dissemination of research to a multidisciplinary audience and to facilitate communication among researchers, developers, practitioners in different fields. The following conferences are planned to be organized as part of MULTICONF-10. ? International Conference on Artificial Intelligence and Pattern Recognition (AIPR-10) ? International Conference on Automation, Robotics and Control Systems (ARCS-10) ? International Conference on Bioinformatics, Computational Biology, Genomics and Chemoinformatics (BCBGC-10) ? International Conference on Computer Communications and Networks (CCN-10) ? International Conference on Enterprise Information Systems and Web Technologies (EISWT-10) ? International Conference on High Performance Computing Systems (HPCS-10) ? International Conference on Information Security and Privacy (ISP-10) ? International Conference on Image and Video Processing and Computer Vision (IVPCV-10) ? International Conference on Software Engineering Theory and Practice (SETP-10) ? International Conference on Theoretical and Mathematical Foundations of Computer Science (TMFCS-10) MULTICONF-10 will be held at Imperial Swan Hotel and Suites. It is a full-service resort that puts you in the middle of the fun! Located 1/2 block south of the famed International Drive, the hotel is just minutes from great entertainment like Walt Disney World? Resort, Universal Studios and Sea World Orlando. Guests can enjoy free scheduled transportation to these theme parks, as well as spacious accommodations, outdoor pools and on-site dining ? all situated on 10 tropically landscaped acres. Here, guests can experience a full-service resort with discount hotel pricing in Orlando. We invite draft paper submissions. Please see the website http://www.PromoteResearch.org for more details. From mpetach at netflight.com Thu Mar 25 22:16:36 2010 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 25 Mar 2010 20:16:36 -0700 Subject: Hotmail and player.play.it In-Reply-To: <785694cd1003251452s6278a9e4tf5c610f0571913c4@mail.gmail.com> References: <785694cd1003251452s6278a9e4tf5c610f0571913c4@mail.gmail.com> Message-ID: <63ac96a51003252016v4f818883tc38cbd8e04b0c1fa@mail.gmail.com> On Thu, Mar 25, 2010 at 2:52 PM, JoeSox wrote: > I just ran into this problem about two or so weeks ago hoping it would go away. > I am denying 'player.play.it' [currently resolving to 67.148.71.9, > 67.148.71.11] on my Juniper firewall. > > However I get denied navigating to 'hotmail.com' [policy says it is > 67.148.71.11 causing the trouble] > > I don't see any player.play.it references in the html or anything > (including the live.com sites unless I am missing something). Any > hotmail admins fix this or something or maybe I am missing something > else. mpetach at netops2:~> whois -h whois.arin.net 67.148.71.9 Qwest Communications Company, LLC QWEST-INET-19 (NET-67-144-0-0-1) 67.144.0.0 - 67.148.255.255 AKAMAI TECHNOLOGIES INC Q1111-67-148-71-0 (NET-67-148-71-0-1) 67.148.71.0 - 67.148.71.255 # ARIN WHOIS database, last updated 2010-03-25 20:00 # Enter ? for additional hints on searching ARIN's WHOIS database. # # ARIN WHOIS data and services are subject to the Terms of Use # available at https://www.arin.net/whois_tou.html mpetach at netops2:~> Welcome to the joys of outsourced CDN platforms. You're effectively blocking anything that uses Akamai--probably not what you meant to do. Try re-evaluating your security policy and focus it a bit more tightly on what you're trying to secure against. ^_^; Matt > -- > Thanks, Joe > > From joesox at gmail.com Thu Mar 25 23:05:33 2010 From: joesox at gmail.com (JoeSox) Date: Thu, 25 Mar 2010 21:05:33 -0700 Subject: Hotmail and player.play.it In-Reply-To: <63ac96a51003252016v4f818883tc38cbd8e04b0c1fa@mail.gmail.com> References: <785694cd1003251452s6278a9e4tf5c610f0571913c4@mail.gmail.com> <63ac96a51003252016v4f818883tc38cbd8e04b0c1fa@mail.gmail.com> Message-ID: <785694cd1003252105i5e6b2729r9cc7b2961e4f0932@mail.gmail.com> Yes, I figured; I was 'scared' to do a whois and I appreciate the confirmations. I am just using the basic built-in Juniper object for domain deny/reject policy because that is all this shop has. It's not the first time, but I was hoping for another answer instead of SOL -- Thanks, Joe On Thu, Mar 25, 2010 at 8:16 PM, Matthew Petach wrote: > On Thu, Mar 25, 2010 at 2:52 PM, wrote: >> I just ran into this problem about two or so weeks ago hoping it would go away. >> I am denying 'player.play.it' [currently resolving to 67.148.71.9, >> 67.148.71.11] on my Juniper firewall. >> >> However I get denied navigating to 'hotmail.com' [policy says it is >> 67.148.71.11 causing the trouble] >> >> I don't see any player.play.it references in the html or anything >> (including the live.com sites unless I am missing something). Any >> hotmail admins fix this or something or maybe I am missing something >> else. > > > mpetach at netops2:~> whois -h whois.arin.net 67.148.71.9 > Qwest Communications Company, LLC QWEST-INET-19 (NET-67-144-0-0-1) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?67.144.0.0 - 67.148.255.255 > AKAMAI TECHNOLOGIES INC Q1111-67-148-71-0 (NET-67-148-71-0-1) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?67.148.71.0 - 67.148.71.255 > > # ARIN WHOIS database, last updated 2010-03-25 20:00 > # Enter ? for additional hints on searching ARIN's WHOIS database. > # > # ARIN WHOIS data and services are subject to the Terms of Use > # available at https://www.arin.net/whois_tou.html > mpetach at netops2:~> > > Welcome to the joys of outsourced CDN platforms. ?You're effectively > blocking anything that uses Akamai--probably not what you meant to > do. ?Try re-evaluating your security policy and focus it a bit more > tightly on what you're trying to secure against. ?^_^; > > Matt > >> -- >> Thanks, Joe >> >> > From frnkblk at iname.com Fri Mar 26 00:30:57 2010 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 26 Mar 2010 00:30:57 -0500 Subject: Call for papers (Deadline Extended): ISP-10, USA, July 2010 In-Reply-To: <739582dd1003251658w68a0f3a5x3fac4d397503e128@mail.gmail.com> References: <739582dd1003251658w68a0f3a5x3fac4d397503e128@mail.gmail.com> Message-ID: ***FAKE CONFERERENCE*** (in case you didn't know) -----Original Message----- From: James Heralds [mailto:jmheralds at gmail.com] Sent: Thursday, March 25, 2010 6:59 PM To: nanog at nanog.org Subject: Call for papers (Deadline Extended): ISP-10, USA, July 2010 It would be highly appreciated if you could share this announcement with your colleagues, students and individuals whose research is in information security, cryptography, privacy, and related areas. Call for papers (Deadline Extended): ISP-10, USA, July 2010 The 2010 International Conference on Information Security and Privacy (ISP-10) (website: http://www.PromoteResearch.org) will be held during 12-14 of July 2010 in Orlando, FL, USA. ISP is an important event in the areas of information security, privacy, cryptography and related topics. The conference will be held at the same time and location where several other major international conferences will be taking place. The conference will be held as part of 2010 multi-conference (MULTICONF-10). MULTICONF-10 will be held during July 12-14, 2010 in Orlando, Florida, USA. The primary goal of MULTICONF is to promote research and developmental activities in computer science, information technology, control engineering, and related fields. Another goal is to promote the dissemination of research to a multidisciplinary audience and to facilitate communication among researchers, developers, practitioners in different fields. The following conferences are planned to be organized as part of MULTICONF-10. . International Conference on Artificial Intelligence and Pattern Recognition (AIPR-10) . International Conference on Automation, Robotics and Control Systems (ARCS-10) . International Conference on Bioinformatics, Computational Biology, Genomics and Chemoinformatics (BCBGC-10) . International Conference on Computer Communications and Networks (CCN-10) . International Conference on Enterprise Information Systems and Web Technologies (EISWT-10) . International Conference on High Performance Computing Systems (HPCS-10) . International Conference on Information Security and Privacy (ISP-10) . International Conference on Image and Video Processing and Computer Vision (IVPCV-10) . International Conference on Software Engineering Theory and Practice (SETP-10) . International Conference on Theoretical and Mathematical Foundations of Computer Science (TMFCS-10) MULTICONF-10 will be held at Imperial Swan Hotel and Suites. It is a full-service resort that puts you in the middle of the fun! Located 1/2 block south of the famed International Drive, the hotel is just minutes from great entertainment like Walt Disney WorldR Resort, Universal Studios and Sea World Orlando. Guests can enjoy free scheduled transportation to these theme parks, as well as spacious accommodations, outdoor pools and on-site dining - all situated on 10 tropically landscaped acres. Here, guests can experience a full-service resort with discount hotel pricing in Orlando. We invite draft paper submissions. Please see the website http://www.PromoteResearch.org for more details. From lutz.muehlig at internetx.de Fri Mar 26 08:21:23 2010 From: lutz.muehlig at internetx.de (InterNetX - Lutz Muehlig) Date: Fri, 26 Mar 2010 14:21:23 +0100 Subject: IPv4 ANYCAST setup Message-ID: <4BACB4D3.60003@internetx.com> Hello, has someone experience in anycast ipv4 networks (to support DNS)? Regards Lutz From jeroen at unfix.org Fri Mar 26 08:24:21 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 26 Mar 2010 14:24:21 +0100 Subject: IPv4 ANYCAST setup In-Reply-To: <4BACB4D3.60003@internetx.com> References: <4BACB4D3.60003@internetx.com> Message-ID: <4BACB585.5040805@spaghetti.zurich.ibm.com> InterNetX - Lutz Muehlig wrote: > Hello, > > has someone experience in anycast ipv4 networks (to support DNS)? "Never been done" "Dangerous" "TCP does not work" etc etc etc. I assume quite a number of people know how to do it, especially as several root DNS servers abuse it. Simple recipe: - Box with: - Your favourite OS - Quagga or OpenBGPd - Your favourite DNS server - Announce the IP of the anycast node in BGP - Monitor the DNS server, when it does not work kill your local BGPd and notify the admins that it broke That is it. Probably with the above couple of things, google a bit and find the rest. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From rsk at gsp.org Fri Mar 26 08:38:23 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 26 Mar 2010 09:38:23 -0400 Subject: Call for papers (Deadline Extended): ISP-10, USA, July 2010 In-Reply-To: <739582dd1003251658w68a0f3a5x3fac4d397503e128@mail.gmail.com> References: <739582dd1003251658w68a0f3a5x3fac4d397503e128@mail.gmail.com> Message-ID: <20100326133823.GA25408@gsp.org> This is the same fake conference spammer who's been hitting a lot of mailing lists and Usenet newsgroups -- best to blacklist the sender address and the domain. ---Rsk From maxlarson.henry at mtptc.gouv.ht Fri Mar 26 08:40:39 2010 From: maxlarson.henry at mtptc.gouv.ht (Max Larson Henry) Date: Fri, 26 Mar 2010 09:40:39 -0400 Subject: IPv4 ANYCAST setup In-Reply-To: <4BACB585.5040805@spaghetti.zurich.ibm.com> References: <4BACB4D3.60003@internetx.com> <4BACB585.5040805@spaghetti.zurich.ibm.com> Message-ID: <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> > > has someone experience in anycast ipv4 networks (to support DNS)? > > "Never been done" "Dangerous" "TCP does not work" etc etc etc. > - Yes but as for DNS, anycast is essentially used for user requests (UDP) not to perform zone transfer(TCP). -M From lowen at pari.edu Fri Mar 26 08:40:35 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 26 Mar 2010 09:40:35 -0400 Subject: NTP clock source In-Reply-To: <4BAB935F.2040509@sunwave.net> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> Message-ID: <201003260940.35677.lowen@pari.edu> On Thursday 25 March 2010 12:46:23 pm Marty Anstey wrote: > If you are of the DIY persuasion, check out the following project: > http://www.febo.com/pages/soekris/ And if the OP (or any one else on list) is of that persuasion, and really wants to get into serious timing discussions, joining the time-nuts mailing list at febo.com would be a good idea. And if Stratum 0 is a requirement, then looking at the time-nuts archives at least would be good preparation for running a real Stratum 0 time source. From john at sackheads.org Fri Mar 26 08:44:43 2010 From: john at sackheads.org (John Payne) Date: Fri, 26 Mar 2010 09:44:43 -0400 Subject: IPv4 ANYCAST setup In-Reply-To: <4BACB585.5040805@spaghetti.zurich.ibm.com> References: <4BACB4D3.60003@internetx.com> <4BACB585.5040805@spaghetti.zurich.ibm.com> Message-ID: On Mar 26, 2010, at 9:24 AM, Jeroen Massar wrote: > InterNetX - Lutz Muehlig wrote: >> Hello, >> >> has someone experience in anycast ipv4 networks (to support DNS)? > > "Never been done" "Dangerous" "TCP does not work" etc etc etc. Can't really tell if you're being serious here due to caffeine underrun. http://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf Slide 23 seems quite appropriate. http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-tue-anycast.pdf has links to other work on this. It certainly seems to work "well enough". > > I assume quite a number of people know how to do it, especially as > several root DNS servers abuse it. > > Simple recipe: > - Box with: > - Your favourite OS > - Quagga or OpenBGPd > - Your favourite DNS server > - Announce the IP of the anycast node in BGP > - Monitor the DNS server, when it does not work kill your local BGPd > and notify the admins that it broke > > That is it. Probably with the above couple of things, google a bit and > find the rest. > > Greets, > Jeroen > From paul at transversal.com Fri Mar 26 08:52:29 2010 From: paul at transversal.com (Paul Ryland) Date: Fri, 26 Mar 2010 13:52:29 -0000 Subject: IPv4 ANYCAST setup In-Reply-To: <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> References: <4BACB4D3.60003@internetx.com><4BACB585.5040805@spaghetti.zurich.ibm.com> <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> Message-ID: > > > has someone experience in anycast ipv4 networks (to support DNS)? > > > > "Never been done" "Dangerous" "TCP does not work" etc etc etc. > > - Yes but as for DNS, anycast is essentially used for user requests (UDP) > not to perform zone transfer(TCP). How-to with working configurations for Linux+Quagga: Further information is found in RFC3258: Remember to disable PMTU discovery on your DNS servers if you are using this. Paul From Valdis.Kletnieks at vt.edu Fri Mar 26 08:52:48 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 26 Mar 2010 09:52:48 -0400 Subject: IPv4 ANYCAST setup In-Reply-To: Your message of "Fri, 26 Mar 2010 09:40:39 EDT." <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> References: <4BACB4D3.60003@internetx.com> <4BACB585.5040805@spaghetti.zurich.ibm.com> <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> Message-ID: <4828.1269611568@localhost> On Fri, 26 Mar 2010 09:40:39 EDT, Max Larson Henry said: > - Yes but as for DNS, anycast is essentially used for user requests (UDP) > not to perform zone transfer(TCP). DNS uses TCP for more than just XFR. For instance, if you're running a resolver that doesn't do EDNS0, and you hit an (increasingly common) DNSSEC signed reply, it's going to be over 512 bytes and the lack of EDNS0 will cause it to re-ask via TCP. Just mentioning it because the sort of sites that think TCP==XFR are the sort most likely to be running firewalls that munch the EDNS0 bits, and are setting themselves up for big surprises in the very near future. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jeroen at unfix.org Fri Mar 26 08:55:20 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 26 Mar 2010 14:55:20 +0100 Subject: IPv4 ANYCAST setup In-Reply-To: <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> References: <4BACB4D3.60003@internetx.com> <4BACB585.5040805@spaghetti.zurich.ibm.com> <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> Message-ID: <4BACBCC8.3020409@spaghetti.zurich.ibm.com> Max Larson Henry wrote: > > > has someone experience in anycast ipv4 networks (to support DNS)? > > "Never been done" "Dangerous" "TCP does not work" etc etc etc. > > > - Yes but as for DNS, anycast is essentially used for user requests > (UDP) not to perform zone transfer(TCP). Also that would work, unless you have a very unstable routing table that makes the node swap all the time. Please also note that if a DNS answer does not fit inside a a UDP packet (default 512, MTU with EDNS0) that the fallback is TCP mode... John Payne wrote: [..] > Can't really tell if you're being serious here due to caffeine > underrun. As it is already almost 15:00 in Europe (and it is a friday), take a guess ;) Also note the next line I wrote and the point to the google, which you now have done for the person, who probably is also having a lazy friday afternoon ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: From fweimer at bfk.de Fri Mar 26 09:03:22 2010 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 26 Mar 2010 14:03:22 +0000 Subject: IPv4 ANYCAST setup In-Reply-To: <4BACB585.5040805@spaghetti.zurich.ibm.com> (Jeroen Massar's message of "Fri\, 26 Mar 2010 14\:24\:21 +0100") References: <4BACB4D3.60003@internetx.com> <4BACB585.5040805@spaghetti.zurich.ibm.com> Message-ID: <82iq8j9o45.fsf@mid.bfk.de> * Jeroen Massar: > Simple recipe: > - Box with: > - Your favourite OS > - Quagga or OpenBGPd > - Your favourite DNS server > - Announce the IP of the anycast node in BGP > - Monitor the DNS server, when it does not work kill your local BGPd > and notify the admins that it broke This is fine if you just use BGP to indirectly hook into your IGP. For global anycast, you need a sufficiently short prefix with no non-anycast services on it. This can be difficult to justify for newcomers. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From lowen at pari.edu Fri Mar 26 09:35:36 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 26 Mar 2010 10:35:36 -0400 Subject: IP4 Space In-Reply-To: <7DFF0D2A-3D26-44B9-A0C7-7C4B5F1FD77E@internode.com.au> References: Message-ID: <201003261035.36198.lowen@pari.edu> On Tuesday 23 March 2010 10:59:31 pm Mark Newton wrote: > How many 10 year old pieces of kit do you have on your network? 90% of the network equipment here is over ten years old, and still trucking. No plans to replace what is still working, as long as we have spares in stock, and until we get grants to pay for replacements. No compelling reasons for the capex on replacing 75% of that over ten year old equipment, either, as long as it still works and isn't too insecure to use. From nanog at shreddedmail.com Fri Mar 26 10:15:36 2010 From: nanog at shreddedmail.com (Rick Ernst) Date: Fri, 26 Mar 2010 08:15:36 -0700 Subject: "Is TDM going the way of dial-up?" Message-ID: I've noticed over the last 3 years or so that TDM, specifically T-1, access and transport has been in a steady decline. Customers are moving to FTTH and cable, or going WiMAX and Metro-Ethernet. Ethernet seems to have taken an even bigger bite out of DS-3. The bigger pipes seem to favor ethernet. A recent upgrade from OC-3 to GigE transport actually saved us a large chunk of money. I'm wondering if others are seeing the same behavior, if it's market-dependant, or if I'm just imagining things. I'm working on building new infrastructure and my current thoughts are to minimize my TDM footprint. It would be useful to get a better feel if this is an overall trend or something local. Thoughts? Thanks, From smeuse at mara.org Fri Mar 26 10:26:28 2010 From: smeuse at mara.org (Steve Meuse) Date: Fri, 26 Mar 2010 11:26:28 -0400 Subject: "Is TDM going the way of dial-up?" In-Reply-To: References: Message-ID: <20100326152628.GA4823@mara.org> Rick Ernst expunged (nanog at shreddedmail.com): > I'm wondering if others are seeing the same behavior, if it's > market-dependant, or if I'm just imagining things. I'm working on building > new infrastructure and my current thoughts are to minimize my TDM > footprint. It would be useful to get a better feel if this is an overall > trend or something local. You aren't imagining things. In fact, some large national networks have been designed to support solely ethernet. It comes down to cost, as always.... -Steve From mike at mtcc.com Fri Mar 26 10:32:08 2010 From: mike at mtcc.com (Michael Thomas) Date: Fri, 26 Mar 2010 08:32:08 -0700 Subject: "Is TDM going the way of dial-up?" In-Reply-To: <20100326152628.GA4823@mara.org> References: <20100326152628.GA4823@mara.org> Message-ID: <4BACD378.4080302@mtcc.com> On 03/26/2010 08:26 AM, Steve Meuse wrote: > Rick Ernst expunged (nanog at shreddedmail.com): > >> I'm wondering if others are seeing the same behavior, if it's >> market-dependant, or if I'm just imagining things. I'm working on building >> new infrastructure and my current thoughts are to minimize my TDM >> footprint. It would be useful to get a better feel if this is an overall >> trend or something local. > > You aren't imagining things. In fact, some large national networks have been designed to support solely ethernet. It comes down to cost, as always.... Speaking of which, what is the state of voip-over-cellular as essentially the last holdout of TDM? Will the new 4G stuff be able to support latencies, etc? Has the work on handovers-over-IP matured enough that it's viable? Mike From mike at mtcc.com Fri Mar 26 10:33:38 2010 From: mike at mtcc.com (Michael Thomas) Date: Fri, 26 Mar 2010 08:33:38 -0700 Subject: "Is TDM going the way of dial-up?" In-Reply-To: <20100326152628.GA4823@mara.org> References: <20100326152628.GA4823@mara.org> Message-ID: <4BACD3D2.20502@mtcc.com> On 03/26/2010 08:26 AM, Steve Meuse wrote: > Rick Ernst expunged (nanog at shreddedmail.com): > >> I'm wondering if others are seeing the same behavior, if it's >> market-dependant, or if I'm just imagining things. I'm working on building >> new infrastructure and my current thoughts are to minimize my TDM >> footprint. It would be useful to get a better feel if this is an overall >> trend or something local. > > You aren't imagining things. In fact, some large national networks have been designed to support solely ethernet. It comes down to cost, as always.... Speaking of which, what is the state of voip-over-cellular as essentially the last holdout of TDM? Will the new 4G stuff be able to support latencies, etc? Has the work on handovers-over-IP matured enough that it's viable? Mike From bclark at spectraaccess.com Fri Mar 26 10:34:57 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 26 Mar 2010 11:34:57 -0400 Subject: "Is TDM going the way of dial-up?" In-Reply-To: <20100326152628.GA4823@mara.org> References: <20100326152628.GA4823@mara.org> Message-ID: <4BACD421.2030209@spectraaccess.com> Steve Meuse wrote: I'm wondering if others are seeing the same behavior, if it's market-dependant, or if I'm just imagining things. I'm working on building new infrastructure and my current thoughts are to minimize my TDM footprint. It would be useful to get a better feel if this is an overall trend or something local. You aren't imagining things. In fact, some large national networks have been des igned to support solely ethernet. It comes down to cost, as always.... -Steve Actually, a lot of people would be shocked at just how much VoIP is now used to transport voice with TDM only occurring at the last mile and in many cases at the last foot. Anyone designing a voice infrastructure would be best to design it for VoIP. Your ROI is much much greater. If you need to use TDM, then do so only at the edge as close to the TDM equipment as possible. Of course if you are going to use VoIP through-out an infrastructure it certainly is a good idea to get familiar with QoS provisioning. Bret From streiner at cluebyfour.org Fri Mar 26 10:35:37 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 26 Mar 2010 11:35:37 -0400 (EDT) Subject: "Is TDM going the way of dial-up?" In-Reply-To: References: Message-ID: On Fri, 26 Mar 2010, Rick Ernst wrote: > I've noticed over the last 3 years or so that TDM, specifically T-1, access > and transport has been in a steady decline. Customers are moving to FTTH > and cable, or going WiMAX and Metro-Ethernet. Ethernet seems to have taken > an even bigger bite out of DS-3. The bigger pipes seem to favor ethernet. A > recent upgrade from OC-3 to GigE transport actually saved us a large chunk > of money. > > I'm wondering if others are seeing the same behavior, if it's > market-dependant, or if I'm just imagining things. I'm working on building > new infrastructure and my current thoughts are to minimize my TDM > footprint. It would be useful to get a better feel if this is an overall > trend or something local. I tend to think this is market dependent. In major population centers, TDM service may well be on the decline, but I'd suspect that Ethernet based services have a much lower penetration in areas with lower population densities. I don't see TDM going away entirely any time soon because it still comes in handy for things like out-of-band management, etc, plus nowadays there is lots of TDM gear on the secondary market that can be picked up dirt-cheap. jms From joelja at bogus.com Fri Mar 26 10:44:04 2010 From: joelja at bogus.com (joel jaeggli) Date: Fri, 26 Mar 2010 08:44:04 -0700 Subject: "Is TDM going the way of dial-up?" In-Reply-To: References: Message-ID: <4BACD644.5040803@bogus.com> On 3/26/2010 8:15 AM, Rick Ernst wrote: > I've noticed over the last 3 years or so that TDM, specifically T-1, access > and transport has been in a steady decline. Customers are moving to FTTH > and cable, or going WiMAX and Metro-Ethernet. Ethernet seems to have taken > an even bigger bite out of DS-3. The bigger pipes seem to favor ethernet. A > recent upgrade from OC-3 to GigE transport actually saved us a large chunk > of money. > > I'm wondering if others are seeing the same behavior, if it's > market-dependant, or if I'm just imagining things. I'm working on building > new infrastructure and my current thoughts are to minimize my TDM > footprint. It would be useful to get a better feel if this is an overall > trend or something local. > Why I think it comes down to is do you want to use frame-relay, atm, sdh and ethernet when you can just use ethernet? lan-phy ethernet has economies of scale that result in lower cost along virtually every dimension relative to the alternatives. > Thoughts? > > Thanks, > > From dylan.ebner at crlmed.com Fri Mar 26 10:45:27 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Fri, 26 Mar 2010 15:45:27 +0000 Subject: "Is TDM going the way of dial-up?" In-Reply-To: References: Message-ID: <017265BF3B9640499754DD48777C3D206857B0ECDB@MBX9.EXCHPROD.USA.NET> Funny thing about this is we have been steadily getting rid of all of our t1 and ds3 circuits and replacing them with metro-e or cable based services at much better price/Mbs. However, when we went to VOIP and wanted to do sip trunking with qwest, they needed to deliver this over t1, otherwise is wasn't cost effective. Dylan Ebner -----Original Message----- From: Rick Ernst [mailto:nanog at shreddedmail.com] Sent: Friday, March 26, 2010 10:16 AM To: nanog at nanog.org Subject: "Is TDM going the way of dial-up?" I've noticed over the last 3 years or so that TDM, specifically T-1, access and transport has been in a steady decline. Customers are moving to FTTH and cable, or going WiMAX and Metro-Ethernet. Ethernet seems to have taken an even bigger bite out of DS-3. The bigger pipes seem to favor ethernet. A recent upgrade from OC-3 to GigE transport actually saved us a large chunk of money. I'm wondering if others are seeing the same behavior, if it's market-dependant, or if I'm just imagining things. I'm working on building new infrastructure and my current thoughts are to minimize my TDM footprint. It would be useful to get a better feel if this is an overall trend or something local. Thoughts? Thanks, From lowen at pari.edu Fri Mar 26 10:45:18 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 26 Mar 2010 11:45:18 -0400 Subject: [OT] Old kit (was:Re: IP4 Space) In-Reply-To: <877585b01003241424y63c9e63bh1883cbe61c52eacc@mail.gmail.com> References: <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> Message-ID: <201003261145.18794.lowen@pari.edu> On Wednesday 24 March 2010 05:24:39 pm Michael Dillon wrote: > For comparison look at the z-80 CPU which powered the early desktop > computers. When the IBM PC came out, people thought that the Intel 8086 > would make the Z-80 obsolete. But it didn't. The Z-80 just disappeared > into all sorts of electronic > devices where it serves as a controller for some function, perhaps the > video display or the disk drive servos. And you can still buy them. Lots of DVD drives use embedded Z80's as controllers, including the dual-layer drive in my laptop. Never thought that my teenage years spent hacking Z80 machine code on a TRS-80 could produce a currently marketable skill.... Quick, Z80 joke coming.... Addr: 0000:21 00 00 01 FF FF 11 01 00 ED B0.......Will it finish? Same is true of MIPS and PowerPC, though. There are far more MIPS chips in routers than ever saw desktop use in SGI workstations; and while it might take a little while for Cisco's PowerPC driven routers' CPU's to outnumber all the PowerMacs our there, one day it will happen. And then all those PowerMac assembly language gurus might prove useful in the router side of the house..... From jolsen at devry.com Fri Mar 26 10:44:26 2010 From: jolsen at devry.com (Olsen, Jason) Date: Fri, 26 Mar 2010 10:44:26 -0500 Subject: "Is TDM going the way of dial-up?" In-Reply-To: References: Message-ID: <63AF18E6CB3D3A47A965A11168C9736F01ED810F@MAIL3P.dvuadmin.net> > From: Rick Ernst [mailto:nanog at shreddedmail.com] > an even bigger bite out of DS-3. The bigger pipes seem to favor > ethernet. A recent upgrade from OC-3 to GigE transport actually saved us a large > chunk of money. We recently had exactly the opposite experience, unfortunately. During relocation of our datacenter we asked our MPLS WAN provider to provide GigE transport rather than the multiple OC-3s we were using today. To us it seemed like it would be cheaper - GigE interfaces, even WAN-PHY rated ones, were orders of magnitude cheaper than SONET. Unfortunately the provider came back with absolutely outrageous costs for the port, claiming they had to do non-standard agreements with incumbents to provide the lines to us (despite the amount of circuits already in the site). This may be more a function of that particular provider, however. From smeuse at mara.org Fri Mar 26 10:53:25 2010 From: smeuse at mara.org (Steve Meuse) Date: Fri, 26 Mar 2010 11:53:25 -0400 Subject: "Is TDM going the way of dial-up?" In-Reply-To: <017265BF3B9640499754DD48777C3D206857B0ECDB@MBX9.EXCHPROD.USA.NET> References: <017265BF3B9640499754DD48777C3D206857B0ECDB@MBX9.EXCHPROD.USA.NET> Message-ID: <20100326155325.GB4823@mara.org> Dylan Ebner expunged (dylan.ebner at crlmed.com): > Funny thing about this is we have been steadily getting rid of all of our t1 and ds3 circuits and replacing them with metro-e or cable based services at much better price/Mbs. However, when we went to VOIP and wanted to do sip trunking with qwest, they needed to deliver this over t1, otherwise is wasn't cost effective. E911 was a sticky point for us. We ended up having to install some small boxes to do T1 handoff to our provider of choice, they didn't have any ethernet options (which we pushed for). -Steve From lowen at pari.edu Fri Mar 26 10:57:23 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 26 Mar 2010 11:57:23 -0400 Subject: IP4 Space In-Reply-To: <4B98597B.3060101@jsbc.cc> References: Message-ID: <201003261157.23601.lowen@pari.edu> On Wednesday 10 March 2010 09:46:19 pm Jim Burwell wrote: > On 3/10/2010 16:57, Owen DeLong wrote: > > The target really needs to be the CxOs and the management, > > especially in places where there is content facing the general > > public. Fortunately, Google, Yahoo, Netflix, etc. get it and have > > moved forward with IPv6. Some others are coming along. > True. CxOs can basically order it to be done. Fascinating thread; thanks to all for the many insights found here; this thread has made my personal archive, just like the other long one did. I've chosen to reply to this post, because it directly addresses me, in addition to the other two topical posts I just couldn't resist. So, let me give the insight from the CIO point of view, at least in terms of a non-profit organization. How do I know this PoV? I _am_ the CIO here, that's how. Here's my hypothetical reaction to a hypothetical network engineer coming to me with a good, solid, thorough, and compelling presentation on why we need to go to IPv6: "Hey, great presentation. Compelling arguments. But I have one question: will our existing gear that's not yet fully depreciated handle it? No? Sorry, won't happen. Not in this recession year; grants have been tight, and nobody wants to fund this kind of capex right now. Especially not since it hasn't yet been five years since that previous grant bought some of that equipment. No, we cannot afford to forklift upgrade now. Do whatever you can with what we have. Or, if we absolutely must upgrade, find the money in the bandwidth budget, and reduce our bandwidth if you have to do so. Oh, and one other thing: is our ISP supporting this IPv6 thing yet? No? Come back when they do, and when you figure out how to do this with our existing equipment, or find the money in the existing budget. If you'll excuse me, I have a meeting with the head of the server group, who says he needs funds for upgrading our server farm to something called vSphere 4. Says he can save us a couple of grand per month in power and cooling costs, and has a plan to use the savings to upgrade our website to something more interactive for our core stakeholders." Fact: many, if not most, businesses today are struggling to do basic things, at least in my area. IPv6 migration for many businesses is a desirable, not an essential, thing to do, at least right now, and especially if serious capex is required to do it. For some businesses, IPv6 addition is more of an annoyance than a desirable. So, many businesses, in today's economic climate, will be dragged into IPv6 kicking and screaming simply because it's going to be, in their eyes, dead cost. Unless there is either a significant value-add or cost reduction in the mid to long term, that is. Having more addresses is not enough. And thus, ISP's which serve those businesses really don't have sufficient economic reason to expend their own capex budgets down to the bone if the demand from their customers is low. At the CxO level, it's all about the money. Or the lack therof. In our case, yes, we're going to add IPv6 when it makes cents to do so. Misspelling intentional; but I do have a plan in place to roll it out quickly when needed, in no small part thanks to threads on NANOG and Cisco-NSP. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute From jdfalk-lists at cybernothing.org Fri Mar 26 11:03:54 2010 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Fri, 26 Mar 2010 09:03:54 -0700 Subject: Call for papers (Deadline Extended): ISP-10, USA, July 2010 In-Reply-To: <20100326133823.GA25408@gsp.org> References: <739582dd1003251658w68a0f3a5x3fac4d397503e128@mail.gmail.com> <20100326133823.GA25408@gsp.org> Message-ID: <822859D1-2BA0-43F7-AB63-003DB6259B9E@cybernothing.org> On Mar 26, 2010, at 6:38 AM, Rich Kulawiec wrote: > This is the same fake conference spammer who's been hitting a lot > of mailing lists and Usenet newsgroups -- best to blacklist the > sender address and the domain. Why is this fake conference still posting to NANOG? -- J.D. Falk Return Path Inc From jared at puck.nether.net Fri Mar 26 11:09:56 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 Mar 2010 12:09:56 -0400 Subject: "Is TDM going the way of dial-up?" In-Reply-To: <63AF18E6CB3D3A47A965A11168C9736F01ED810F@MAIL3P.dvuadmin.net> References: <63AF18E6CB3D3A47A965A11168C9736F01ED810F@MAIL3P.dvuadmin.net> Message-ID: On Mar 26, 2010, at 11:44 AM, Olsen, Jason wrote: >> From: Rick Ernst [mailto:nanog at shreddedmail.com] > > >> an even bigger bite out of DS-3. The bigger pipes seem to favor >> ethernet. A recent upgrade from OC-3 to GigE transport actually saved > us a large >> chunk of money. > > We recently had exactly the opposite experience, unfortunately. During > relocation of our datacenter we asked our MPLS WAN provider to provide > GigE transport rather than the multiple OC-3s we were using today. To us > it seemed like it would be cheaper - GigE interfaces, even WAN-PHY rated > ones, were orders of magnitude cheaper than SONET. Unfortunately the > provider came back with absolutely outrageous costs for the port, > claiming they had to do non-standard agreements with incumbents to > provide the lines to us (despite the amount of circuits already in the > site). > > This may be more a function of that particular provider, however. What I've been hearing rumors of is --- unregulated services (eg: gigaman, opteman) typically have a better price-point if you are going with the carrier of choice. TDM services (DSn/OCn) where there is a standard interconnection method tend to have higher costs than ethernet services, but are available when you have multiple carriers involved. (eg: VZ/MCI/XO/QWEST to SBC/ATT) territory. I see this as a two-fold issue, one, the carriers (ATT) are trying to provide an incentive for shifting away from the TDM based services. At the same time, it's more difficult to deliver service if you're not building to the market. I would take into account the filing that ATT gave to the FCC recently asking to set a sunset date for their POTS (read: TDM) network elements. This will allow them to leave the markets that are unprofitable, while delivering the unregulated (ethernet/IP) services where it currently is profitable. - Jared From frank at fttx.org Fri Mar 26 11:10:37 2010 From: frank at fttx.org (Frank A. Coluccio) Date: Fri, 26 Mar 2010 09:10:37 -0700 Subject: "Is TDM going the way of dial-up?" Message-ID: <20100326091037.96CC1642@resin07.mta.everyone.net> re: "what is the state of voip-over-cellular as essentially the last holdout of TDM? Will the new 4G stuff be able to support latencies, etc? Has the work on handovers-over-IP matured enough that it's viable?" One of the biggest hurdles in bringing Ethernet to mobile/cellular apps has been its lack of synchronous capabilities. This is now being overcome in a variety of ways, both IETF-instigated and at IEEE, and through some proprietary solutions where vendors are re-introducing system clocking. See my footer note that addresses this subject at the bottom of [1]this message. --- mike at mtcc.com wrote: From: Michael Thomas To: Steve Meuse Cc: nanog at nanog.org Subject: Re: "Is TDM going the way of dial-up?" Date: Fri, 26 Mar 2010 08:33:38 -0700 On 03/26/2010 08:26 AM, Steve Meuse wrote: > Rick Ernst expunged (nanog at shreddedmail.com): > >> I'm wondering if others are seeing the same behavior, if it's >> market-dependant, or if I'm just imagining things. I'm working on building >> new infrastructure and my current thoughts are to minimize my TDM >> footprint. It would be useful to get a better feel if this is an overall >> trend or something local. > > You aren't imagining things. In fact, some large national networks have been designed to support solely ethernet. It comes down to cost, as always.... Speaking of which, what is the state of voip-over-cellular as essentially the last holdout of TDM? Will the new 4G stuff be able to support latencies, etc? Has the work on handovers-over-IP matured enough that it's viable? Mike References 1. http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26408512 From lists at billfehring.com Fri Mar 26 11:10:37 2010 From: lists at billfehring.com (Bill Fehring) Date: Fri, 26 Mar 2010 09:10:37 -0700 Subject: Call for papers (Deadline Extended): ISP-10, USA, July 2010 In-Reply-To: <822859D1-2BA0-43F7-AB63-003DB6259B9E@cybernothing.org> References: <739582dd1003251658w68a0f3a5x3fac4d397503e128@mail.gmail.com> <20100326133823.GA25408@gsp.org> <822859D1-2BA0-43F7-AB63-003DB6259B9E@cybernothing.org> Message-ID: On Fri, Mar 26, 2010 at 09:03, J.D. Falk wrote: > Why is this fake conference still posting to NANOG? Maybe a motivational speaker at one of his past "conferences" told him never to give up? -Bill From frank at fttx.org Fri Mar 26 11:17:06 2010 From: frank at fttx.org (Frank A. Coluccio) Date: Fri, 26 Mar 2010 09:17:06 -0700 Subject: "Is TDM going the way of dial-up?" Message-ID: <20100326091706.96CC159A@resin07.mta.everyone.net> Apologies for the gibberish of my previous message. Here's The URL that never made it to the list that contains the article I referenced and my footer note: [1]http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26408512 --- frank at fttx.org wrote: From: "Frank A. Coluccio" To: "Michael Thomas" Cc: nanog at nanog.org Subject: Re: "Is TDM going the way of dial-up?" Date: Fri, 26 Mar 2010 09:10:37 -0700 re: "what is the state of voip-over-cellular as essentially the last holdout of TDM? Will the new 4G stuff be able to support latencies, etc? Has the work on handovers-over-IP matured enough that it's viable?" One of the biggest hurdles in bringing Ethernet to mobile/cellular apps has been its lack of synchronous capabilities. This is now being overcome in a variety of ways, both IETF-instigated and at IEEE, and through some proprietary solutions where vendors are re-introducing system clocking. See my footer note that addresses this subject at the bottom of [1]this message. --- mike at mtcc.com wrote: From: Michael Thomas To: Steve Meuse Cc: nanog at nanog.org Subject: Re: "Is TDM going the way of dial-up?" Date: Fri, 26 Mar 2010 08:33:38 -0700 On 03/26/2010 08:26 AM, Steve Meuse wrote: > Rick Ernst expunged (nanog at shreddedmail.com): > >> I'm wondering if others are seeing the same behavior, if it's >> market-dependant, or if I'm just imagining things. I'm working on building >> new infrastructure and my current thoughts are to minimize my TDM >> footprint. It would be useful to get a better feel if this is an overall >> trend or something local. > > You aren't imagining things. In fact, some large national networks have been designed to support solely ethernet. It comes down to cost, as always.... Speaking of which, what is the state of voip-over-cellular as essentially the last holdout of TDM? Will the new 4G stuff be able to support latencies, etc? Has the work on handovers-over-IP matured enough that it's viable? Mike References 1. http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26408512 References 1. http://siliconinvestor.advfn.com/readmsg.aspx?msgid=26408512 From marka at isc.org Fri Mar 26 11:17:04 2010 From: marka at isc.org (Mark Andrews) Date: Sat, 27 Mar 2010 03:17:04 +1100 Subject: IPv4 ANYCAST setup In-Reply-To: Your message of "Fri, 26 Mar 2010 09:52:48 EDT." <4828.1269611568@localhost> References: <4BACB4D3.60003@internetx.com> <4BACB585.5040805@spaghetti.zurich.ibm.com> <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> <4828.1269611568@localhost> Message-ID: <201003261617.o2QGH4PN018839@drugs.dv.isc.org> In message <4828.1269611568 at localhost>, Valdis.Kletnieks at vt.edu writes: > --==_Exmh_1269611568_4209P > Content-Type: text/plain; charset=us-ascii > > On Fri, 26 Mar 2010 09:40:39 EDT, Max Larson Henry said: > > > - Yes but as for DNS, anycast is essentially used for user requests (UDP) > > not to perform zone transfer(TCP). > > DNS uses TCP for more than just XFR. For instance, if you're running a > resolver that doesn't do EDNS0, and you hit an (increasingly common) DNSSEC > signed reply, it's going to be over 512 bytes and the lack of EDNS0 will > cause it to re-ask via TCP. DNSSEC depends on EDNS and DO being set in the EDNS OPT record, so won't get DNSSEC records, except in response to * queries, for non EDNS queries. > Just mentioning it because the sort of sites that think TCP==XFR are the > sort most likely to be running firewalls that munch the EDNS0 bits, and > are setting themselves up for big surprises in the very near future. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From msokolov at ivan.Harhan.ORG Fri Mar 26 11:43:23 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Fri, 26 Mar 2010 16:43:23 GMT Subject: "Is TDM going the way of dial-up?" Message-ID: <1003261643.AA01673@ivan.Harhan.ORG> Rick Ernst wrote: > I've noticed over the last 3 years or so that TDM, specifically T-1, access > and transport has been in a steady decline. Customers are moving to FTTH > and cable, or going WiMAX and Metro-Ethernet. Ethernet seems to have taken > an even bigger bite out of DS-3. The bigger pipes seem to favor ethernet. A > recent upgrade from OC-3 to GigE transport actually saved us a large chunk > of money. > > I'm wondering if others are seeing the same behavior, if it's > market-dependant, or if I'm just imagining things. Unfortunately what you are seeing is indeed where the world is going, and it is extremely painful to watch. My personal preference is the direct opposite of that: Ethernet for non-LAN use is my very antithesis, I hate it to the core of my being. V.35/HDLC forever for me! I will continue using HDLC over traditional synchronous serial WAN media for as long as I am alive. MS P.S. This message is being sent from a VAX running a variant of 4.3BSD (Quasijarus). Almost the entire ARPA Internet software stack that's running on my VAXen is mostly unchanged from how it was in 1988. From jabley at hopcount.ca Fri Mar 26 12:00:08 2010 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 26 Mar 2010 10:00:08 -0700 Subject: IPv4 ANYCAST setup In-Reply-To: <4BACB4D3.60003@internetx.com> References: <4BACB4D3.60003@internetx.com> Message-ID: <8F93CBE8-A8CB-47EC-8D6C-4C70FB83B24E@hopcount.ca> On 2010-03-26, at 06:21, InterNetX - Lutz Muehlig wrote: > has someone experience in anycast ipv4 networks (to support DNS)? This is a general reference that tries hard not to be DNS-specific: http://www.ietf.org/rfc/rfc4786.txt These are two papers written whilst at ISC describing many aspects of how ISC did what you are talking about with the F root nameserver: http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt http://ftp.isc.org/isc/pubs/tn/isc-tn-2004-1.txt This is a rendering of the OSPF/IGP anycast tech note above as a USENIX paper: http://www.usenix.org/events/usenix04/tech/sigs/full_papers/abley/abley.pdf This is a more sarcastic article about anycast that was published in the USENIX publication ;login: http://www.usenix.org/publications/login/2008-02/openpdfs/abley.pdf This is a presentation about building nameserver clusters that was presented at NANOG 34: http://nanog.org/meetings/nanog34/presentations/abley.nameservers.pdf Joe From owen at delong.com Fri Mar 26 12:01:30 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 10:01:30 -0700 Subject: IPv4 ANYCAST setup In-Reply-To: <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> References: <4BACB4D3.60003@internetx.com> <4BACB585.5040805@spaghetti.zurich.ibm.com> <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> Message-ID: On Mar 26, 2010, at 6:40 AM, Max Larson Henry wrote: >>> has someone experience in anycast ipv4 networks (to support DNS)? >> >> "Never been done" "Dangerous" "TCP does not work" etc etc etc. >> > > - Yes but as for DNS, anycast is essentially used for user requests > (UDP) > not to perform zone transfer(TCP). > > -M The number of DNS queries for user requests that are in UDP in IPv4 is nearly all. When you start seeing hosts with more than a couple of AAAA records, you will start seeing more user requests in TCP. FWIW, World of Warcraft authentication actually involves some hosts with enough A records to require TCP. Owen From jabley at hopcount.ca Fri Mar 26 12:06:02 2010 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 26 Mar 2010 10:06:02 -0700 Subject: IPv4 ANYCAST setup In-Reply-To: <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> References: <4BACB4D3.60003@internetx.com> <4BACB585.5040805@spaghetti.zurich.ibm.com> <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> Message-ID: <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> On 2010-03-26, at 06:40, Max Larson Henry wrote: >>> has someone experience in anycast ipv4 networks (to support DNS)? >> >> "Never been done" "Dangerous" "TCP does not work" etc etc etc. > > - Yes but as for DNS, anycast is essentially used for user requests (UDP) > not to perform zone transfer(TCP). As others have mentioned, TCP can generally be used for any DNS query, not just AXFR. This becomes more important as DNS responses get bigger, e.g. responses from root servers due to the root zone containing DNSSEC information, see . If your nameserver can't be reached over TCP, it's likely that there are people who can't talk to your nameserver. This means your DNS records can't be found. This is a bad thing. Here, in glorious LOLCAPS: ALWAYS MAKE SURE YOUR DNS SERVER CAN BE REACHED OVER TCP TCP IS NOT JUST FOR ZONE TRANSFERS FIX YOUR FIREWALLS :-) Joe From owen at delong.com Fri Mar 26 12:04:41 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 10:04:41 -0700 Subject: IPv4 ANYCAST setup In-Reply-To: <4BACBCC8.3020409@spaghetti.zurich.ibm.com> References: <4BACB4D3.60003@internetx.com> <4BACB585.5040805@spaghetti.zurich.ibm.com> <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> <4BACBCC8.3020409@spaghetti.zurich.ibm.com> Message-ID: <4C12AD08-DCF9-40E9-ACCA-53A1142BF5AB@delong.com> On Mar 26, 2010, at 6:55 AM, Jeroen Massar wrote: > Max Larson Henry wrote: >> >>> has someone experience in anycast ipv4 networks (to support DNS)? >> >> "Never been done" "Dangerous" "TCP does not work" etc etc etc. >> >> >> - Yes but as for DNS, anycast is essentially used for user requests >> (UDP) not to perform zone transfer(TCP). > > Also that would work, unless you have a very unstable routing table > that > makes the node swap all the time. > It doesn't require an unstable routing table. There is a small set of locations that could hit routers with multipath that may "balance" the anycast packets down divergent paths. Essentially, these are the topological midpoints between any two (or more) anycast servers. Owen From jabley at hopcount.ca Fri Mar 26 12:15:11 2010 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 26 Mar 2010 10:15:11 -0700 Subject: IPv4 ANYCAST setup In-Reply-To: <4C12AD08-DCF9-40E9-ACCA-53A1142BF5AB@delong.com> References: <4BACB4D3.60003@internetx.com> <4BACB585.5040805@spaghetti.zurich.ibm.com> <90155a1e1003260640o30471802u884af64208873684@mail.gmail.com> <4BACBCC8.3020409@spaghetti.zurich.ibm.com> <4C12AD08-DCF9-40E9-ACCA-53A1142BF5AB@delong.com> Message-ID: <6AE1723B-A841-4747-A5EF-4E4A61D78321@hopcount.ca> On 2010-03-26, at 10:04, Owen DeLong wrote: > It doesn't require an unstable routing table. There is a small set of > locations that could hit routers with multipath that may "balance" > the anycast packets down divergent paths. > > Essentially, these are the topological midpoints between any two > (or more) anycast servers. As with most things, there are risks and benefits to distributing services using anycast. There are also risks and benefits from not doing so. Far too many words to bother people with here on this list, but the ;login: article I include a link to earlier () attempts to discuss ways in which people can decide whether anycast suits their own particular circumstances ("Horses for Courses"). Joe From owen at delong.com Fri Mar 26 12:16:44 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 10:16:44 -0700 Subject: [OT] Old kit (was:Re: IP4 Space) In-Reply-To: <201003261145.18794.lowen@pari.edu> References: <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <201003261145.18794.lowen@pari.edu> Message-ID: <04E18D2D-CE07-4D36-889A-3933BC23339C@delong.com> On Mar 26, 2010, at 8:45 AM, Lamar Owen wrote: > On Wednesday 24 March 2010 05:24:39 pm Michael Dillon wrote: >> For comparison look at the z-80 CPU which powered the early desktop >> computers. When the IBM PC came out, people thought that the Intel >> 8086 >> would make the Z-80 obsolete. But it didn't. The Z-80 just >> disappeared >> into all sorts of electronic >> devices where it serves as a controller for some function, perhaps >> the >> video display or the disk drive servos. And you can still buy them. > > Lots of DVD drives use embedded Z80's as controllers, including the > dual-layer > drive in my laptop. Never thought that my teenage years spent > hacking Z80 > machine code on a TRS-80 could produce a currently marketable > skill.... > > Quick, Z80 joke coming.... Addr: 0000:21 00 00 01 FF FF 11 01 00 ED > B0.......Will it finish? > > Same is true of MIPS and PowerPC, though. There are far more MIPS > chips in > routers than ever saw desktop use in SGI workstations; and while it > might take > a little while for Cisco's PowerPC driven routers' CPU's to > outnumber all the > PowerMacs our there, one day it will happen. > > And then all those PowerMac assembly language gurus might prove > useful in the > router side of the house..... The Juniper SRX-100 appears to have a MIPS or MIPS-like chip in it called an Octeon. Owen From joelja at bogus.com Fri Mar 26 12:23:42 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 26 Mar 2010 10:23:42 -0700 Subject: [OT] Old kit In-Reply-To: <04E18D2D-CE07-4D36-889A-3933BC23339C@delong.com> References: <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <201003261145.18794.lowen@pari.edu> <04E18D2D-CE07-4D36-889A-3933BC23339C@delong.com> Message-ID: <4BACED9E.2080200@bogus.com> On 03/26/2010 10:16 AM, Owen DeLong wrote: > > On Mar 26, 2010, at 8:45 AM, Lamar Owen wrote: > >> On Wednesday 24 March 2010 05:24:39 pm Michael Dillon wrote: >>> For comparison look at the z-80 CPU which powered the early desktop >>> computers. When the IBM PC came out, people thought that the Intel 8086 >>> would make the Z-80 obsolete. But it didn't. The Z-80 just disappeared >>> into all sorts of electronic >>> devices where it serves as a controller for some function, perhaps the >>> video display or the disk drive servos. And you can still buy them. >> >> Lots of DVD drives use embedded Z80's as controllers, including the >> dual-layer >> drive in my laptop. Never thought that my teenage years spent hacking >> Z80 >> machine code on a TRS-80 could produce a currently marketable skill.... >> >> Quick, Z80 joke coming.... Addr: 0000:21 00 00 01 FF FF 11 01 00 ED >> B0.......Will it finish? >> >> Same is true of MIPS and PowerPC, though. There are far more MIPS >> chips in >> routers than ever saw desktop use in SGI workstations; and while it >> might take >> a little while for Cisco's PowerPC driven routers' CPU's to outnumber >> all the >> PowerMacs our there, one day it will happen. >> >> And then all those PowerMac assembly language gurus might prove useful >> in the >> router side of the house..... > > The Juniper SRX-100 appears to have a MIPS or MIPS-like chip in it called > an Octeon. Cavium is mips arch... so are npu's or control plane processors from RMI, Broadcom, Atheros, Marvell etc. > Owen > > From owen at delong.com Fri Mar 26 12:31:33 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 10:31:33 -0700 Subject: IP4 Space In-Reply-To: <201003261157.23601.lowen@pari.edu> References: <201003261157.23601.lowen@pari.edu> Message-ID: <7BD730BB-3F77-41B2-AA89-F47C4B60AA2B@delong.com> On Mar 26, 2010, at 8:57 AM, Lamar Owen wrote: > On Wednesday 10 March 2010 09:46:19 pm Jim Burwell wrote: >> On 3/10/2010 16:57, Owen DeLong wrote: >>> The target really needs to be the CxOs and the management, >>> especially in places where there is content facing the general >>> public. Fortunately, Google, Yahoo, Netflix, etc. get it and have >>> moved forward with IPv6. Some others are coming along. > >> True. CxOs can basically order it to be done. > > Fascinating thread; thanks to all for the many insights found here; > this > thread has made my personal archive, just like the other long one > did. I've > chosen to reply to this post, because it directly addresses me, in > addition to > the other two topical posts I just couldn't resist. > > So, let me give the insight from the CIO point of view, at least in > terms of a > non-profit organization. How do I know this PoV? I _am_ the CIO > here, that's > how. Here's my hypothetical reaction to a hypothetical network > engineer > coming to me with a good, solid, thorough, and compelling > presentation on why > we need to go to IPv6: > > "Hey, great presentation. Compelling arguments. But I have one > question: > will our existing gear that's not yet fully depreciated handle it? > No? Sorry, > won't happen. Not in this recession year; grants have been tight, > and nobody > wants to fund this kind of capex right now. Especially not since it > hasn't > yet been five years since that previous grant bought some of that > equipment. > No, we cannot afford to forklift upgrade now. Do whatever you can > with what we > have. Or, if we absolutely must upgrade, find the money in the > bandwidth > budget, and reduce our bandwidth if you have to do so. Oh, and one > other > thing: is our ISP supporting this IPv6 thing yet? No? Come back > when they > do, and when you figure out how to do this with our existing > equipment, or find > the money in the existing budget. If you'll excuse me, I have a > meeting with > the head of the server group, who says he needs funds for upgrading > our server > farm to something called vSphere 4. Says he can save us a couple of > grand per > month in power and cooling costs, and has a plan to use the savings > to upgrade > our website to something more interactive for our core stakeholders." > _IF_ your gear is less than 5 years old, then, the answer probably isn't "no". Most gear that is less than 5 years old WILL support IPv6. However, even in cases where it won't, it is better to move forward with IPv6 where you can and have islands of IPv4-only on your network than to wait until you have a complete IPv6 solution. The other key point to take away... If your engineer is telling you that your ISP isn't ready yet, it's time for you to give your engineer your backing at telling the ISP that IPv6 is a requirement for contract renewal. You should ask your server guy how he plans to talk to your core stakeholders when they can't get IPv4 any more. > Fact: many, if not most, businesses today are struggling to do basic > things, > at least in my area. IPv6 migration for many businesses is a > desirable, not > an essential, thing to do, at least right now, and especially if > serious capex > is required to do it. For some businesses, IPv6 addition is more of > an > annoyance than a desirable. So, many businesses, in today's > economic climate, > will be dragged into IPv6 kicking and screaming simply because it's > going to > be, in their eyes, dead cost. Unless there is either a significant > value-add > or cost reduction in the mid to long term, that is. Having more > addresses is > not enough. And thus, ISP's which serve those businesses really > don't have > sufficient economic reason to expend their own capex budgets down to > the bone if > the demand from their customers is low. > Here we come to the essential part of this which is hard to communicate. It's kind of like flying up a box canyon (yes, I know flying up box canyons is best avoided, but, bear with me)... There comes a point, well before it is known to the passengers, where the canyon becomes too narrow to make a maneuver known as a "canyon turn" which is a _VERY_ tight course reversal and your best hope of survival in a situation where you cannot out-climb the canyon walls. This point may not be known to the inexperienced pilot, either, and, there are plenty of aircraft dotting the slopes of various canyons to prove that. If you fly beyond that point without making the turn, then, in essence, even though nobody on the airplane knows it, the crash has already occurred. It will take time to deploy IPv6. If you start when IPv6 is essential to your business continuity, then, your business will be suffering until your deployment is completed. > At the CxO level, it's all about the money. Or the lack therof. > How much less money will you have when donors can not reach your website or have a poor user experience doing so? > In our case, yes, we're going to add IPv6 when it makes cents to do > so. > Misspelling intentional; but I do have a plan in place to roll it > out quickly > when needed, in no small part thanks to threads on NANOG and Cisco- > NSP. That's a good thing. Hopefully you pull the trigger soon enough that quickly is fast enough. The key point here is to at least have a plan that gets IPv6 deployed to the important parts of your infrastructure before you start losing business (with the full understanding that plans never execute as fast as planned). Owen From jmamodio at gmail.com Fri Mar 26 12:42:57 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 26 Mar 2010 12:42:57 -0500 Subject: [OT] Old kit (was:Re: IP4 Space) In-Reply-To: <201003261145.18794.lowen@pari.edu> References: <75cb24521003181820k4d307d3eid7e25508c69ce82c@mail.gmail.com> <20100324031611.GB4441@vacation.karoshi.com.> <877585b01003241424y63c9e63bh1883cbe61c52eacc@mail.gmail.com> <201003261145.18794.lowen@pari.edu> Message-ID: <202705b1003261042u42c73e9ek965d54377738c68f@mail.gmail.com> > Same is true of MIPS and PowerPC, though. ?There are far more MIPS chips in > routers than ever saw desktop use in SGI workstations; and while it might take > a little while for Cisco's PowerPC driven routers' CPU's to outnumber all the > PowerMacs our there, one day it will happen. MIPS are now used as a core in many microcontrollers as an alternative to ARM. I do development using Microchip's PIC32MX which is based on a 32-bits MIPS M4K core, beautiful piece of silicon and very good performance. I have a small collection of old gear, somewhere I've a couple of the old Sinclair Spectrum Z-80 with 16KB RAM !!, amazing that one used to program those things with 4K and some kids today don't know how to get started if they don't have a couple of GB's in APIs. Cheers Jorge From marka at isc.org Fri Mar 26 13:10:45 2010 From: marka at isc.org (Mark Andrews) Date: Sat, 27 Mar 2010 05:10:45 +1100 Subject: IP4 Space In-Reply-To: Your message of "Fri, 26 Mar 2010 11:57:23 EDT." <201003261157.23601.lowen@pari.edu> References: <4B98597B.3060101@jsbc.cc> <201003261157.23601.lowen@pari.edu> Message-ID: <201003261810.o2QIAjde022222@drugs.dv.isc.org> In message <201003261157.23601.lowen at pari.edu>, Lamar Owen writes: > On Wednesday 10 March 2010 09:46:19 pm Jim Burwell wrote: > > On 3/10/2010 16:57, Owen DeLong wrote: > > > The target really needs to be the CxOs and the management, > > > especially in places where there is content facing the general > > > public. Fortunately, Google, Yahoo, Netflix, etc. get it and have > > > moved forward with IPv6. Some others are coming along. > > > True. CxOs can basically order it to be done. > > Fascinating thread; thanks to all for the many insights found here; this > thread has made my personal archive, just like the other long one did. I've > chosen to reply to this post, because it directly addresses me, in addition t > o > the other two topical posts I just couldn't resist. > > So, let me give the insight from the CIO point of view, at least in terms of > a > non-profit organization. How do I know this PoV? I _am_ the CIO here, that' > s > how. Here's my hypothetical reaction to a hypothetical network engineer > coming to me with a good, solid, thorough, and compelling presentation on why > > we need to go to IPv6: > > "Hey, great presentation. Compelling arguments. But I have one question: > will our existing gear that's not yet fully depreciated handle it? No? Sorry > , > won't happen. Not in this recession year; grants have been tight, and nobody > > wants to fund this kind of capex right now. Especially not since it hasn't > yet been five years since that previous grant bought some of that equipment. What percentage of your equipment already supports IPv6? Most 5 year old pieces of equipement already have IPv6 support. It just needs to be enabled. > No, we cannot afford to forklift upgrade now. IPv6 is *not* a "forklift upgrade". It's a parallel deployment that can be done incrementally one service at a time. The first step is to get the bits to you. > Do whatever you can with what we > have. Or, if we absolutely must upgrade, find the money in the bandwidth > budget, and reduce our bandwidth if you have to do so. Turning on IPv6 doesn't really affect the amount of bandwith you use. > Oh, and one other > thing: is our ISP supporting this IPv6 thing yet? No? You don't need your ISP to support IPv6 to turn on IPv6. You just need a IPv4 path to someone who does support IPv6. > Come back when they > do, and when you figure out how to do this with our existing equipment, or fi > nd > the money in the existing budget. If you'll excuse me, I have a meeting with > > the head of the server group, who says he needs funds for upgrading our serve > r > farm to something called vSphere 4. Says he can save us a couple of grand pe > r > month in power and cooling costs, and has a plan to use the savings to upgrad > e > our website to something more interactive for our core stakeholders." > > Fact: many, if not most, businesses today are struggling to do basic things, > at least in my area. IPv6 migration for many businesses is a desirable, not > an essential, thing to do, at least right now, and especially if serious cape > x > is required to do it. For some businesses, IPv6 addition is more of an > annoyance than a desirable. So, many businesses, in today's economic climate > , > will be dragged into IPv6 kicking and screaming simply because it's going to > be, in their eyes, dead cost. Unless there is either a significant value-add > > or cost reduction in the mid to long term, that is. Having more addresses is > > not enough. And thus, ISP's which serve those businesses really don't have > sufficient economic reason to expend their own capex budgets down to the bone > if the demand from their customers is low. Most IPv4 only ISPs are already carrying IPv6 traffic. It's just encapsulated by one of the early deployment methods. > At the CxO level, it's all about the money. Or the lack therof. Turn on IPv6 should be a $0 cost. Fully supporting IPv6 on all the services you offer will have some cost. > In our case, yes, we're going to add IPv6 when it makes cents to do so. > Misspelling intentional; but I do have a plan in place to roll it out quickly > > when needed, in no small part thanks to threads on NANOG and Cisco-NSP. > -- > Lamar Owen > Chief Information Officer > Pisgah Astronomical Research Institute > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Valdis.Kletnieks at vt.edu Fri Mar 26 13:32:06 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 26 Mar 2010 14:32:06 -0400 Subject: "Is TDM going the way of dial-up?" In-Reply-To: Your message of "Fri, 26 Mar 2010 11:35:37 EDT." References: Message-ID: <16309.1269628326@localhost> On Fri, 26 Mar 2010 11:35:37 EDT, "Justin M. Streiner" said: > I don't see TDM going away entirely any time soon because it still comes > in handy for things like out-of-band management, etc, plus nowadays there > is lots of TDM gear on the secondary market that can be picked up > dirt-cheap. All the same, the price of gear dropping through the floor on the secondary market is usually a pretty good indication that the technology is played out, because supply-and-demand says that demand for the gear will keep the price propped up until the demand goes away - which usually means the tech is played out. Anybody got a counter-example? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From streiner at cluebyfour.org Fri Mar 26 13:41:32 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 26 Mar 2010 14:41:32 -0400 (EDT) Subject: "Is TDM going the way of dial-up?" In-Reply-To: <16309.1269628326@localhost> References: <16309.1269628326@localhost> Message-ID: On Fri, 26 Mar 2010, Valdis.Kletnieks at vt.edu wrote: > On Fri, 26 Mar 2010 11:35:37 EDT, "Justin M. Streiner" said: > >> I don't see TDM going away entirely any time soon because it still comes >> in handy for things like out-of-band management, etc, plus nowadays there >> is lots of TDM gear on the secondary market that can be picked up >> dirt-cheap. > > All the same, the price of gear dropping through the floor on the secondary > market is usually a pretty good indication that the technology is played out, > because supply-and-demand says that demand for the gear will keep the price > propped up until the demand goes away - which usually means the tech is > played out. I don't know too many people who build their out-of-band management networks out of the latest and greatest gear. There are tons of Cisco 2511s, 2611s, etc that have been given second lives as terminal servers. There are also lots of areas where Ethernet transports are either ridiculously expensive because the carrier wants me to partially subsidize their initial build costs, or it's just flat-out not available. There are also areas where I've seen it delivered over n x STS-1's bonded together, so the Ethernet frames are still riding over a SONET transport in many cases. jms From eesslinger at fpu-tn.com Fri Mar 26 13:53:46 2010 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Fri, 26 Mar 2010 13:53:46 -0500 Subject: Need to talk to Charter email contact Message-ID: Good afternoon, I'm looking for some cluefull help from someone at Charter. I've got a static IP customer unable to deliver mail to charter.net customers and I can get no help trying to get in through the 'front door' of tech support. I've been forwarded to the residential spanish technicians 3 times so far to get rid of me. Customer is unable to get any connection to ib1.charter.net on port 25 thus is unable to use the unblock at charter.net method of clearing this up. The few people I've talked to that understand what I'm talking about say that his connection timing out is 'impossible to be an issue on the Charter side', but there is no block preventing his email on our side (and he can successfully send to aol, bellsouth, hotmail, gmail, yahoo, comcast, etc..) DNS is configured with mx, forward and reverse records properly setup. Can contact me off list by phone or email. Thanks in advance. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 ________________________________ This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From cscora at apnic.net Fri Mar 26 13:54:23 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Mar 2010 04:54:23 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201003261854.o2QIsOHf015484@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 27 Mar, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 316354 Prefixes after maximum aggregation: 146166 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 153886 Total ASes present in the Internet Routing Table: 33654 Prefixes per ASN: 9.40 Origin-only ASes present in the Internet Routing Table: 29228 Origin ASes announcing only one prefix: 14274 Transit ASes present in the Internet Routing Table: 4426 Transit-only ASes present in the Internet Routing Table: 107 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 28 Max AS path prepend of ASN (28009) 24 Prefixes from unregistered ASNs in the Routing Table: 1005 Unregistered ASNs in the Routing Table: 155 Number of 32-bit ASNs allocated by the RIRs: 496 Prefixes from 32-bit ASNs in the Routing Table: 511 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 224 Number of addresses announced to Internet: 2207844992 Equivalent to 131 /8s, 153 /16s and 10 /24s Percentage of available address space announced: 59.6 Percentage of allocated address space announced: 66.2 Percentage of available address space allocated: 90.0 Percentage of address space in use by end-sites: 81.8 Total number of prefixes smaller than registry allocations: 151722 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 75992 Total APNIC prefixes after maximum aggregation: 26357 APNIC Deaggregation factor: 2.88 Prefixes being announced from the APNIC address blocks: 72662 Unique aggregates announced from the APNIC address blocks: 31966 APNIC Region origin ASes present in the Internet Routing Table: 3984 APNIC Prefixes per ASN: 18.24 APNIC Region origin ASes announcing only one prefix: 1094 APNIC Region transit ASes present in the Internet Routing Table: 618 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 505653824 Equivalent to 30 /8s, 35 /16s and 170 /24s Percentage of available APNIC address space announced: 79.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 132383 Total ARIN prefixes after maximum aggregation: 68542 ARIN Deaggregation factor: 1.93 Prefixes being announced from the ARIN address blocks: 105593 Unique aggregates announced from the ARIN address blocks: 40196 ARIN Region origin ASes present in the Internet Routing Table: 13605 ARIN Prefixes per ASN: 7.76 ARIN Region origin ASes announcing only one prefix: 5276 ARIN Region transit ASes present in the Internet Routing Table: 1342 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 724613536 Equivalent to 43 /8s, 48 /16s and 185 /24s Percentage of available ARIN address space announced: 61.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 72416 Total RIPE prefixes after maximum aggregation: 42364 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 65475 Unique aggregates announced from the RIPE address blocks: 43222 RIPE Region origin ASes present in the Internet Routing Table: 14273 RIPE Prefixes per ASN: 4.59 RIPE Region origin ASes announcing only one prefix: 7392 RIPE Region transit ASes present in the Internet Routing Table: 2129 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 419880096 Equivalent to 25 /8s, 6 /16s and 220 /24s Percentage of available RIPE address space announced: 78.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 28095 Total LACNIC prefixes after maximum aggregation: 6652 LACNIC Deaggregation factor: 4.22 Prefixes being announced from the LACNIC address blocks: 26431 Unique aggregates announced from the LACNIC address blocks: 13655 LACNIC Region origin ASes present in the Internet Routing Table: 1258 LACNIC Prefixes per ASN: 21.01 LACNIC Region origin ASes announcing only one prefix: 415 LACNIC Region transit ASes present in the Internet Routing Table: 214 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 28 Number of LACNIC addresses announced to Internet: 71750144 Equivalent to 4 /8s, 70 /16s and 210 /24s Percentage of available LACNIC address space announced: 71.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6721 Total AfriNIC prefixes after maximum aggregation: 1812 AfriNIC Deaggregation factor: 3.71 Prefixes being announced from the AfriNIC address blocks: 5069 Unique aggregates announced from the AfriNIC address blocks: 1522 AfriNIC Region origin ASes present in the Internet Routing Table: 350 AfriNIC Prefixes per ASN: 14.48 AfriNIC Region origin ASes announcing only one prefix: 97 AfriNIC Region transit ASes present in the Internet Routing Table: 77 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 14921216 Equivalent to 0 /8s, 227 /16s and 174 /24s Percentage of available AfriNIC address space announced: 44.5 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1836 8405 476 Korea Telecom (KIX) 17488 1306 134 133 Hathway IP Over Cable Interne 4755 1292 288 140 TATA Communications formerly 4134 1030 20317 398 CHINANET-BACKBONE 7545 1027 199 101 TPG Internet Pty Ltd 9583 1001 75 503 Sify Limited 17974 949 281 28 PT TELEKOMUNIKASI INDONESIA 18101 907 220 46 Reliance Infocom Ltd Internet 24560 865 303 166 Bharti Airtel Ltd., Telemedia 4808 844 1585 214 CNCGROUP IP network: China169 Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4057 3842 311 bellsouth.net, inc. 4323 3784 1083 394 Time Warner Telecom 1785 1777 698 131 PaeTec Communications, Inc. 7018 1564 5756 1001 AT&T WorldNet Services 20115 1529 1497 655 Charter Communications 2386 1324 616 934 AT&T Data Communications Serv 3356 1233 10952 424 Level 3 Communications, LLC 6478 1176 247 158 AT&T Worldnet Services 11492 1146 222 14 Cable One 22773 1132 2604 70 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 610 56 6 United Telecom of Georgia 3292 448 1899 390 TDC Tele Danmark 30890 436 100 202 Evolva Telecom 702 423 1870 335 UUNET - Commercial IP service 8551 400 355 36 Bezeq International 8866 392 117 18 Bulgarian Telecommunication C 3320 363 7072 317 Deutsche Telekom AG 3301 355 1413 316 TeliaNet Sweden 3215 347 3206 103 France Telecom Transpac 12479 328 576 5 Uni2 Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1537 2892 237 UniNet S.A. de C.V. 10620 1028 229 156 TVCABLE BOGOTA 28573 951 729 80 NET Servicos de Comunicao S.A 7303 693 363 102 Telecom Argentina Stet-France 22047 545 310 15 VTR PUNTO NET S.A. 18881 523 268 11 Global Village Telecom 6503 509 168 191 AVANTEL, S.A. 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 454 195 69 Empresa Nacional de Telecomun 11172 445 99 70 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 969 445 10 TEDATA 24863 704 144 41 LINKdotNET AS number 36992 557 121 167 Etisalat MISR 3741 274 853 233 The Internet Solution 33776 262 14 11 Starcomms Nigeria Limited 2018 212 215 122 Tertiary Education Network 6713 177 167 12 Itissalat Al-MAGHRIB 29571 171 19 9 Ci Telecom Autonomous system 24835 138 78 11 RAYA Telecom - Egypt 29975 133 506 14 Vodacom Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4057 3842 311 bellsouth.net, inc. 4323 3784 1083 394 Time Warner Telecom 4766 1836 8405 476 Korea Telecom (KIX) 1785 1777 698 131 PaeTec Communications, Inc. 7018 1564 5756 1001 AT&T WorldNet Services 8151 1537 2892 237 UniNet S.A. de C.V. 20115 1529 1497 655 Charter Communications 2386 1324 616 934 AT&T Data Communications Serv 17488 1306 134 133 Hathway IP Over Cable Interne 4755 1292 288 140 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3784 3390 Time Warner Telecom 1785 1777 1646 PaeTec Communications, Inc. 4766 1836 1360 Korea Telecom (KIX) 8151 1537 1300 UniNet S.A. de C.V. 17488 1306 1173 Hathway IP Over Cable Interne 4755 1292 1152 TATA Communications formerly 11492 1146 1132 Cable One 22773 1132 1062 Cox Communications, Inc. 18566 1059 1049 Covad Communications 6478 1176 1018 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.0.0.0/16 12654 RIPE NCC RIS Project 2.1.0.0/21 12654 RIPE NCC RIS Project 2.1.24.0/24 12654 RIPE NCC RIS Project 41.73.192.0/19 36930 ZanZibar Telecom 41.190.64.0/22 28683 Office des Postes et telecomm 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.220.144.0/20 36918 ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 36918 ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.24.0/22 25747 VSC Satellite Co Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:25 /11:66 /12:191 /13:392 /14:675 /15:1240 /16:10998 /17:5204 /18:8810 /19:18216 /20:22229 /21:22310 /22:28961 /23:28657 /24:165416 /25:962 /26:1202 /27:610 /28:136 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2623 4057 bellsouth.net, inc. 4323 2348 3784 Time Warner Telecom 4766 1475 1836 Korea Telecom (KIX) 1785 1241 1777 PaeTec Communications, Inc. 17488 1060 1306 Hathway IP Over Cable Interne 11492 1056 1146 Cable One 18566 1040 1059 Covad Communications 7018 941 1564 AT&T WorldNet Services 10620 934 1028 TVCABLE BOGOTA 8452 873 969 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 2:1 4:13 8:253 12:2002 13:10 15:22 16:3 17:8 20:26 24:1374 27:2 32:48 33:12 38:654 40:100 41:2077 44:3 46:1 47:26 52:6 55:7 56:2 57:24 58:645 59:640 60:419 61:1095 62:1054 63:1981 64:3829 65:2353 66:4158 67:1819 68:1052 69:2785 70:698 71:235 72:1866 73:2 74:2142 75:244 76:312 77:825 78:572 79:416 80:989 81:771 82:453 83:451 84:681 85:1040 86:383 87:680 88:348 89:1557 90:81 91:2701 92:427 93:1126 94:1368 95:545 96:233 97:302 98:529 99:26 109:417 110:289 111:459 112:240 113:246 114:389 115:632 116:1036 117:630 118:407 119:976 120:147 121:856 122:1401 123:872 124:1067 125:1292 128:208 129:203 130:158 131:557 132:227 133:17 134:197 135:44 136:223 137:171 138:255 139:94 140:479 141:137 142:376 143:349 144:432 145:51 146:423 147:169 148:585 149:248 150:151 151:168 152:258 153:168 154:2 155:320 156:184 157:324 158:102 159:359 160:315 161:178 162:269 163:164 164:399 165:509 166:508 167:402 168:796 169:158 170:733 171:48 172:2 173:575 174:611 175:53 178:16 180:353 182:32 183:236 184:27 186:340 187:252 188:1191 189:721 190:3582 192:5722 193:4600 194:3360 195:2776 196:1171 198:3541 199:3396 200:5300 201:1480 202:8084 203:8300 204:4039 205:2304 206:2518 207:3025 208:3916 209:3431 210:2553 211:1211 212:1720 213:1682 214:589 215:67 216:4471 217:1519 218:492 219:418 220:1079 221:380 222:300 End of report From eesslinger at fpu-tn.com Fri Mar 26 15:05:38 2010 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Fri, 26 Mar 2010 15:05:38 -0500 Subject: Need to talk to Charter email contact In-Reply-To: Message-ID: And a followup I've got someone in their mail group and we're working on clearing up the issue. Thank you everyone for the replies and help. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 > -----Original Message----- > From: Eric J Esslinger [mailto:eesslinger at fpu-tn.com] > Sent: Friday, March 26, 2010 1:54 PM > To: 'nanog at nanog.org' > Subject: Need to talk to Charter email contact > > > Good afternoon, I'm looking for some cluefull help from > someone at Charter. I've got a static IP customer unable to > deliver mail to charter.net customers and I can get no help > trying to get in through the 'front door' of tech support. > I've been forwarded to the residential spanish technicians 3 > times so far to get rid of me. Customer is unable to get any > connection to ib1.charter.net on port 25 thus is unable to > use the unblock at charter.net > method of clearing this up. The few people I've talked to > that understand what I'm talking about say that his > connection timing out is 'impossible to be an issue on the > Charter side', but there is no block preventing his email on > our side (and he can successfully send to aol, bellsouth, > hotmail, gmail, yahoo, comcast, etc..) DNS is configured with > mx, forward and reverse records properly setup. > > Can contact me off list by phone or email. Thanks in advance. > __________________________ Eric Esslinger Information > Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ (931)433-1522 ext 165 > > ________________________________ > This message may contain confidential and/or proprietary > information and is intended for the person/entity to whom it > was originally addressed. Any use by others is strictly prohibited. > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: Eric J Esslinger.vcf Type: text/x-vcard Size: 498 bytes Desc: Eric J Esslinger.vcf URL: From davei at otd.com Fri Mar 26 15:32:02 2010 From: davei at otd.com (Dave Israel) Date: Fri, 26 Mar 2010 16:32:02 -0400 Subject: IP4 Space In-Reply-To: <7BD730BB-3F77-41B2-AA89-F47C4B60AA2B@delong.com> References: <201003261157.23601.lowen@pari.edu> <7BD730BB-3F77-41B2-AA89-F47C4B60AA2B@delong.com> Message-ID: <4BAD19C2.2090208@otd.com> On 3/26/2010 1:31 PM, Owen DeLong wrote: > > On Mar 26, 2010, at 8:57 AM, Lamar Owen wrote: > > You should ask your server guy how he plans to talk to your core > stakeholders when they can't get IPv4 any more. Then, at that time, both he and his key stakeholders will experience pain while they both deploy IPv6, or more likely, his key stakeholders will add another level of NAT-like indirection to give themselves space to expand with the address pool they have. >> At the CxO level, it's all about the money. Or the lack therof. >> > How much less money will you have when donors can not reach your > website or have a poor user experience doing so? This assumption is incorrect. "They can't keep nursing IPv4 forever. Eventually everybody will have to switch to v6. If you don't, you'll be sorry. Just wait and see." That attitude did not force any previous supposed IPv4-killer protocol to be deployed. The fact is, for the foreseeable future, his donors will tend to have a better experience over v4 than v6. He isn't going to be blindsided by the need to deploy v6, and he knows it. By the time an important v4 host is not reachable via the entire internet (and at full speed), v6 will have been everywhere for years. An address space crisis will not result in v6 deployment from repentant network engineers who did not see the light in time. An address space crisis will merely result in more hacks to keep v4 running longer. v6 will be deployed slowly by the curious, encouraged by features v6 has that they want and with the assumption that they will still be able to do everything they can do on v4 (either through translation or dual stacking.) This process can be accelerated by something that v6 can do that v4 can't. So far, there's nothing that fits that description; everything being done over v6 can also be done over v4. From tglassey at earthlink.net Fri Mar 26 15:52:03 2010 From: tglassey at earthlink.net (todd glassey) Date: Fri, 26 Mar 2010 13:52:03 -0700 Subject: NTP clock source In-Reply-To: <85d954181003250703l5d9930a2l6655a3ef244ebfd7@mail.gmail.com> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> <85d954181003250703l5d9930a2l6655a3ef244ebfd7@mail.gmail.com> Message-ID: <4BAD1E73.1080603@earthlink.net> On 3/25/2010 7:03 AM, Dave Hart wrote: > On Thu, Mar 25, 2010 at 12:51 UTC, Kyle Bader wrote: >> Can anyone recommend a solid clock souce (stratum 0) that's not overly >> expensive? > > All the options I'm aware of have no prices posted, sadly. For me, > that means "forget it, you don't want to spend that much", but then > I'm not spending other people's money :) > > In addition to Symmetricom and EndRun Technologies, Meinberg has a > solid reputation in this space: > > http://www.meinberg.de/english/products/#network_sync > > I'm biased toward Meinberg because several of their staff contribute > their skills to the development and maintenance of the ntp.org > reference implementation. They have also been generous donating > hardware over the years to ntp.org and pool.ntp.org, and their Windows > NTP binaries and GUI installer are widely used. I totally agree! Meinberg's M300's rock solid and JTime is really easy to deal with as are its distributor's. > > The cheapest solution involves the Garmin GPS 18x LVC receiver and a > soldering iron. Unlike the USB and "PC" (232) versions of the GPS > 18x, the LVC version supplies a pulse-per-second signal which makes it > suitable for sub-millisecond NTP sync. The supplied connector has to > be cut off, a DB-9 serial hood wired in its place, and either a USB > cable or other 5V power supply needs to be attached. Or you can do as > I did and pay for the completed GPS 18x LVC with DB-9 and USB > connectors from a third party. $105 from: > True - you can build very accurate timekeeping service practices, but ALL GPS-L1 based systems have one flaw - the provability of the time data is squat. The evidence-model from a passive L1 system no matter how accurate it is - is zero... zip... it has as much legal impact with a competent lawyer on the other side, as you looking at mickey on your wrist and setting the ToD by hand daily. This is becoming more and more important in the world of commercial computing and something that timekeeping will have to morph towards to insure its not unseated... > > You also need a junkbox PC with real serial ports (not via a USB > adapter), or the capacity on an existing server. The GPS 18x cable is > either 3m or 5m long, if your PC is not close enough to a > southern-exposed window or to roof access for the 18x to lock, you may > also need a RS-232 extension cable and USB power supply. Unlike > timing-focused GPSes, the 18x needs 3 or more birds in view to provide > a PPS signal. > > Good luck, > Dave Hart > > -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 133 bytes Desc: not available URL: From lowen at pari.edu Fri Mar 26 16:21:11 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 26 Mar 2010 17:21:11 -0400 Subject: IP4 Space In-Reply-To: <7BD730BB-3F77-41B2-AA89-F47C4B60AA2B@delong.com> References: Message-ID: <201003261721.11474.lowen@pari.edu> On Friday 26 March 2010 01:31:33 pm Owen DeLong wrote: > The other key point to take away... If your engineer is telling you that > your ISP isn't ready yet, it's time for you to give your engineer your > backing at telling the ISP that IPv6 is a requirement for contract > renewal. At least right now, I don't have many choices, as I'm in an area served by a rural ILEC under 47 USC 251(f) as cited by 47 CFR 51.401. So there isn't an alternative at the moment. But this ILEC has great engineers and techs, and I believe when they're ready to field trial IPv6 we'd likely be on the short list. As for as the economy is concerned, due to the current situation I've already had to cut back on the bandwidth department, moving from an OC3 with full APS to a MetroE delivered via 1000Base-LX. We are cutting our total Internet- facing bandwidth by 75%. We are scrambling as it is. And my nickname of 'Mr. Make-Do' is getting a real workout. > You should ask your server guy how he plans to talk to your core > stakeholders when they can't get IPv4 any more. If full IPv4 deprecation is 10 years out, well, it's not yet on the radar, quite honestly. > Here we come to the essential part of this which is hard to communicate. > > It's kind of like flying up a box canyon (yes, I know flying up box > canyons > is best avoided, but, bear with me)... [snip] Our CEO is a FAA certified balloonist and balloonist certifier. He understands these issues, with the caveat that a hot-air balloon can out-climb all but the most powerful airplanes, with climb rates of 1500 feet per minute being easily attainable. So he's used to some agility in the climbing department, but understands how winds blow.... But the analogy is flawed to a degree, since this isn't really a hard 'wall' we're headed to. The farther in, the greater the pain, obviously, but, unlike a canyon wall, there is some give. > > At the CxO level, it's all about the money. Or the lack therof. > How much less money will you have when donors can not reach your > website or have a poor user experience doing so? As those folk who might donate lose IPv4 connectivity, then the pain increases, yes indeed. Most of the people we apply to don't come in that way, though. The bigger issue to us is when the NSF goes entirely IPv6 with no IPv4 connectivity, or when NASA does the same, or any of our other major funders. This is, I would think, farther down the road than when unallocated IPv4 space is exhausted. Not that this means we have room to procrastinate, but it's just not as cataclysmic of an event as flying a plane, or a balloon, into the wall at the end of a box canyon would be. > That's a good thing. Hopefully you pull the trigger soon enough that > quickly is fast enough. The key point here is to at least have a plan > that gets IPv6 deployed to the important parts of your infrastructure > before you start losing business (with the full understanding that > plans never execute as fast as planned). We're small enough where our network inertia shouldn't prevent us being able to only take a couple of months of work to implement dual stack in all of the critical pieces. The hard and most time consuming part isn't the creation of the configs or the assignment of the addresses, but in the planning of which equipment that is on hand can be used, testing that equipment, and planning the deployment so that we experience the fewest hiccups. We're working on that piece already, as other projects permit, and with a mind to turn it around rapidly when needed. From lowen at pari.edu Fri Mar 26 16:25:30 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 26 Mar 2010 17:25:30 -0400 Subject: IP4 Space In-Reply-To: <201003261810.o2QIAjde022222@drugs.dv.isc.org> References: Message-ID: <201003261725.30279.lowen@pari.edu> On Friday 26 March 2010 02:10:45 pm Mark Andrews wrote: > In message <201003261157.23601.lowen at pari.edu>, Lamar Owen writes: > > "Hey, great presentation. Compelling arguments. But I have one > > question: will our existing gear that's not yet fully depreciated handle > > it? No? > What percentage of your equipment already supports IPv6? Most 5 year old > pieces of equipement already have IPv6 support. It just needs to be > enabled. While my hypothetical answer was intentionally worst-case, with just-barely- too-old hypothetical hardware being mentioned, in reality my situation is dealing with in some cases much older equipment. I could go into detail, but you guys don't want to read my pity party, I'm sure. But "supporting IPv6" and "handling it [dual stack with comparable throughput]" are two different things. > > No, we cannot afford to forklift upgrade now. > IPv6 is *not* a "forklift upgrade". I have few routers that will do IPv6 at all, and even fewer that will do it efficiently. Where we have layer 3 switches, none will do IPv6 in hardware, and only one will do it in software (OSR 7609). For us, efficient dual-stack is a forklift upgrade. > Turning on IPv6 doesn't really affect the amount of bandwith you use. Not my point; if I have to spend on hardware/software upgrades (both being expensive, especially for out-of-contract hardware), then that's less dollars we have to spend on bandwidth. Thus I lower my bandwidth, and spend that previously-opex money on capex instead. [snip] Don't misunderstand; we are and have been working on our plan for rolling out dual-stack, and I hope to have an IT intern this summer who will do the grunt work. I'm just having to try to be frugal when doing so, and with an understanding of the limitations of our older gear; I don't plan on being bit by some surprise 'feature' on one of our arcane pieces of gear. Once we understand what can do what and how fast it can do what it does, then we can intelligently redeploy equipment to produce the least pain at the least cost when IPv6 is enabled on it. And if we have to purchase some newer kit, well, we'll cross that bridge when we come to it. It will be a tough sell when we come to that bridge. For instance, terminating a slow MetroE on Cisco 12000 1 port GE. Overkill, on first glance, but not when you factor the actual IPv6 performance on that linecard. And if already have that gear, fully amortized, then you've reduced your implementation cost (maybe not opex, but it would take a lot of reduction in opex to offset the reduction in capex), and thus made it more likely to happen. > > At the CxO level, it's all about the money. Or the lack therof. > Turn on IPv6 should be a $0 cost. Fully supporting IPv6 on all the > services you offer will have some cost. Nothing is $0 cost. Time is money, after all. But I do appreciate all the advice I have gleaned from NANOG and c-nsp over the years on the various and sundry ways people have performed the 'addition' of IPv6 to their IPv4 networks. And I thank all those who have shared their experiences; even if it didn't help anyone else, it has helped this non-profit. And while I understand most of the issues involved in the negative impact of not going dual-stack, and am in full agreement that we need to do so, I still have to look at the economic reality of the situation. Yes, in order to get this done in this economy you (or your department head, or whatever) have to get your CIO/CTO and maybe the CEO on board (typically the CIO would get the CEO on board). But even with them on board the costs may be greater than the bottom line can currently bear. And to get the CxO's on board you have to speak the C language....no, not that C, but the language of the CxO. And that's dollars and cents; cost-benefit, etc. Business 101. Having said all that, we are well on the way to getting the equipment selection phase (among equipment we already have on hand or in service) completed. We know what equipment we have that will definitely not work, and we know what equipment we have on hand that definitely will work. Now we have to determine how well that workable equipment will work, and if there are ways to continue to use some of the equipment that is in service, but not able to handle IPv6. From JCharles at epic.com Fri Mar 26 16:45:45 2010 From: JCharles at epic.com (Jeremy Charles) Date: Fri, 26 Mar 2010 16:45:45 -0500 Subject: ARIN negotiation? Message-ID: Has anyone here had their legal department balk at the legal agreement that ARIN wants you to sign when you get things like an AS number or an IP block? Any luck in negotiating with ARIN? The agreement has language at the top saying that ARIN doesn't accept modifications, but our legal team is questioning whether that means it really is non-negotiable. They're not exactly fans of it as it is written. (I probably can't share what my legal counsel is saying to me about the agreement, but it's probably not relevant to the question anyway...) === Jeremy Charles Epic - Computer and Technology Services Division jcharles at epic.com Phone: 608-271-9000 Fax: 608-271-7237 From owen at delong.com Fri Mar 26 16:42:33 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 14:42:33 -0700 Subject: IP4 Space In-Reply-To: <4BAD19C2.2090208@otd.com> References: <201003261157.23601.lowen@pari.edu> <7BD730BB-3F77-41B2-AA89-F47C4B60AA2B@delong.com> <4BAD19C2.2090208@otd.com> Message-ID: Dave, It's clear we disagree about what will happen in an obviously unpredictable future. I think that eyeball networks will deploy IPv6 rapidly due to the high costs of attempting to continue to hack IPv4. You believe that something else will happen. In time, we will see which of us turns out to be more correct. We can look at it in hindsight over drinks in about 5 years or so. Owen On Mar 26, 2010, at 1:32 PM, Dave Israel wrote: > > > On 3/26/2010 1:31 PM, Owen DeLong wrote: >> >> On Mar 26, 2010, at 8:57 AM, Lamar Owen wrote: >> >> You should ask your server guy how he plans to talk to your core >> stakeholders when they can't get IPv4 any more. > > Then, at that time, both he and his key stakeholders will experience > pain while they both deploy IPv6, or more likely, his key stakeholders > will add another level of NAT-like indirection to give themselves space > to expand with the address pool they have. > >>> At the CxO level, it's all about the money. Or the lack therof. >>> >> How much less money will you have when donors can not reach your >> website or have a poor user experience doing so? > > This assumption is incorrect. "They can't keep nursing IPv4 forever. > Eventually everybody will have to switch to v6. If you don't, you'll be > sorry. Just wait and see." That attitude did not force any previous > supposed IPv4-killer protocol to be deployed. The fact is, for the > foreseeable future, his donors will tend to have a better experience > over v4 than v6. He isn't going to be blindsided by the need to deploy > v6, and he knows it. By the time an important v4 host is not reachable > via the entire internet (and at full speed), v6 will have been > everywhere for years. > > An address space crisis will not result in v6 deployment from repentant > network engineers who did not see the light in time. An address space > crisis will merely result in more hacks to keep v4 running longer. v6 > will be deployed slowly by the curious, encouraged by features v6 has > that they want and with the assumption that they will still be able to > do everything they can do on v4 (either through translation or dual > stacking.) This process can be accelerated by something that v6 can do > that v4 can't. So far, there's nothing that fits that description; > everything being done over v6 can also be done over v4. > From morrowc.lists at gmail.com Fri Mar 26 16:51:13 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 26 Mar 2010 14:51:13 -0700 Subject: ARIN negotiation? In-Reply-To: References: Message-ID: <75cb24521003261451x4fe3b401k74b505dd24521bde@mail.gmail.com> doesn't hurt to ask arin's legal folks, they work for you (kinda). On Fri, Mar 26, 2010 at 2:45 PM, Jeremy Charles wrote: > Has anyone here had their legal department balk at the legal agreement that ARIN wants you to sign when you get things like an AS number or an IP block? ?Any luck in negotiating with ARIN? > From aaron at wholesaleinternet.net Fri Mar 26 16:52:26 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 26 Mar 2010 16:52:26 -0500 Subject: ARIN negotiation? In-Reply-To: References: Message-ID: <0e5c01cacd2e$9fb947b0$df2bd710$@net> Don't know for sure but I doubt it. The whole point is that everyone plays by the same set of rules and opening up the RSA for "negotiation" would defeat that purpose. -----Original Message----- From: Jeremy Charles [mailto:JCharles at epic.com] Sent: Friday, March 26, 2010 4:46 PM To: nanog at nanog.org Subject: ARIN negotiation? Has anyone here had their legal department balk at the legal agreement that ARIN wants you to sign when you get things like an AS number or an IP block? Any luck in negotiating with ARIN? The agreement has language at the top saying that ARIN doesn't accept modifications, but our legal team is questioning whether that means it really is non-negotiable. They're not exactly fans of it as it is written. (I probably can't share what my legal counsel is saying to me about the agreement, but it's probably not relevant to the question anyway...) === Jeremy Charles Epic - Computer and Technology Services Division jcharles at epic.com Phone: 608-271-9000 Fax: 608-271-7237 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.791 / Virus Database: 271.1.1/2752 - Release Date: 03/26/10 02:33:00 From bill at herrin.us Fri Mar 26 16:56:36 2010 From: bill at herrin.us (William Herrin) Date: Fri, 26 Mar 2010 17:56:36 -0400 Subject: ARIN negotiation? In-Reply-To: References: Message-ID: <3c3e3fca1003261456n11299ff6v9728bfac46c8fc92@mail.gmail.com> On Fri, Mar 26, 2010 at 5:45 PM, Jeremy Charles wrote: > Has anyone here had their legal department balk at the legal > agreement that ARIN wants you to sign when you get things > like an AS number or an IP block? Yes. > Any luck in negotiating with ARIN? No. > The agreement has language at the top saying that ARIN > doesn't accept modifications, but our legal team is > questioning whether that means it really is non-negotiable. It does. > They're not exactly fans of it as it is written. > (I probably can't share what my legal counsel is > saying to me about the agreement, but it's > probably not relevant to the question anyway...) I can't imagine why anyone would balk at a contract where the "seller" more or less says, "You agree that all your base are belong to us." Suck it up; for better or for worse, that's how the game is played. The good news is that you can hop on ARIN PPML and have a respectably strong say in what rules get written. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bmanning at vacation.karoshi.com Fri Mar 26 16:58:20 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 26 Mar 2010 21:58:20 +0000 Subject: ARIN negotiation? In-Reply-To: References: Message-ID: <20100326215820.GA10994@vacation.karoshi.com.> I am aware of a general case where the RSA has been modified. As presented, the RSA is targeted toward US-based commercial & not-for-profit entities. If you are a soveriegn in the ARIN region or are a state government in the US, I beleive there is some wiggle-room for changing liability and venue clauses. Your best bet is to inquire of the ARIN GC or legal team about your specfic concerns. --bill manning On Fri, Mar 26, 2010 at 04:45:45PM -0500, Jeremy Charles wrote: > Has anyone here had their legal department balk at the legal agreement that ARIN wants you to sign when you get things like an AS number or an IP block? Any luck in negotiating with ARIN? > > The agreement has language at the top saying that ARIN doesn't accept modifications, but our legal team is questioning whether that means it really is non-negotiable. They're not exactly fans of it as it is written. > > > (I probably can't share what my legal counsel is saying to me about the agreement, but it's probably not relevant to the question anyway...) > > > === > Jeremy Charles > Epic - Computer and Technology Services Division > jcharles at epic.com > > Phone: 608-271-9000 Fax: 608-271-7237 > From cidr-report at potaroo.net Fri Mar 26 17:00:02 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Mar 2010 22:00:02 GMT Subject: BGP Update Report Message-ID: <201003262200.o2QM029u058761@wattle.apnic.net> BGP Update Report Interval: 18-Mar-10 -to- 25-Mar-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30890 50203 3.6% 113.6 -- EVOLVA Evolva Telecom s.r.l. 2 - AS8452 30728 2.2% 42.9 -- TEDATA TEDATA 3 - AS14420 22146 1.6% 55.8 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 4 - AS45985 21594 1.5% 5398.5 -- DAEWOOSEC Daewoo Securities Co., Ltd. 5 - AS4668 17699 1.3% 54.6 -- LGNET-AS-KR LG CNS 6 - AS19647 15320 1.1% 957.5 -- HPOD20001 - Hewlett-Packard Operation Division 7 - AS4323 13234 0.9% 7.1 -- TWTC - tw telecom holdings, inc. 8 - AS7738 13202 0.9% 29.5 -- Telecomunicacoes da Bahia S.A. 9 - AS35805 12943 0.9% 21.2 -- UTG-AS United Telecom AS 10 - AS45987 12236 0.9% 4078.7 -- DONGWHA-AS-KR EUNIQUE CO.,LTD 11 - AS12479 10644 0.8% 532.2 -- UNI2-AS Uni2 - Lince telecomunicaciones 12 - AS5803 10461 0.7% 104.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS9829 9508 0.7% 15.0 -- BSNL-NIB National Internet Backbone 14 - AS3786 8791 0.6% 51.7 -- LGDACOM LG DACOM Corporation 15 - AS16569 8232 0.6% 8232.0 -- ASN-CITY-OF-CALGARY - City of Calgary 16 - AS26025 7610 0.5% 7610.0 -- COC - City of Calgary 17 - AS27747 7574 0.5% 44.0 -- Telecentro S.A. 18 - AS10036 7537 0.5% 27.8 -- CNM-AS-KR C&M Communication Co.,Ltd. 19 - AS10066 7153 0.5% 43.1 -- GAYANET-AS-KR CJ-CABLENET 20 - AS10037 6268 0.5% 43.5 -- NEXEYE-AS-KR Jeil CATV Co.,Ltd TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16569 8232 0.6% 8232.0 -- ASN-CITY-OF-CALGARY - City of Calgary 2 - AS26025 7610 0.5% 7610.0 -- COC - City of Calgary 3 - AS45985 21594 1.5% 5398.5 -- DAEWOOSEC Daewoo Securities Co., Ltd. 4 - AS45987 12236 0.9% 4078.7 -- DONGWHA-AS-KR EUNIQUE CO.,LTD 5 - AS10052 5375 0.4% 2687.5 -- KNU-AS Kyungpook National Univ. 6 - AS5691 2348 0.2% 2348.0 -- MITRE-AS-5 - The MITRE Corporation 7 - AS32794 1072 0.1% 1072.0 -- ICFG - International Church of the Foursquare Gospel 8 - AS19647 15320 1.1% 957.5 -- HPOD20001 - Hewlett-Packard Operation Division 9 - AS25969 1694 0.1% 847.0 -- SLU - St. Louis University 10 - AS45989 3420 0.2% 684.0 -- KLNETCO-AS-KR KL-Net Corp. 11 - AS42214 607 0.0% 607.0 -- IWC-AS SC International Work Company SRL 12 - AS1280 602 0.0% 602.0 -- ISC-AS1280 Internet Systems Consortium, Inc. 13 - AS22395 587 0.0% 587.0 -- GHCO-INTERNAP - Goldenberg Hehmeyer 14 - AS12479 10644 0.8% 532.2 -- UNI2-AS Uni2 - Lince telecomunicaciones 15 - AS10445 2748 0.2% 458.0 -- HTG - Huntleigh Telcom 16 - AS27097 1740 0.1% 435.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 17 - AS45960 374 0.0% 374.0 -- YTLCOMMS-AS-AP YTL COMMUNICATIONS SDN BHD 18 - AS27027 364 0.0% 364.0 -- ANBELL ASN-ANBELL 19 - AS35291 704 0.1% 352.0 -- ICOMM-AS SC Internet Communication Systems SRL 20 - AS28052 326 0.0% 326.0 -- Arte Radiotelevisivo Argentino TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 208.98.230.0/24 8232 0.6% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 2 - 208.98.231.0/24 7610 0.5% AS26025 -- COC - City of Calgary 3 - 123.140.107.0/24 5399 0.4% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 4 - 210.92.10.0/24 5399 0.4% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 5 - 210.92.6.0/24 5399 0.4% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 6 - 210.92.4.0/24 5397 0.4% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. 7 - 155.230.0.0/16 5373 0.4% AS10052 -- KNU-AS Kyungpook National Univ. 8 - 41.235.80.0/24 5081 0.3% AS8452 -- TEDATA TEDATA 9 - 183.109.74.0/24 4101 0.3% AS45987 -- DONGWHA-AS-KR EUNIQUE CO.,LTD 10 - 210.120.80.0/24 4069 0.3% AS45987 -- DONGWHA-AS-KR EUNIQUE CO.,LTD 11 - 210.120.82.0/24 4066 0.3% AS45987 -- DONGWHA-AS-KR EUNIQUE CO.,LTD 12 - 62.193.80.0/24 3659 0.2% AS5536 -- Internet-Egypt 13 - 85.60.192.0/23 3119 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 14 - 194.126.40.0/21 3049 0.2% AS24627 -- SHOWNET-KW-AS GULFSATCOMMUNICATIONS COMPANY K.S.C. AS25122 -- GULFSAT_COMMUNICATIONS-AS Gulfsat Communications Co. 15 - 199.114.154.0/24 2952 0.2% AS1733 -- CENTAF-SWA - 754th Electronic Systems Group 16 - 206.184.16.0/24 2899 0.2% AS174 -- COGENT Cogent/PSI 17 - 85.60.194.0/23 2462 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 18 - 192.12.120.0/24 2348 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 19 - 200.13.36.0/24 2325 0.2% AS28477 -- Universidad Autonoma del Esstado de Morelos 20 - 85.60.208.0/21 2129 0.1% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 26 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Mar 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201003262200.o2QM00Pu058756@wattle.apnic.net> This report has been generated at Fri Mar 26 21:11:54 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 19-03-10 316783 195181 20-03-10 318199 195244 21-03-10 318191 194191 22-03-10 317341 194985 23-03-10 318630 195016 24-03-10 318820 194978 25-03-10 318566 194959 26-03-10 318754 195401 AS Summary 33979 Number of ASes in routing system 14497 Number of ASes announcing only one prefix 4402 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 96814336 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'). --- 26Mar10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 319000 195345 123655 38.8% All ASes AS6389 4055 319 3736 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4402 1277 3125 71.0% TWTC - tw telecom holdings, inc. AS4766 1836 491 1345 73.3% KIXS-AS-KR Korea Telecom AS4755 1294 193 1101 85.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1778 682 1096 61.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS22773 1132 75 1057 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1059 33 1026 96.9% COVAD - Covad Communications Co. AS17488 1306 347 959 73.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1537 626 911 59.3% Uninet S.A. de C.V. AS10620 1028 170 858 83.5% Telmex Colombia S.A. AS18101 907 62 845 93.2% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS19262 1085 245 840 77.4% VZGNI-TRANSIT - Verizon Internet Services Inc. AS7545 1047 239 808 77.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS6478 1176 419 757 64.4% ATT-INTERNET3 - AT&T WorldNet Services AS24560 864 239 625 72.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4808 844 237 607 71.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS8452 969 364 605 62.4% TEDATA TEDATA AS4134 1030 436 594 57.7% CHINANET-BACKBONE No.31,Jin-rong Street AS4804 678 85 593 87.5% MPX-AS Microplex PTY LTD AS7303 692 113 579 83.7% Telecom Argentina S.A. AS7018 1564 1002 562 35.9% ATT-INTERNET4 - AT&T WorldNet Services AS5668 804 254 550 68.4% AS-5668 - CenturyTel Internet Holdings, Inc. AS17908 772 234 538 69.7% TCISL Tata Communications AS3356 1233 696 537 43.6% LEVEL3 Level 3 Communications AS35805 610 101 509 83.4% UTG-AS United Telecom AS AS4780 655 155 500 76.3% SEEDNET Digital United Inc. AS22047 545 49 496 91.0% VTR BANDA ANCHA S.A. AS17676 575 87 488 84.9% GIGAINFRA Softbank BB Corp. AS9443 555 74 481 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS11492 1146 678 468 40.8% CABLEONE - CABLE ONE, INC. Total 37178 9982 27196 73.2% Top 30 total Possible Bogus Routes 2.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 2.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.190.64.0/22 AS28683 BENINTELECOM 41.202.96.0/19 AS29571 CITelecom-AS 41.220.144.0/20 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.220.159.0/24 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.24.0/22 AS25747 VSC-SATELLITE-CO - VSC Satellite Co. 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.193.160.0/19 AS22351 INTELSAT Intelsat Global BGP Routing Policy 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 78.41.80.0/24 AS29158 DE-IP69 Tux-Service 78.41.81.0/24 AS29158 DE-IP69 Tux-Service 78.41.82.0/24 AS29158 DE-IP69 Tux-Service 78.41.83.0/24 AS29158 DE-IP69 Tux-Service 78.41.84.0/24 AS29158 DE-IP69 Tux-Service 78.41.86.0/24 AS29158 DE-IP69 Tux-Service 78.41.87.0/24 AS29158 DE-IP69 Tux-Service 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 80.250.32.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 80.250.34.0/23 AS21452 SKANNET-IBADAN SKANNET IP Network 107.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering AS 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 178.216.48.0/21 AS34702 WAVECOM-AS WaveCom AS 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.153.144.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.29.40.0/22 AS36918 OTAVSAT-AS ORASCOM TELECOM ALGERIE VSAT 196.32.96.0/20 AS33787 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.254.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 196.216.4.0/22 AS23889 MAURITIUS-TELECOM-AS-AP 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.161.92.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.80.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.77.138.0/23 AS24487 202.79.224.0/21 AS9519 VERTELNET Vertical Telecoms Pty Ltd 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.125.88.0/24 AS38535 M2AKSES-AS-AP P.T. Mega Media Aksesindo 202.125.89.0/24 AS38535 M2AKSES-AS-AP P.T. Mega Media Aksesindo 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.146.184.0/23 AS24487 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.166.166.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.154.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.124.96.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.100.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.124.104.0/23 AS7615 FORTANA-AS-AP Fortana Networks Australia Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.160.130.0/23 AS24487 203.215.52.0/22 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.128.104.0/21 AS11709 VIC - VIRTUAL INTERACTIVE CENTER 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.87.208.0/24 AS31997 209.87.209.0/24 AS31997 209.87.210.0/24 AS31997 209.87.211.0/24 AS31997 209.87.212.0/22 AS31997 209.87.216.0/24 AS31997 209.87.217.0/24 AS31997 209.87.218.0/24 AS31997 209.87.219.0/24 AS31997 209.87.220.0/24 AS31997 209.87.221.0/24 AS31997 209.87.222.0/24 AS31997 209.87.223.0/24 AS31997 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.144.240.0/23 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.243.0/24 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.144.244.0/22 AS11351 RR-NYSREGION-ASN-01 - Road Runner HoldCo LLC 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.29.208.0/23 AS33774 DJAWEB 217.29.212.0/23 AS33774 DJAWEB Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cra at WPI.EDU Fri Mar 26 17:09:22 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 26 Mar 2010 18:09:22 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop Message-ID: <20100326220922.GH12189@angus.ind.WPI.EDU> Anyone have suggestions on Ethernet LAN loop-prevention? With the advent of Auto MDI/MDI-X ports on switches, it seems way too easy to accidentally or maliciously create loops between network jacks. We have bored or inattentive people plugging in patch cords between adjacent network jacks. STP for loop-prevention isn't working so well for us. STP "edge" or "portfast" or "faststart" modes are required for end-station ports (with normal STP, DHCP often times out after 30+ seconds it takes to go into Forwarding state). Since the "edge" STP mode goes into Forwarding state immediately, there is a period when loops will form, causing havok with upstream gear until STP blocks the port (if it ever does see below). "Desktop" switches. You know, those 4 or 5 port Gigabit Ethernet switches. Apparently, many of them don't do any kind of STP at all. Recommendations on ones that do STP? RSTP: is it any better than traditional STP in regards to "edge" ports and blocking before a loop gets out of hand? Or perhaps blocking for 5-10 seconds before going into Forwarding state, hopefully preventing loops before they happen but also allowing DHCP clients to get an address without timeouts? Recommendations on "Desktop" switches that do RSTP? Thanks for your suggestions/discussion. -- - Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/) From mike.lyon at gmail.com Fri Mar 26 17:13:43 2010 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 26 Mar 2010 15:13:43 -0700 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <20100326220922.GH12189@angus.ind.WPI.EDU> References: <20100326220922.GH12189@angus.ind.WPI.EDU> Message-ID: <1b5c1c151003261513y2be8edaey4743062d53e276ed@mail.gmail.com> Disable the jacks all together and go wireless? Have them put in a trouble ticket if they absolutely need a port activated in a conference room for a one-time meeting. -Mike On Fri, Mar 26, 2010 at 3:09 PM, Chuck Anderson wrote: > Anyone have suggestions on Ethernet LAN loop-prevention? With the > advent of Auto MDI/MDI-X ports on switches, it seems way too easy to > accidentally or maliciously create loops between network jacks. We > have bored or inattentive people plugging in patch cords between > adjacent network jacks. STP for loop-prevention isn't working so well > for us. > > STP "edge" or "portfast" or "faststart" modes are required for > end-station ports (with normal STP, DHCP often times out after 30+ > seconds it takes to go into Forwarding state). Since the "edge" STP > mode goes into Forwarding state immediately, there is a period when > loops will form, causing havok with upstream gear until STP blocks the > port (if it ever does see below). > > "Desktop" switches. You know, those 4 or 5 port Gigabit Ethernet > switches. Apparently, many of them don't do any kind of STP at all. > Recommendations on ones that do STP? > > RSTP: is it any better than traditional STP in regards to "edge" ports > and blocking before a loop gets out of hand? Or perhaps blocking for > 5-10 seconds before going into Forwarding state, hopefully preventing > loops before they happen but also allowing DHCP clients to get an > address without timeouts? Recommendations on "Desktop" switches that > do RSTP? > > Thanks for your suggestions/discussion. > > -- > - Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/) > > From mhuff at ox.com Fri Mar 26 17:21:08 2010 From: mhuff at ox.com (Matthew Huff) Date: Fri, 26 Mar 2010 18:21:08 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <20100326220922.GH12189@angus.ind.WPI.EDU> References: <20100326220922.GH12189@angus.ind.WPI.EDU> Message-ID: <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C8F@PUR-EXCH07.ox.com> Bpduguard if running cisco. set all the switch ports to bpduguard or enable it globally -----Original Message----- From: Chuck Anderson [mailto:cra at WPI.EDU] Sent: Friday, March 26, 2010 6:09 PM To: nanog at nanog.org Subject: Auto MDI/MDI-X + conference rooms + bored == loop Anyone have suggestions on Ethernet LAN loop-prevention? With the advent of Auto MDI/MDI-X ports on switches, it seems way too easy to accidentally or maliciously create loops between network jacks. We have bored or inattentive people plugging in patch cords between adjacent network jacks. STP for loop-prevention isn't working so well for us. STP "edge" or "portfast" or "faststart" modes are required for end-station ports (with normal STP, DHCP often times out after 30+ seconds it takes to go into Forwarding state). Since the "edge" STP mode goes into Forwarding state immediately, there is a period when loops will form, causing havok with upstream gear until STP blocks the port (if it ever does see below). "Desktop" switches. You know, those 4 or 5 port Gigabit Ethernet switches. Apparently, many of them don't do any kind of STP at all. Recommendations on ones that do STP? RSTP: is it any better than traditional STP in regards to "edge" ports and blocking before a loop gets out of hand? Or perhaps blocking for 5-10 seconds before going into Forwarding state, hopefully preventing loops before they happen but also allowing DHCP clients to get an address without timeouts? Recommendations on "Desktop" switches that do RSTP? Thanks for your suggestions/discussion. -- - Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/) From owen at delong.com Fri Mar 26 17:33:56 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 15:33:56 -0700 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <20100326220922.GH12189@angus.ind.WPI.EDU> References: <20100326220922.GH12189@angus.ind.WPI.EDU> Message-ID: <39183BDC-67DB-4523-9C3A-A80215962D3D@delong.com> Switches that support STP? There are switches that have STP protection such that they are portfast until they see an inbound BPDU and then revert to spanning tree on that port (it blocks, listens, learns, then forwards if appropriate). The only draw-back to such a configuration I am aware of is that you have the (very small) overhead of all such ports sending BPDUs. Owen On Mar 26, 2010, at 3:09 PM, Chuck Anderson wrote: > Anyone have suggestions on Ethernet LAN loop-prevention? With the > advent of Auto MDI/MDI-X ports on switches, it seems way too easy to > accidentally or maliciously create loops between network jacks. We > have bored or inattentive people plugging in patch cords between > adjacent network jacks. STP for loop-prevention isn't working so well > for us. > > STP "edge" or "portfast" or "faststart" modes are required for > end-station ports (with normal STP, DHCP often times out after 30+ > seconds it takes to go into Forwarding state). Since the "edge" STP > mode goes into Forwarding state immediately, there is a period when > loops will form, causing havok with upstream gear until STP blocks the > port (if it ever does see below). > > "Desktop" switches. You know, those 4 or 5 port Gigabit Ethernet > switches. Apparently, many of them don't do any kind of STP at all. > Recommendations on ones that do STP? > > RSTP: is it any better than traditional STP in regards to "edge" ports > and blocking before a loop gets out of hand? Or perhaps blocking for > 5-10 seconds before going into Forwarding state, hopefully preventing > loops before they happen but also allowing DHCP clients to get an > address without timeouts? Recommendations on "Desktop" switches that > do RSTP? > > Thanks for your suggestions/discussion. > > -- > - Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/) From tkapela at gmail.com Fri Mar 26 17:56:15 2010 From: tkapela at gmail.com (Anton Kapela) Date: Fri, 26 Mar 2010 18:56:15 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <20100326220922.GH12189@angus.ind.WPI.EDU> References: <20100326220922.GH12189@angus.ind.WPI.EDU> Message-ID: Hi Chuck, > Anyone have suggestions on Ethernet LAN loop-prevention? With the In general, I avoid the potential for layer2 loops to any user-accesible layer2 ports in a manner that many edge network and broadband providers may find familiar -- vlan per user, tail, port, etc. -- aggregated in a hierarchical manner within the building, metro area, or city. This simple and logical layer2 isolation (real isolation, none of this pvlan-edge stuff) basically solves many problems by simply avoiding the preconditions necessary for loops/etc to pose a problem to the agg/border/etc of a network. Don't worry about users' being entire walled-off from each other -- unicast IP reachability is not broken with this model. Currently, the IOS implementation of unnumbered vlans/subints provides proxy-arp responses for all in-prefix (as defined by loopback/interface pointer-membership) addresses that your end-users may issue who-has's for. This is analogous to docsis and rfc1483 half-bridge as often used on xDSL network edges -- layer3's not broken, but layer2 is nicely walled off per-user. Perhaps you could think of this as dedicated layer2 resources per customer edge (CE), rather, "complaining entity." More here: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtunvlan.html I use this feature on 3550/3560/3750, sup2/sup720 on 6500; several colleagues have verified this works on 4900m an 4500's in 12.2SG trains. Of course, terminating lower-speed subints or QinQ tag'd vlan bundles works on higher-end ports (sip/spa), as well as all cpu-based boxes... 7200/7301 will consume QinQ ip subints for breakfast, and even give populate option 82 info in DHCP transactions auto-magically, if given the chance (by using helder-addrs on subints). The user-facing port config is usually some per-site variation of this following flavor, configured expecting users to land at 10/fdx or hdx: interface FastEthernet0/1 description Unit 201 load-interval 30 speed 10 port security max-mac-count 10 port security aging time 5 port storm-control broadcast action shutdown port storm-control broadcast threshold rising 100 falling 50 port storm-control multicast action shutdown port storm-control multicast threshold rising 100 falling 50 port storm-control unicast action filter port storm-control unicast threshold rising 3000 falling 1000 switchport access vlan 201 spanning-tree portfast spanning-tree bpdufilter enable ...Errdisable autorecover (or having the user call the support desk) are some of the ways out of the down/down access port penalty box; mix and combine these elements to taste. If terminating fast or gig-e, scale things accordingly. After the access ports are setup and trunking per-port layer2 frames up to the l3 edge (could be 3550, 650x, mwr-1941, etc), we have pages of things like: [...] interface FastEthernet0/1.112 encapsulation dot1Q 112 ip unnumbered Loopback0 ! interface FastEthernet0/1.113 encapsulation dot1Q 113 ip unnumbered Loopback0 ! interface FastEthernet0/1.114 encapsulation dot1Q 114 ip unnumbered Loopback0 [...] In my mdu and mtu layer2 edge sites, this approach has saved our posteriors from real problems--year in, year out. A few words on this config: in what you see above, a user simply cannot introduce enough traffic to the network (unicast) to matter (i.e. perhaps they create an unknown unicast dest flood..), and will be shut down if they spew enough bcast/mcast frames (thresholds set appropriate given your expected end-user profiles). Further, only the first 10 mac addresses can ride this bus (sorry, no LAN parties without prior approval), mitigating concerns for CAM or vlan table exhaustion. Lastly, no funky l3/4 acl's are required to prevent users handing out DHCP addresses, leaking RA's, or fronting ARP as your routers MAC address to their vlan-sharin' neighbors--simply because they don't get to send layer2 frames to anyone but the upstream routers control plane. -Tk From blakjak at blakjak.net Fri Mar 26 18:33:04 2010 From: blakjak at blakjak.net (Mark Foster) Date: Sat, 27 Mar 2010 12:33:04 +1300 (NZDT) Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <20100326220922.GH12189@angus.ind.WPI.EDU> References: <20100326220922.GH12189@angus.ind.WPI.EDU> Message-ID: > "Desktop" switches. You know, those 4 or 5 port Gigabit Ethernet > switches. Apparently, many of them don't do any kind of STP at all. > Recommendations on ones that do STP? If the network fabric you're on is important enough to cause you grief in the event of a STP event, you shouldn't be fielding 'dumb' switches. Even the 'dumbest' switch I would ever place into user-space is fully managable, layer 2 with VLAN's and STP support. That is, it's in a cabinet or TC and fed by infrastructure cabling, and the only folks who can get at it are the engineers and techs supporting the site. The other side of things is that if DHCP times out once during STP negotiation, it rarely times out twice. Users whos machines are 'dynamically connected' often enough to have STP related glitches in their DHCP grab should know enough to hit 'repair' or run ipconfig /renew - or should be told to reboot :-) > RSTP: is it any better than traditional STP in regards to "edge" ports > and blocking before a loop gets out of hand? Or perhaps blocking for > 5-10 seconds before going into Forwarding state, hopefully preventing > loops before they happen but also allowing DHCP clients to get an > address without timeouts? Recommendations on "Desktop" switches that > do RSTP? There's plenty of desktop switches out there which are close to 'fully featured' - but obviously there's money involved. If your uplink switch (at the very least) supports STP then at least you can isolate the problem if the switch itself can't handle, but I wouldn't recommend this. Havn't fielded any recently but there's a fanless version of the Cisco 2960 I was looking at a while ago for desktop use (fan noise is usualy an issue). Mark. From cra at WPI.EDU Fri Mar 26 18:36:08 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 26 Mar 2010 19:36:08 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <39183BDC-67DB-4523-9C3A-A80215962D3D@delong.com> References: <20100326220922.GH12189@angus.ind.WPI.EDU> <39183BDC-67DB-4523-9C3A-A80215962D3D@delong.com> Message-ID: <20100326233608.GA13305@angus.ind.WPI.EDU> On Fri, Mar 26, 2010 at 03:33:56PM -0700, Owen DeLong wrote: > Switches that support STP? Yes, "soho" or "desktop" switches I mean. Apparently Netgear GS105's do not do STP at all, at least they don't claim to. > There are switches that have STP protection such that they are > portfast until they see an inbound BPDU and then revert to > spanning tree on that port (it blocks, listens, learns, then > forwards if appropriate). Do the ports so configured also send BPDUs such that a loop on a "desktop" switch uplinked to that port will cause the port to see its own BPDUs and revert to STP Blocking? Even if that is the case, I think the detection of BPDU and subsequent transition to Blocking will happen too slowly. By then the damage is already done upstream in the collapsed L2/L3 core. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Mar 26 18:37:49 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 27 Mar 2010 10:07:49 +1030 Subject: IPv4 ANYCAST setup In-Reply-To: <4BACB585.5040805@spaghetti.zurich.ibm.com> References: <4BACB4D3.60003@internetx.com> <4BACB585.5040805@spaghetti.zurich.ibm.com> Message-ID: <20100327100749.0febaf04@opy.nosense.org> On Fri, 26 Mar 2010 14:24:21 +0100 Jeroen Massar wrote: > InterNetX - Lutz Muehlig wrote: > > Hello, > > > > has someone experience in anycast ipv4 networks (to support DNS)? > > "Never been done" "Dangerous" "TCP does not work" etc etc etc. > > I assume quite a number of people know how to do it, especially as > several root DNS servers abuse it. > > Simple recipe: > - Box with: > - Your favourite OS > - Quagga or OpenBGPd > - Your favourite DNS server > - Announce the IP of the anycast node in BGP > - Monitor the DNS server, when it does not work kill your local BGPd > and notify the admins that it broke > > That is it. Probably with the above couple of things, google a bit and > find the rest. > I was involved in building an anycast setup where we had two anycast DNS /32 addresses. Each of them was the backup for the other i.e. each DNS server was announcing both /32s via BGP, with opposite weights. If one failed, the other DNS server then took over the failed DNS cache's queries, and as it was also already an operational DNS server for one of the anycast addresses, it's DNS cache was already hot. For load balancing, we alternated the order of announcing the DNS server addresses in e.g. PPP IPCP, DHCP. That worked somewhat surprisingly well - the peak query per second values on each of them were no more than about 10% different. One trap we got caught by was stateful firewalling on the host. We knew to up the number of stateful connections, however on that particular Linux distro there were two places it was set - /etc/sysctl.conf and in the iptables configuration. We only knew about the first, so when the firewall rules were updated the number of supported stateful connections was dropped down to too low a level. It wasn't funny to have one DNS server stop answering queries, and have it's own monitoring script fail itself, switch all the traffic to the other one and then have that die too for the same reason. Lots of gnashing of teeth until we worked out . The final and better solution was to stop doing stateful firewalling on DNS queries, using the iptables 'raw' table. Regards, Mark. From cra at WPI.EDU Fri Mar 26 18:48:32 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 26 Mar 2010 19:48:32 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: References: <20100326220922.GH12189@angus.ind.WPI.EDU> Message-ID: <20100326234832.GB13305@angus.ind.WPI.EDU> On Fri, Mar 26, 2010 at 06:56:15PM -0400, Anton Kapela wrote: > In general, I avoid the potential for layer2 loops to any > user-accesible layer2 ports in a manner that many edge network and > broadband providers may find familiar -- vlan per user, tail, port, > etc. -- aggregated in a hierarchical manner within the building, > metro area, or city. If you have 2 network jacks next to each other in a conference room, do they each get configured as a separate "user"? What happens if a user connects them together? What happens if a user plugs a desktop switch into one of them, then connects two ports on *that* switch together? > avoiding the preconditions necessary for loops/etc to pose a problem > to the agg/border/etc of a network. Don't worry about users' being Would this work in a collapsed L2/L3 core (no agg, no L3 at edge)? > After the access ports are setup and trunking per-port layer2 frames > up to the l3 edge (could be 3550, 650x, mwr-1941, etc), we have > pages of things like: When doing 1:1 VLAN:Port mapping, can you do more than 4096 VLANs/ports? Or are you doing QinQ? > A few words on this config: in what you see above, a user simply > cannot introduce enough traffic to the network (unicast) to matter > (i.e. perhaps they create an unknown unicast dest flood..), and will > be shut down if they spew enough bcast/mcast frames (thresholds set > appropriate given your expected end-user profiles). Further, only > the first 10 mac addresses can ride this bus (sorry, no LAN parties > without prior approval), mitigating concerns for CAM or vlan table > exhaustion. Lastly, no funky l3/4 acl's are required to prevent > users handing out DHCP addresses, leaking RA's, or fronting ARP as > your routers MAC address to their vlan-sharin' neighbors--simply > because they don't get to send layer2 frames to anyone but the > upstream routers control plane. Cool, but I'm not sure this will work in my non-Cisco campus environment with 10,000 edge ports. Thanks. From cdl at asgaard.org Fri Mar 26 18:57:04 2010 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Sat, 27 Mar 2010 10:57:04 +1100 Subject: ARIN negotiation? In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 yes; no; without reservation; really, why would a competent lawyer have any problems accepting that contract :) ? On 27 Mar 2010, at 08.45 , Jeremy Charles wrote: > Has anyone here had their legal department balk at the legal agreement that ARIN wants you to sign when you get things like an AS number or an IP block? Any luck in negotiating with ARIN? > > The agreement has language at the top saying that ARIN doesn't accept modifications, but our legal team is questioning whether that means it really is non-negotiable. They're not exactly fans of it as it is written. > > > (I probably can't share what my legal counsel is saying to me about the agreement, but it's probably not relevant to the question anyway...) > > > === > Jeremy Charles > Epic - Computer and Technology Services Division > jcharles at epic.com > > Phone: 608-271-9000 Fax: 608-271-7237 > > - --- ??? Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJLrUnQAAoJEGmx2Mt/+Iw/smoH/2eOivfobfS8RLEESWVp/cDx QYv7ALqfKh4RArXr3lRWtYjpJhjCwBH+bPDbycEyQGtq4738Ry5fC+MMwmwQf8GZ be6xa6C4RXxGMuRfaNX3xpPIxU893Vg++2vEvApQItrgBuMoc8R3+yxzT7s4P4b8 G0FnKp469LYiSFVaH2/0Pd8FrmXRUAMHWfi4BvOp3+rb8mKBReTUtfN7Sl/Rgts7 D1C7TjKo0lBN/4W6jjB0WAXA3A4MZF+HqHX3l28FIIpsv28NecWJfNun1Ja8PVmh O7yIg/RKrxezCLnNWEp6A7zeBSvpqDkrr2gKKrWDdKOkZXsa2cnby/2bBLCbtBk= =WweW -----END PGP SIGNATURE----- From cdl at asgaard.org Fri Mar 26 18:59:37 2010 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Sat, 27 Mar 2010 10:59:37 +1100 Subject: IP4 Space In-Reply-To: References: <201003261157.23601.lowen@pari.edu> <7BD730BB-3F77-41B2-AA89-F47C4B60AA2B@delong.com> <4BAD19C2.2090208@otd.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings Owen, The only problem is that there will be a number of devices that the eyeballs like that won't ever see an IPv6 packet (specifically thinking about the CE devices in the home). As such, it won't be IPv6 only, it will be dual-stack. Eventually we won't be able to give that eyeball's NAT box a unique address, then the proliferation of state begins.... Chris On 27 Mar 2010, at 08.42 , Owen DeLong wrote: > Dave, > It's clear we disagree about what will happen in an obviously > unpredictable future. I think that eyeball networks will deploy IPv6 > rapidly due to the high costs of attempting to continue to hack IPv4. > You believe that something else will happen. In time, we will see > which of us turns out to be more correct. We can look at it in > hindsight over drinks in about 5 years or so. > > Owen > > On Mar 26, 2010, at 1:32 PM, Dave Israel wrote: > >> >> >> On 3/26/2010 1:31 PM, Owen DeLong wrote: >>> >>> On Mar 26, 2010, at 8:57 AM, Lamar Owen wrote: >>> >>> You should ask your server guy how he plans to talk to your core >>> stakeholders when they can't get IPv4 any more. >> >> Then, at that time, both he and his key stakeholders will experience >> pain while they both deploy IPv6, or more likely, his key stakeholders >> will add another level of NAT-like indirection to give themselves space >> to expand with the address pool they have. >> >>>> At the CxO level, it's all about the money. Or the lack therof. >>>> >>> How much less money will you have when donors can not reach your >>> website or have a poor user experience doing so? >> >> This assumption is incorrect. "They can't keep nursing IPv4 forever. >> Eventually everybody will have to switch to v6. If you don't, you'll be >> sorry. Just wait and see." That attitude did not force any previous >> supposed IPv4-killer protocol to be deployed. The fact is, for the >> foreseeable future, his donors will tend to have a better experience >> over v4 than v6. He isn't going to be blindsided by the need to deploy >> v6, and he knows it. By the time an important v4 host is not reachable >> via the entire internet (and at full speed), v6 will have been >> everywhere for years. >> >> An address space crisis will not result in v6 deployment from repentant >> network engineers who did not see the light in time. An address space >> crisis will merely result in more hacks to keep v4 running longer. v6 >> will be deployed slowly by the curious, encouraged by features v6 has >> that they want and with the assumption that they will still be able to >> do everything they can do on v4 (either through translation or dual >> stacking.) This process can be accelerated by something that v6 can do >> that v4 can't. So far, there's nothing that fits that description; >> everything being done over v6 can also be done over v4. >> > > > - --- ??? Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJLrUppAAoJEGmx2Mt/+Iw/k30IAIv4rBRUbpWpFt7g5aXj5Jdh BfT7vKZp20Ho4O4IPPu5gqF1w5m/PWAsdyyuD+seUaVx/r6+KQbS5cLuErt+RXtb nZShLBjmXRusuJaz6Wj9ydTPaCZ0YdAC+drLLVN+7ogyoLpk3bp8JYf9nA66eHV5 BvaepyWOO47Fl2jG18Zds/xuPDlx9wTTi/fdeJiPAfLMFUKyMhoooFbqZXYd1Go4 tZVZWShvD8WOSiCnBr746WiuUpsqzpk0UPD+fmkciMkLEC3kCCJlRg0ak0O/SSlC nl8DgMk/ADY421ilZpUs27NwrpjOd8AXMgXoDhmeZ4q7HyH7KqqVrBlWrWuYe6Q= =ELTE -----END PGP SIGNATURE----- From feldman at twincreeks.net Fri Mar 26 19:09:29 2010 From: feldman at twincreeks.net (Steve Feldman) Date: Fri, 26 Mar 2010 17:09:29 -0700 Subject: [NANOG-announce] Early registration for NANOG 49 Message-ID: Registration is now open for the 49th NANOG meeting, to be held in San Francisco on June 13-16, 2010 and hosted by Netflix. The early registration price is $450, so register now to get the best value! Hotel reservations are also available. The group rate expires on May 24, 2010, or when the room block is full. See http://www.nanog.org for more information on the meeting, and follow the links to register and reserve your hotel room. See you in San Francisco! Steve Feldman NANOG Steering Committee chair _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From tkapela at gmail.com Fri Mar 26 19:19:28 2010 From: tkapela at gmail.com (Anton Kapela) Date: Fri, 26 Mar 2010 20:19:28 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <20100326234832.GB13305@angus.ind.WPI.EDU> References: <20100326220922.GH12189@angus.ind.WPI.EDU> <20100326234832.GB13305@angus.ind.WPI.EDU> Message-ID: On Mar 26, 2010, at 7:48 PM, Chuck Anderson wrote: > If you have 2 network jacks next to each other in a conference room, > do they each get configured as a separate "user"? Indeed, most of the buildings have a 'community room' like that -- but all the deployed ports (unless ordered differently) will get incrementing-vlan assignments, so indeed, they'd be different vlans back to l3 core. > What happens if a > user connects them together? Nothing, basically, as the network from edge port towards IP edge is (or should be) loop-free. The router will hear DHCP req's on 2x ints, but the client will (should) pick the first-heard response. Depending on the DHCP client implementation, it may wedge/break, but I haven't encountered one in testing. For higher-availability from edge towards IP core, LACP/PAGP provides link-independence, and UDLD/802 OAM provide something of a decent safety-net for breakage detection in metro-spans over other providers/resellers. > What happens if a user plugs a desktop > switch into one of them, then connects two ports on *that* switch > together? In my example config, bcast or mcast over 100 pps shuts the port that's receiving the bcast or mcast's down -- but, that's a configurable action. It could discard them, police them, or just report a syslog/trap to the NMS... Of course, this is all switch-vendor specific, etc. > Would this work in a collapsed L2/L3 core (no agg, no L3 at edge)? Oh, indeed -- and is. The UTOPIA network (http://www.utopianet.org/) in SLC, Utah, is doing basically this for it's ISP-reseller tiers. ISP's get customers on vlans or Q-stacked vlans, and do what they will with it. The ISP's I've talked with have tended to use Juni ERX for this, but there's nothing stopping one from using IOS, or another vendor that can do this trick. It just implies something to consider in the layer2 transport network (support for man l2 addrs in cam, QinQ, etc) at design-time. > When doing 1:1 VLAN:Port mapping, can you do more than 4096 > VLANs/ports? Or are you doing QinQ? Indeed -- q-stacking enables this. In most cases, I don't backhaul more than a few hundred vlans per building -- if it's over 200 to 250 ports/jacks, I generally drop local 3550/3560/3750 or cpu-based boxes on-site, routing towards the metro edge/backbone. > Cool, but I'm not sure this will work in my non-Cisco campus > environment with 10,000 edge ports. Ahh; a pickle. C and J do indeed enable this in many of the popular boxes, which is great. That's not to say other vendors don't have something like it--the concept is perhaps the most valuable bit to discuss here, imho; the vendor-particulars are less important. -Tk From owen at delong.com Fri Mar 26 19:38:30 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Mar 2010 17:38:30 -0700 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: References: <20100326220922.GH12189@angus.ind.WPI.EDU> Message-ID: <2D6A0E72-28BA-489D-A3C8-8D7BAAAD0002@delong.com> On Mar 26, 2010, at 4:33 PM, Mark Foster wrote: > >> "Desktop" switches. You know, those 4 or 5 port Gigabit Ethernet >> switches. Apparently, many of them don't do any kind of STP at all. >> Recommendations on ones that do STP? > > If the network fabric you're on is important enough to cause you grief in the event of a STP event, you shouldn't be fielding 'dumb' switches. > > Even the 'dumbest' switch I would ever place into user-space is fully managable, layer 2 with VLAN's and STP support. That is, it's in a cabinet or TC and fed by infrastructure cabling, and the only folks who can get at it are the engineers and techs supporting the site. > > The other side of things is that if DHCP times out once during STP negotiation, it rarely times out twice. Users whos machines are 'dynamically connected' often enough to have STP related glitches in their DHCP grab should know enough to hit 'repair' or run ipconfig /renew - or should be told to reboot :-) > or reboot is problematic in many cases. Many systems drop link-state during reboot for a long-enough period that the bridge-port restarts its spanning tree process, making results across reboots consistently bad. >> RSTP: is it any better than traditional STP in regards to "edge" ports >> and blocking before a loop gets out of hand? Or perhaps blocking for >> 5-10 seconds before going into Forwarding state, hopefully preventing >> loops before they happen but also allowing DHCP clients to get an >> address without timeouts? Recommendations on "Desktop" switches that >> do RSTP? > > There's plenty of desktop switches out there which are close to 'fully featured' - but obviously there's money involved. If your uplink switch (at the very least) supports STP then at least you can isolate the problem if the switch itself can't handle, but I wouldn't recommend this. > With the additional advantage that the uplink switch link to the conference-room switch doesn't flap often enough to cause DHCP issues, but, will shut down the port if properly configured and the conference-room switch at least passes the BPDUs around the loop. Owen From jcurran at arin.net Fri Mar 26 20:24:07 2010 From: jcurran at arin.net (John Curran) Date: Fri, 26 Mar 2010 21:24:07 -0400 Subject: ARIN negotiation? In-Reply-To: References: Message-ID: <7F4B94AB-4E5E-4671-8ECE-75EA32DCCFC3@arin.net> Hello Jeremy - So let's see if I can clarify some of your questions: - ARIN doesn't generally modify the terms of the RSA agreement (this is a fairness issue so that all address holders are under similar terms to the extent possible) - We've actually revised the RSA on several occasions to make the language more member-friendly. The most recent change was the release in February 2009 of RSA 10.0, noted here: I'd recommend referring your legal team to this announcement and related FAQ documents, as we've tried to make as much of background information and reasoning available as possible. - If there are changes that your legal department would like to suggest, I would like to hear about them, and they'll be considered to see if they can be accommodated in a future revision to be made available for all members. Email is the best way to reach me, but I can also be tracked down at my ARIN office number (+1 703 227 9850). Thanks! /John John Curran President and CEO ARIN On Mar 26, 2010, at 5:45 PM, Jeremy Charles wrote: > Has anyone here had their legal department balk at the legal agreement that ARIN wants you to sign when you get things like an AS number or an IP block? Any luck in negotiating with ARIN? > > The agreement has language at the top saying that ARIN doesn't accept modifications, but our legal team is questioning whether that means it really is non-negotiable. They're not exactly fans of it as it is written. From blakjak at blakjak.net Fri Mar 26 20:24:05 2010 From: blakjak at blakjak.net (Mark Foster) Date: Sat, 27 Mar 2010 14:24:05 +1300 (NZDT) Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <2D6A0E72-28BA-489D-A3C8-8D7BAAAD0002@delong.com> References: <20100326220922.GH12189@angus.ind.WPI.EDU> <2D6A0E72-28BA-489D-A3C8-8D7BAAAD0002@delong.com> Message-ID: > or reboot is problematic in many cases. Many systems drop link-state during reboot for a long-enough period that the bridge-port restarts its spanning tree process, making results across reboots consistently bad. Interesting; Windows tends to bring link up well-prior to the login dialogue and ive never seen a dhcp lease fail such that the user has had no lease by the time they try to login... From mysidia at gmail.com Fri Mar 26 20:29:52 2010 From: mysidia at gmail.com (James Hess) Date: Fri, 26 Mar 2010 20:29:52 -0500 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C8F@PUR-EXCH07.ox.com> References: <20100326220922.GH12189@angus.ind.WPI.EDU> <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C8F@PUR-EXCH07.ox.com> Message-ID: <6eb799ab1003261829w6a716562wa732c1b2da32dd9a@mail.gmail.com> On Fri, Mar 26, 2010 at 5:21 PM, Matthew Huff wrote: > Bpduguard if running cisco. set all the switch ports to bpduguard or enable it globally Bpduguarding a cool idea, and not a bad protective measure, if running that vendor's equipment, but it still allows a possibly large disruption for the (small) duration until the first BPDU is received and relies on reasonable operation from the thing creating a loop -- the guard is a no-op if whatever crosses jacks does not pass STP PDUs. Whether it is enough, depends on your threshold of pain for looping, packet loss, and the frequency of conference room physical configuration errors. Most all switch manufacturers provide some type of port security feature that allows an end-user connection port to automatically be disabled and require admin intervention to re-activate, if the number of MAC addresses exceed a configurable number, e.g. allow 5 MAC addresses, which are remembered as that port's list of "secured" MAC addresses with an aging time of 5 minutes. Use that function, and use the functions of a switch that provide storm control for client ports. With a reasonable aging duration for expiring secured MAC addresses. If a client port emits packets with more than the expected number of MAC address sources within a short time, then that should be an early warning that traffic has taken an improper path. Keeping in mind a loop doesn't necessarily create an instant issue, until there is other broadcast traffic on the network, that crosses the loop, and starts messing up the CAM table on the upstream device, as well as possibly generating duplicate traffic. But with port security, the number of devices that lose packets due to the loop should be limited (the smaller you set the limit without impacting legitimate use of the port, the better). -- -J From JCharles at epic.com Fri Mar 26 20:38:24 2010 From: JCharles at epic.com (Jeremy Charles) Date: Fri, 26 Mar 2010 20:38:24 -0500 Subject: ARIN negotiation? In-Reply-To: <7F4B94AB-4E5E-4671-8ECE-75EA32DCCFC3@arin.net> References: <7F4B94AB-4E5E-4671-8ECE-75EA32DCCFC3@arin.net> Message-ID: Thanks to those who replied to offer experience and input on working with ARIN. You've given me some helpful information to pass along to our legal team when considering the RSA. Cheers! -JC From cra at WPI.EDU Fri Mar 26 21:29:00 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 26 Mar 2010 22:29:00 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <6eb799ab1003261829w6a716562wa732c1b2da32dd9a@mail.gmail.com> References: <20100326220922.GH12189@angus.ind.WPI.EDU> <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C8F@PUR-EXCH07.ox.com> <6eb799ab1003261829w6a716562wa732c1b2da32dd9a@mail.gmail.com> Message-ID: <20100327022900.GA22292@angus.ind.WPI.EDU> On Fri, Mar 26, 2010 at 08:29:52PM -0500, James Hess wrote: > Most all switch manufacturers provide some type of port security > feature that allows an end-user connection port to automatically be > disabled and require admin intervention to re-activate, if the number > of MAC addresses exceed a configurable number, e.g. allow 5 MAC > addresses, which are remembered as that port's list of "secured" MAC > addresses with an aging time of 5 minutes. In fact, the last time this happened, I implemented exactly what you describe, mac-security with a limit of 5 MACs. The security kicked in and shutdown the port, but not before the core shutdown the edge switch's uplinks (see below). > Use that function, and use the functions of a switch that provide > storm control for client ports. With a reasonable aging duration > for expiring secured MAC addresses. Have that. > If a client port emits packets with more than the expected number > of MAC address sources within a short time, then that should be an > early warning that traffic has taken an improper path. Have that. > Keeping in mind a loop doesn't necessarily create an instant issue, > until there is other broadcast traffic on the network, that crosses > the loop, and starts messing up the CAM table on the upstream device, > as well as possibly generating duplicate traffic. Which pretty much means within milliseconds on my network. > But with port security, the number of devices that lose packets due to > the loop should be limited (the smaller you set the limit without > impacting legitimate use of the port, the better). So basically, the problem is the core switches implement a proprietary loop-prevention protocol that sends "beacon" frames out every 500ms, and if a certain number of these special frames come back (exceeds threshold) it shuts down the port. Even with a 10:1 ratio of threshold settings on the two redundant links to the edge switch, it still trips both thresholds fast enough that both redundant links get shutdown in the short time before the edge switch's protection mechanism (mac-security, STP, bpduprotect, whatever) kicks in. I've now set the ratio to 100:1 (500:5 in actual packet counts) and the transmit interval to 1000ms in the hopes that at least one core link will survive long enough for the edge port to shutdown and break the loop first, but I'm beginning to think that this protocol is crap and I should just disable it and let the core ride out the loop in the hopes that it survives without taking down the entire core before the edge switch shutdown happens. The good news is that this core is being replaced soon, hopefully with gear that will be able to implement a service-provider-like design with per-port VLAN separation as was suggested in this thread. But it surprises me that low-end switch vendors (like NetGear) still put out crap that doesn't do STP, especially when the switch does Auto MDI/MDI-X, which is just asking for trouble. Anyone know if Auto MDI/MDI-X is inherent or required in 1000Base-T? It would be nice if I could shut it off. Thanks for all the ideas. From mysidia at gmail.com Fri Mar 26 23:13:11 2010 From: mysidia at gmail.com (James Hess) Date: Fri, 26 Mar 2010 23:13:11 -0500 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <20100327022900.GA22292@angus.ind.WPI.EDU> References: <20100326220922.GH12189@angus.ind.WPI.EDU> <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C8F@PUR-EXCH07.ox.com> <6eb799ab1003261829w6a716562wa732c1b2da32dd9a@mail.gmail.com> <20100327022900.GA22292@angus.ind.WPI.EDU> Message-ID: <6eb799ab1003262113q478f67b3h8b5448de50e5ff64@mail.gmail.com> On Fri, Mar 26, 2010 at 9:29 PM, Chuck Anderson wrote: > So basically, the problem is the core switches implement a proprietary > loop-prevention protocol that sends "beacon" frames out every 500ms, > and if a certain number of these special frames come back (exceeds --> loop first, but I'm beginning to think that this protocol is crap and > I should just disable it and let the core ride out the loop in the Ah, nasty.. it seems like you definitely should want to keep the beacon frames from getting injected then. Taking down core links ought to be harder than 1 user emitting a few frames. A malicious user, or a naive user with a malicious trojan on their computer could try to send fake beacons, to cause trouble. I for one might start thinking if the beacons can be sunk from end user ports by brute force, using a Layer 2 ACL. I wonder if RFC 5556, IETF TRILL specs, or 802.1aq/802.1Qbb / Datacenter Ethernet / Bridging standards and more robust standards-based loop avoidance standards will ever get finalized, considering they have been drafts for over 5 years, it seems like the standardization is very sluggish. A new protocol is probably the right solution, but it might not be ready until 2015 at this rate. > Anyone know if Auto MDI/MDI-X is inherent or required in 1000Base-T? > It would be nice if I could shut it off. Auto MDI/MDI-X is an optional feature in the 1000BaseT standard. Automatic negotiation of speeds and duplex, is mandatory due to 802.3ab, but not auto-crossover You can get that here http://standards.ieee.org/getieee802/802.3.html Clause 40.4.4 in IEEE 802.3-2008 -- Section Three states the following: "40.4.4 Automatic MDI/MDI-X Configuration Automatic MDI/MDI-X Configuration is intended to eliminate the need for crossover cables between simi lar devices. Implementation of an automatic MDI/MDI-X configuration is optional for 1000BASE-T devices. If an automatic configuration method is used, it shall comply with the following specifications. The assignment of pin-outs for a 1000BASE-T crossover function cable is shown in Table40?12 in 40.8. " -- -J From sking at kingrst.com Fri Mar 26 23:16:17 2010 From: sking at kingrst.com (Steven King) Date: Sat, 27 Mar 2010 00:16:17 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C8F@PUR-EXCH07.ox.com> References: <20100326220922.GH12189@angus.ind.WPI.EDU> <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C8F@PUR-EXCH07.ox.com> Message-ID: <4BAD8691.8060009@kingrst.com> Along with bpduguard, Cisco switches also continue to look for loops with loopguard. They continuously look for the Keepalive packets that they send out each port. So as long as you have not turned off STP all together on the port, you will be fine. On 3/26/10 6:21 PM, Matthew Huff wrote: > Bpduguard if running cisco. > > set all the switch ports to bpduguard or enable it globally > > > -----Original Message----- > From: Chuck Anderson [mailto:cra at WPI.EDU] > Sent: Friday, March 26, 2010 6:09 PM > To: nanog at nanog.org > Subject: Auto MDI/MDI-X + conference rooms + bored == loop > > Anyone have suggestions on Ethernet LAN loop-prevention? With the > advent of Auto MDI/MDI-X ports on switches, it seems way too easy to > accidentally or maliciously create loops between network jacks. We > have bored or inattentive people plugging in patch cords between > adjacent network jacks. STP for loop-prevention isn't working so well > for us. > > STP "edge" or "portfast" or "faststart" modes are required for > end-station ports (with normal STP, DHCP often times out after 30+ > seconds it takes to go into Forwarding state). Since the "edge" STP > mode goes into Forwarding state immediately, there is a period when > loops will form, causing havok with upstream gear until STP blocks the > port (if it ever does see below). > > "Desktop" switches. You know, those 4 or 5 port Gigabit Ethernet > switches. Apparently, many of them don't do any kind of STP at all. > Recommendations on ones that do STP? > > RSTP: is it any better than traditional STP in regards to "edge" ports > and blocking before a loop gets out of hand? Or perhaps blocking for > 5-10 seconds before going into Forwarding state, hopefully preventing > loops before they happen but also allowing DHCP clients to get an > address without timeouts? Recommendations on "Desktop" switches that > do RSTP? > > Thanks for your suggestions/discussion. > > -- Steve KingSenior Senior Linux Engineer - Advance Internet, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From msokolov at ivan.Harhan.ORG Sat Mar 27 00:28:13 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Sat, 27 Mar 2010 05:28:13 GMT Subject: Auto MDI/MDI-X + conference rooms + bored == loop Message-ID: <1003270528.AA03201@ivan.Harhan.ORG> James Hess wrote: > Auto MDI/MDI-X is an optional feature in the 1000BaseT standard. Can someone please explain how can the whole MDI vs. MDI-X distinction be meaningful at all for 1000BaseT? I thought they run 250 Mbps on each of the 4 pairs in both directions using some form of echo-cancelling hybrid techniques. If one no longer has separate Rx and Tx pins, how is it meaningful to talk about MDI or MDI-X? I thought that for 1000BaseT a straight-through cable was always the "native" cable choice for connecting any two ports, be they switch ports or station ports - is that not true? It also seems to me that a crossover cable should never make sense for 1000BaseT, but from what I understand such cables do work because the PHYs are generally smart enough to detect "hey, I'm seeing signal on pair B that ought to be on pair C" and auto-correct. MS From owen at delong.com Sat Mar 27 04:11:32 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 27 Mar 2010 02:11:32 -0700 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <20100327022900.GA22292@angus.ind.WPI.EDU> References: <20100326220922.GH12189@angus.ind.WPI.EDU> <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C8F@PUR-EXCH07.ox.com> <6eb799ab1003261829w6a716562wa732c1b2da32dd9a@mail.gmail.com> <20100327022900.GA22292@angus.ind.WPI.EDU> Message-ID: On Mar 26, 2010, at 7:29 PM, Chuck Anderson wrote: > On Fri, Mar 26, 2010 at 08:29:52PM -0500, James Hess wrote: >> Most all switch manufacturers provide some type of port security >> feature that allows an end-user connection port to automatically be >> disabled and require admin intervention to re-activate, if the number >> of MAC addresses exceed a configurable number, e.g. allow 5 MAC >> addresses, which are remembered as that port's list of "secured" >> MAC >> addresses with an aging time of 5 minutes. > > In fact, the last time this happened, I implemented exactly what you > describe, mac-security with a limit of 5 MACs. The security kicked in > and shutdown the port, but not before the core shutdown the edge > switch's uplinks (see below). > >> Use that function, and use the functions of a switch that provide >> storm control for client ports. With a reasonable aging duration >> for expiring secured MAC addresses. > > Have that. > >> If a client port emits packets with more than the expected number >> of MAC address sources within a short time, then that should be an >> early warning that traffic has taken an improper path. > > Have that. > >> Keeping in mind a loop doesn't necessarily create an instant issue, >> until there is other broadcast traffic on the network, that crosses >> the loop, and starts messing up the CAM table on the upstream >> device, >> as well as possibly generating duplicate traffic. > > Which pretty much means within milliseconds on my network. > Sounds like you forgot to configure the "Root is that-way ->" sanity check on your switches. Make sure that Root bridge can't be determined to be in a direction other than "upstream" will help a lot with this. >> But with port security, the number of devices that lose packets due >> to >> the loop should be limited (the smaller you set the limit without >> impacting legitimate use of the port, the better). > > So basically, the problem is the core switches implement a proprietary > loop-prevention protocol that sends "beacon" frames out every 500ms, > and if a certain number of these special frames come back (exceeds > threshold) it shuts down the port. Even with a 10:1 ratio of That's Icky... Can you replace that with traditional spanning tree? It's just too sensitive for a deployment of any real size. > threshold settings on the two redundant links to the edge switch, it > still trips both thresholds fast enough that both redundant links get > shutdown in the short time before the edge switch's protection > mechanism (mac-security, STP, bpduprotect, whatever) kicks in. I've > now set the ratio to 100:1 (500:5 in actual packet counts) and the > transmit interval to 1000ms in the hopes that at least one core link > will survive long enough for the edge port to shutdown and break the > loop first, but I'm beginning to think that this protocol is crap and > I should just disable it and let the core ride out the loop in the > hopes that it survives without taking down the entire core before the > edge switch shutdown happens. > Yes, I think that would be much better. (Of course, another alternative would be traditional spanning tree, or, some variant of STP with faster timers). > The good news is that this core is being replaced soon, hopefully with > gear that will be able to implement a service-provider-like design > with per-port VLAN separation as was suggested in this thread. But it > surprises me that low-end switch vendors (like NetGear) still put out > crap that doesn't do STP, especially when the switch does Auto > MDI/MDI-X, which is just asking for trouble. > Usually people don't use Netgear cheap switches in environments with more than a desktop worth of topology. > Anyone know if Auto MDI/MDI-X is inherent or required in 1000Base-T? > It would be nice if I could shut it off. > Yes, it is. (This is actually a good thing in everyone else's environment). Owen From bmanning at vacation.karoshi.com Sat Mar 27 07:33:54 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 27 Mar 2010 12:33:54 +0000 Subject: IP4 Space - IVI et.al. In-Reply-To: <201003261721.11474.lowen@pari.edu> References: <7BD730BB-3F77-41B2-AA89-F47C4B60AA2B@delong.com> <201003261721.11474.lowen@pari.edu> Message-ID: <20100327123354.GA15815@vacation.karoshi.com.> Thanks for sharing. I think your/our circumstances are shared by many folks who have a network to run, budgets to stck to, and technology to adopt. Not everyone has a massive core network with 10s of thousands of downstream clients. A few years ago I attended a SIGCOM mtg and was on a pannel talking about IPv6. One of the pannelests was XingLi of CERN, who presented their v4/v6 translator code that supports over 400,000 chinese academics on native IPv6 - the IPv4 was relegated to the translator box and the DNS. I run the code at my home (we have been native IPv6 only for about 3 years now) on old hard ware (a 386 with 2 at 100m nics) and it is rock solid. We have runs demos at ARIN mtgs, and I2/Joint Techs workshops for a few years as well. The IETF is grappling with the same issues, wiht multiple alternatives being discussed. Another technique, based on slightly different design criteria can be had from ISC (your favorite DNS and DHCP code supplier). Their product is called AFTR. For really high end stuff, my friend Charlie has developed a box that will translate for 100k/10m nodes or so - truely a carrier-grade box. Both IVI and (perhaps) AFTR will give you the ability to move small (100-1000) networks to a native IPv6, with a thin IPv4 veneer on the perimeter. So it is possible to decompose the problem into small, bite-sized chunks and not have to worry about your upstream leading the say. You can use old kit and not have to deploy lots of new gear. So it might be worthwhile to consider this from a "grass-roots" perspective. Another PoV to consider. --bill From cra at WPI.EDU Sat Mar 27 09:57:51 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 27 Mar 2010 10:57:51 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: References: <20100326220922.GH12189@angus.ind.WPI.EDU> <483E6B0272B0284BA86D7596C40D29F9E2BEEC6C8F@PUR-EXCH07.ox.com> <6eb799ab1003261829w6a716562wa732c1b2da32dd9a@mail.gmail.com> <20100327022900.GA22292@angus.ind.WPI.EDU> Message-ID: <20100327145751.GA708@angus.ind.WPI.EDU> On Sat, Mar 27, 2010 at 02:11:32AM -0700, Owen DeLong wrote: > Sounds like you forgot to configure the "Root is that-way ->" sanity > check on your switches. Make sure that Root bridge can't be > determined to be in a direction other than "upstream" will help > a lot with this. No STP in the core, only on the managed edges. >> So basically, the problem is the core switches implement a proprietary >> loop-prevention protocol that sends "beacon" frames out every 500ms, >> and if a certain number of these special frames come back (exceeds >> threshold) it shuts down the port. Even with a 10:1 ratio of > > That's Icky... Can you replace that with traditional spanning tree? > It's just too sensitive for a deployment of any real size. STP is eliminated by vendor's design recommendations. Active/active split LAG across two core boxes. But yes, I agree that this design is proving--lacking. >> The good news is that this core is being replaced soon, hopefully with >> gear that will be able to implement a service-provider-like design >> with per-port VLAN separation as was suggested in this thread. But it >> surprises me that low-end switch vendors (like NetGear) still put out >> crap that doesn't do STP, especially when the switch does Auto >> MDI/MDI-X, which is just asking for trouble. >> > Usually people don't use Netgear cheap switches in environments with > more than a desktop worth of topology. We don't generally put them in, users do. There are a few cases where we have a dearth of cable or conduit space and needed something small and quiet to put there. Hence my question about better switches to use in those scenarios. >> Anyone know if Auto MDI/MDI-X is inherent or required in 1000Base-T? >> It would be nice if I could shut it off. >> > Yes, it is. (This is actually a good thing in everyone else's > environment). It's easy to claim that no one else but me has this problem. Designing a "dekstop" switch that makes it easy to create accidental loops, but then has no loop-prevention mechanism seems irresponsible to me... From guifort at live.com Sat Mar 27 12:10:33 2010 From: guifort at live.com (Guillaume FORTAINE) Date: Sat, 27 Mar 2010 18:10:33 +0100 Subject: Useful URL for network operators Message-ID: Misses, Misters, FYI : http://tools.bgp4.jp/index.php?tools%20team/tools? Best Regards, Guillaume FORTAINE? _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 From nathan at atlasnetworks.us Sat Mar 27 13:06:45 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sat, 27 Mar 2010 11:06:45 -0700 Subject: Recommendations for small (5-10 port) IGMP switch Message-ID: <11B064048F34FD4094CBA16FC04BE219044A04063E@ex01> Hello List, I'm looking for recommendations for switches between 5 and 10 ports that meet the following specifications: 1) Sub-$150 USD 2) Can untag vlans 3) Multicast capable a. Capable of 30+ multicast groups Best Regards, Nathan Eisenberg From randy at psg.com Sat Mar 27 13:36:52 2010 From: randy at psg.com (Randy Bush) Date: Sat, 27 Mar 2010 11:36:52 -0700 Subject: Useful URL for network operators In-Reply-To: References: Message-ID: could you please keep a constant email address so we don't have to keep adding to our mail filters? thanks. randy From ml at kenweb.org Sat Mar 27 13:56:17 2010 From: ml at kenweb.org (ML) Date: Sat, 27 Mar 2010 14:56:17 -0400 Subject: Recommendations for small (5-10 port) IGMP switch In-Reply-To: <11B064048F34FD4094CBA16FC04BE219044A04063E@ex01> References: <11B064048F34FD4094CBA16FC04BE219044A04063E@ex01> Message-ID: <4BAE54D1.2010504@kenweb.org> On 3/27/2010 2:06 PM, Nathan Eisenberg wrote: > Hello List, > > I'm looking for recommendations for switches between 5 and 10 ports that meet the following specifications: > > 1) Sub-$150 USD > 2) Can untag vlans > 3) Multicast capable > a. Capable of 30+ multicast groups > > Best Regards, > Nathan Eisenberg > > Netgear GS108T. I've never tried it with that many active multicast groups though. From LarrySheldon at cox.net Sat Mar 27 14:19:25 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 27 Mar 2010 14:19:25 -0500 Subject: Useful URL for network operators In-Reply-To: References: Message-ID: <4BAE5A3D.4080804@cox.net> On 3/27/2010 12:10, Guillaume FORTAINE wrote: nymshifting son of a ..... More stringent measures are required. From tkapela at gmail.com Sun Mar 28 00:20:04 2010 From: tkapela at gmail.com (Anton Kapela) Date: Sun, 28 Mar 2010 01:20:04 -0400 Subject: BGP Update Report In-Reply-To: <201003192200.o2JM01vK037512@wattle.apnic.net> References: <201003192200.o2JM01vK037512@wattle.apnic.net> Message-ID: So, this week, I actually read the update report. Noting the stats below (..a flap/update once per minute? please, fix your CPE router), I have but one humble request: Could the settlement-free members of the DFZ please consider re-enabling route-flap dampening towards customers? Thanks, -Tk > Rank Prefix Upds % Origin AS -- AS Name > 1 - 62.168.199.0/24 13100 1.1% AS31055 -- CONSULTIX-AS Consultix GmbH > 2 - 208.98.230.0/24 8216 0.7% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary > 3 - 208.98.231.0/24 7195 0.6% AS26025 -- COC - City of Calgary > 4 - 155.230.0.0/16 5927 0.5% AS10052 -- KNU-AS Kyungpook National Univ. > 5 - 210.92.10.0/24 5895 0.5% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. > 6 - 210.92.6.0/24 5895 0.5% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. > 7 - 210.92.4.0/24 5895 0.5% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. > 8 - 123.140.107.0/24 5893 0.5% AS45985 -- DAEWOOSEC Daewoo Securities Co., Ltd. > 9 - 214.15.217.0/24 5673 0.5% AS27097 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center > 10 - 41.235.80.0/24 5590 0.5% AS8452 -- TEDATA TEDATA > 11 - 199.114.154.0/24 3567 0.3% AS1733 -- CENTAF-SWA - 754th Electronic Systems Group > 12 - 85.60.192.0/23 3060 0.3% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones > 13 - 206.184.16.0/24 2874 0.2% AS174 -- COGENT Cogent/PSI > 14 - 205.101.192.0/24 2658 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center > 15 - 205.109.96.0/20 2658 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center > 16 - 205.109.208.0/20 2657 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center > 17 - 205.109.160.0/19 2651 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center > 18 - 205.110.243.0/24 2647 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center > 19 - 205.101.66.0/24 2646 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center > 20 - 199.121.123.0/24 2638 0.2% AS665 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center From swmike at swm.pp.se Sun Mar 28 01:32:08 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 28 Mar 2010 08:32:08 +0200 (CEST) Subject: things to test Message-ID: I've been pondering what aspects of a residential broadband connection that would be worthwhile in testing, which would also be some kind of incentive for ISPs to start doing "better". Some things that comes to mind: speed latency to some points geographically near the user MTU of the connection If PMTUD works or not queueing (FIFO or something "better") antispoofing (BCP38) compliance filtering (IPv6 transition protocols for instance, lots more possible) buffer depth ingress/egress ECN ISP provided DNS resolver properties (DNSSEC, EDNS etc) I'm sure there are lots more, and this could probably not be done using a web browser driven application, but instead would have to be an application, thus harder to get people to use generally. Any work being done in this area already that someone can point to? I'd also like to use some of this tech to do "web server tests", especially when it comes to PMTUD working, especially when for a IPv6 world it would be nice to have an easily available testing suite for these basic mechanisms. -- Mikael Abrahamsson email: swmike at swm.pp.se From jul_bsd at yahoo.fr Sun Mar 28 07:04:39 2010 From: jul_bsd at yahoo.fr (jul) Date: Sun, 28 Mar 2010 14:04:39 +0200 Subject: DNS TXT field usage ? Message-ID: <4BAF45D7.5000102@yahoo.fr> Hello, While watching some parked domains, I recently observed one which has a TXT field containing some crypto value, something like a ssh key/RSA 512 or 1024 output (only the crypto part 'cvxvcvcxvcxv=' ). For now, I have referenced the following usage of TXT - DNS Server information/version - SPF (format like "v=spf1 a mx -all") [1] - DKIM (format like "k=rsa\; t=y\; p=MIGfMA0GCSqGSIb3 [...] YA+OwSMWQIDAQAB", but always in _domainkey.) [2] - not DNSSec as I supposed first (only DNSKEY, RR, RSIG, NSEC, not TXT) Does someone know at what kind of usage this kind of value could correspond ? (even if, nearly everything is possible) Maybe somebody knows of a webpage referencing common usage of DNS fields ? I found http://www.iana.org/assignments/dns-parameters but it points only on RFC not practical usage. Thanks a lot. Best regards, Jul [1] http://en.wikipedia.org/wiki/Sender_Policy_Framework [2] http://www.ietf.org/rfc/rfc4871.txt (7.4) Note: current RFC referencing TXT field is http://www.ietf.org/rfc/rfc1035.txt "TXT RRs are used to hold descriptive text." From nanog-post at rsuc.gweep.net Sun Mar 28 07:34:26 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sun, 28 Mar 2010 08:34:26 -0400 Subject: DNS TXT field usage ? In-Reply-To: <4BAF45D7.5000102@yahoo.fr> References: <4BAF45D7.5000102@yahoo.fr> Message-ID: <20100328123426.GA59866@gweep.net> On Sun, Mar 28, 2010 at 02:04:39PM +0200, jul wrote: > Hello, > > While watching some parked domains, I recently observed one which has a > TXT field containing some crypto value, something like a ssh key/RSA 512 > or 1024 output (only the crypto part 'cvxvcvcxvcxv=' ). If the TXT data is a large wodge which changes, and/or there are fluctuating interesting labels within the zone, then it isn't parked but is being used for IP-over-DNS tunneling. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From nanog-post at rsuc.gweep.net Sun Mar 28 08:29:43 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sun, 28 Mar 2010 09:29:43 -0400 Subject: BGP Update Report In-Reply-To: References: <201003192200.o2JM01vK037512@wattle.apnic.net> Message-ID: <20100328132943.GB59866@gweep.net> On Sun, Mar 28, 2010 at 01:20:04AM -0400, Anton Kapela wrote: > So, this week, I actually read the update report. Noting the stats below (..a flap/update once per minute? please, fix your CPE router), I have but one humble request: > > Could the settlement-free members of the DFZ please consider > re-enabling route-flap dampening towards customers? The problem is that unless one is holding customer routes in a seperate VRF and dampen them there or take similar steps to segment, dampening leads directly to blackholes. Even in that case, failover within that VRF wouldn't work, as all implementations I've seen attack the prefix as the problem instead of the path vector. Bye-bye alternate paths. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From LarrySheldon at cox.net Sun Mar 28 08:51:51 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 28 Mar 2010 08:51:51 -0500 Subject: Blacklist entry Message-ID: <4BAF5EF7.5090307@cox.net> For some reason I am getting a ton of "DNR" spam from blackberry.net with Subject: lines that imply that somebody here is the culprit. (Hence this message here.) I am blacklisting "blackberry.net" in an effort to reduce the spam load here. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From Valdis.Kletnieks at vt.edu Sun Mar 28 12:00:13 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 28 Mar 2010 13:00:13 -0400 Subject: Blacklist entry In-Reply-To: Your message of "Sun, 28 Mar 2010 08:51:51 CDT." <4BAF5EF7.5090307@cox.net> References: <4BAF5EF7.5090307@cox.net> Message-ID: <12352.1269795613@localhost> On Sun, 28 Mar 2010 08:51:51 CDT, Larry Sheldon said: > For some reason I am getting a ton of "DNR" spam from blackberry.net > with Subject: lines that imply that somebody here is the culprit. > (Hence this message here.) I figured it was just another case of something that *still* doesn't understand the semantic difference between RFC821 MAIL FROM: and RFC822 From: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From LarrySheldon at cox.net Sun Mar 28 12:08:39 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 28 Mar 2010 12:08:39 -0500 Subject: Blacklist entry In-Reply-To: <12352.1269795613@localhost> References: <4BAF5EF7.5090307@cox.net> <12352.1269795613@localhost> Message-ID: <4BAF8D17.7030806@cox.net> On 3/28/2010 12:00, Valdis.Kletnieks at vt.edu wrote: > On Sun, 28 Mar 2010 08:51:51 CDT, Larry Sheldon said: >> For some reason I am getting a ton of "DNR" spam from blackberry.net >> with Subject: lines that imply that somebody here is the culprit. >> (Hence this message here.) > > I figured it was just another case of something that *still* doesn't understand > the semantic difference between RFC821 MAIL FROM: and RFC822 From: I'm comfortable with "....what stupidity is sufficient to explain." I figure they are not bright enough to be malicious. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From tkapela at gmail.com Sun Mar 28 13:00:55 2010 From: tkapela at gmail.com (Anton Kapela) Date: Sun, 28 Mar 2010 14:00:55 -0400 Subject: BGP Update Report In-Reply-To: <20100328132943.GB59866@gweep.net> References: <201003192200.o2JM01vK037512@wattle.apnic.net> <20100328132943.GB59866@gweep.net> Message-ID: <226B7CBF-ED2E-40A1-A3BC-DD9C43C71C0D@gmail.com> Joe, > The problem is that unless one is holding customer routes in a > seperate VRF and dampen them there or take similar steps to > segment, dampening leads directly to blackholes. Even in that > case, failover within that VRF wouldn't work, as all > implementations I've seen attack the prefix as the problem instead > of the path vector. Bye-bye alternate paths. I guess what I'm hinting at is precisely something finer-grained (path not prefix), as you suggest. Per-neighbor enabled, versus "entire bgp RIB" would be preferred. I'm also interested in the *chronic* nature of these apparent instabilities. An average of one flap per minute could imply that the end-site is not getting allot of useful TCP moved, and as such, after something on the (n)-hour timescale, perhaps it's worth suppressing it. So, I'd ask for a long-timescale dampening function, indexed against per-path, and enforced per neighbor. Perhaps as-path lists could be combined with relaxed timers on existing implementations to achieve this today (in a VRF target/context). -Tk From simon.leinen at switch.ch Sun Mar 28 14:07:30 2010 From: simon.leinen at switch.ch (Simon Leinen) Date: Sun, 28 Mar 2010 21:07:30 +0200 Subject: things to test In-Reply-To: (Mikael Abrahamsson's message of "Sun, 28 Mar 2010 08:32:08 +0200 (CEST)") References: Message-ID: [on residential broadband connections] Mikael Abrahamsson writes: > Some things that comes to mind: > speed > latency to some points geographically near the user > MTU of the connection > If PMTUD works or not > queueing (FIFO or something "better") > antispoofing (BCP38) compliance > filtering (IPv6 transition protocols for instance, lots more possible) > buffer depth ingress/egress > ECN > ISP provided DNS resolver properties (DNSSEC, EDNS etc) That's an excellent start. I would add * availability of global IP addresses (0-n) * ability to connect to "unusual" ports (falls under "filtering") * ability to accept connections * interception of common TCP ports such as 80 and 25 * transparency for various header fields (addresses & ports? DSCP...) * rate-limits for specific protocols (ICMP, BitTorrent...) * latency and throughput for some popular sites/resources, including those using CDNs, at various times of day/week ...and of course... * availability of IPv6 > I'm sure there are lots more, and this could probably not be done > using a web browser driven application, but instead would have to be > an application, thus harder to get people to use generally. > Any work being done in this area already that someone can point to? Check out M-Lab - http://www.measurementlab.net/ -- Simon. From simon.leinen at switch.ch Sun Mar 28 14:08:52 2010 From: simon.leinen at switch.ch (Simon Leinen) Date: Sun, 28 Mar 2010 21:08:52 +0200 Subject: IP4 Space - IVI et.al. In-Reply-To: <20100327123354.GA15815@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Sat, 27 Mar 2010 12:33:54 +0000") References: <7BD730BB-3F77-41B2-AA89-F47C4B60AA2B@delong.com> <201003261721.11474.lowen@pari.edu> <20100327123354.GA15815@vacation.karoshi.com.> Message-ID: bmanning writes: > A few years ago I attended a SIGCOM mtg and was on a pannel talking > about IPv6. One of the pannelests was XingLi of CERN, who presented s/CERN/CERNET/ - credit where credit is due. > their v4/v6 translator code that supports over 400,000 chinese > academics on native IPv6 - the IPv4 was relegated to the translator > box and the DNS. -- Simon. From bmanning at vacation.karoshi.com Sun Mar 28 14:21:40 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 28 Mar 2010 19:21:40 +0000 Subject: IP4 Space - IVI et.al. In-Reply-To: References: <7BD730BB-3F77-41B2-AA89-F47C4B60AA2B@delong.com> <201003261721.11474.lowen@pari.edu> <20100327123354.GA15815@vacation.karoshi.com.> Message-ID: <20100328192140.GB14860@vacation.karoshi.com.> On Sun, Mar 28, 2010 at 09:08:52PM +0200, Simon Leinen wrote: > bmanning writes: > > A few years ago I attended a SIGCOM mtg and was on a pannel talking > > about IPv6. One of the pannelests was XingLi of CERN, who presented > > s/CERN/CERNET/ - credit where credit is due. well... yes. > > > their v4/v6 translator code that supports over 400,000 chinese > > academics on native IPv6 - the IPv4 was relegated to the translator > > box and the DNS. > -- > Simon. From danny at tcb.net Sun Mar 28 14:51:46 2010 From: danny at tcb.net (Danny McPherson) Date: Sun, 28 Mar 2010 13:51:46 -0600 Subject: BGP Update Report In-Reply-To: <226B7CBF-ED2E-40A1-A3BC-DD9C43C71C0D@gmail.com> References: <201003192200.o2JM01vK037512@wattle.apnic.net> <20100328132943.GB59866@gweep.net> <226B7CBF-ED2E-40A1-A3BC-DD9C43C71C0D@gmail.com> Message-ID: On Mar 28, 2010, at 12:00 PM, Anton Kapela wrote: > I guess what I'm hinting at is precisely something finer-grained (path not prefix), as you suggest. Per-neighbor enabled, versus "entire bgp RIB" would be preferred. I'm also interested in the *chronic* nature of these apparent instabilities. An average of one flap per minute could imply that the end-site is not getting allot of useful TCP moved, and as such, after something on the (n)-hour timescale, perhaps it's worth suppressing it. > > So, I'd ask for a long-timescale dampening function, indexed against per-path, and enforced per neighbor. Perhaps as-path lists could be combined with relaxed timers on existing implementations to achieve this today (in a VRF target/context). It's not just AS_PATH, a lot of the reason so many duplicate updates occur (nearly 50% of all updates at times, and often more during the busiest times) is because on the other end implementations don't keep egress advertisement state per attribute (e.g., if cluster_list length just triggered an internal transition then a new update is sent to external peers with no new information because the determining internal attributes are stripped before transmitting the new update), yet those *prefixes* might well be suppressed as a result of the implementation and/or network architecture on the other end of the BGP connection. Then you couple what Joe was pointing out, where intermediate nodes with consistently unstable links or "paths" result in penalizing an entire prefix, not just the unstable paths, and it makes for more brokenness than benefit when route flap damping is employed. It's not that people haven't studied and understand why this occurs, the issue is that implementation optimizations seem to always win out today over systemic state effects (i.e., that "be conservative in what you send" thing doesn't seem to apply in practice, unfortunately). -danny From jay at west.net Sun Mar 28 17:53:26 2010 From: jay at west.net (Jay Hennigan) Date: Sun, 28 Mar 2010 15:53:26 -0700 Subject: Using private APNIC range in US In-Reply-To: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> References: <4c6b8c911003180852t6565a56fs6819aac1c6d5bbe4@mail.gmail.com> Message-ID: <4BAFDDE6.3090609@west.net> On 3/18/10 8:52 AM, Jaren Angerbauer wrote: > Hi all, > > I have a client here in the US, that I just discovered is using a host > of private IPs that (as I understand) belong to APNIC (i.e. > 1.7.154.70, 1.7.154.00-99, etc.) for their web servers. Actually, those are public IPs. The 1/8 block is presently undergoing testing for use as a public network. Private IPs are defined in RFC1918 and don't "belong" to a regional registry. > I'm assuming > that the addresses probably nat to a [US] public IP. If their webservers are located in North America and visible from the Internet, that is probably a valid assumption. "nslookup", "host" or "dig" on the hostname should give you a more definitive answer. > I'm not familiar > enough with the use of private address space outside of ARIN (i.e. > 192.0.0.0, 10.0.0.0, etc) but I figure if their sites are up and > accessible it must be working for them. For some value of "working", that may be accurate today. It is also going to be true for some values of "broken", if not now then in the future. Private address space is not part of ARIN, APNIC, etc. It is global and defined by RFC1918. > I'm just wondering if there > is any recommendation or practice around this -- using private IP > ranges from another country. Thanks. There is no such thing as a "private IP range from a country". Private addresses are global. The recommendation and practice is to use addresses from RFC1918 for private addresses. If these resources need to be visible from the Internet, then NAT to public addresses assigned or allocated to the operator of the system will be needed. Your client should renumber his private addresses to a netblock that is defined in RC1918 such as 10/8, 172.16/12, or 192.168/16 -- -- 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 swmike at swm.pp.se Sun Mar 28 19:36:39 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 29 Mar 2010 02:36:39 +0200 (CEST) Subject: things to test In-Reply-To: References: Message-ID: On Sun, 28 Mar 2010, Simon Leinen wrote: > Check out M-Lab - http://www.measurementlab.net/ Offline suggestions I have received also includes http://netalyzr.icsi.berkeley.edu/ which seems to have some of the test suggestions as well. -- Mikael Abrahamsson email: swmike at swm.pp.se From clonvick at cisco.com Mon Mar 29 08:19:03 2010 From: clonvick at cisco.com (Chris Lonvick) Date: Mon, 29 Mar 2010 06:19:03 -0700 (PDT) Subject: things to test In-Reply-To: References: Message-ID: Hi, I'll toss in that I2 and GEANT have been developing the PerfSONAR toolset. http://www.perfsonar.net/ Regards, Chris On Sun, 28 Mar 2010, Mikael Abrahamsson wrote: > > I've been pondering what aspects of a residential broadband connection that > would be worthwhile in testing, which would also be some kind of incentive > for ISPs to start doing "better". > > Some things that comes to mind: > > speed > latency to some points geographically near the user > MTU of the connection > If PMTUD works or not > queueing (FIFO or something "better") > antispoofing (BCP38) compliance > filtering (IPv6 transition protocols for instance, lots more possible) > buffer depth ingress/egress > ECN > ISP provided DNS resolver properties (DNSSEC, EDNS etc) > > I'm sure there are lots more, and this could probably not be done using a web > browser driven application, but instead would have to be an application, thus > harder to get people to use generally. > > Any work being done in this area already that someone can point to? I'd also > like to use some of this tech to do "web server tests", especially when it > comes to PMTUD working, especially when for a IPv6 world it would be nice to > have an easily available testing suite for these basic mechanisms. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > From tglassey at earthlink.net Mon Mar 29 11:43:25 2010 From: tglassey at earthlink.net (todd glassey) Date: Mon, 29 Mar 2010 09:43:25 -0700 Subject: NTP clock source In-Reply-To: <98EECE82-8E77-471F-A6E3-EB54B3902241@iwiring.net> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> <98EECE82-8E77-471F-A6E3-EB54B3902241@iwiring.net> Message-ID: <4BB0D8AD.6040502@earthlink.net> On 3/25/2010 10:40 AM, Dan Shoop wrote: > > On Mar 25, 2010, at 8:51 AM, Kyle Bader wrote: > >> Can anyone recommend a solid clock source (stratum 0) that's not overly >> expensive? The only stuff I've found so far is ESE, can anyone >> recommend them or conversely has anyone had any problems with their >> hardware? Why would you want a S-0 Clock??? You are not a time-space lab, and so you would want something like a stratum-2 time source which comes from a provable provider. There are laws by the way on what are official and non-official sources of time. In the US for instance these are 15 USC 271 and 272, and the right to deploy the time is codified in 15 USC 260 so which source of time is used is important. By the way - if this is a commercial use, try applying the same set of controls to the time provider you are forced to apply to the rest of the outsourcing service providers you rely on... >> >> -- >> >> Kyle > > > We have several symmetricom time servers that we use in several location and I'd recommend them very highly. ' Depends on whether you are trying to generate evidence of something or not. If you need to be able to prove the time data is correct, then you will need a process to do that, a process which most all of the time server systems to date choke on pretty badly. Since the GPS-L1 system without SAASM encryption was formally banned by the US Military for use in their systems by an order of the Joint Chiefs of Staff in 1998, its pretty clear that relying on GPS-L1 for anything requiring a sense of digital trust is out. NTP Peer Stats files have virtually no way of associating content to events meaning that the time-tokens which are passed around are lost in the wind, meaning that there is no enduring evidence generated by NTP. The NTP loopstat and peerstat files have just enough info to be dangerous and not enough to prove anything to the existing rules of evidence, so the real issue is whether you have to prove something as a response to a regulatory requirements or you just want to synchronize the systems in question for... Todd > > -d > > ------------------------------------------------------------------------ > Dan Shoop > Computer Scientist > shoop at iwiring.net > > GoogleVoice: 1-646-402-5293 > > aim: iWiring > twitter: @colonelmode > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 125 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Mon Mar 29 12:00:53 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 29 Mar 2010 13:00:53 -0400 Subject: NTP clock source In-Reply-To: Your message of "Mon, 29 Mar 2010 09:43:25 PDT." <4BB0D8AD.6040502@earthlink.net> References: <854dca5c1003250551g324764b2yfb74781b6cb1e4fb@mail.gmail.com> <98EECE82-8E77-471F-A6E3-EB54B3902241@iwiring.net> <4BB0D8AD.6040502@earthlink.net> Message-ID: <12855.1269882053@localhost> On Mon, 29 Mar 2010 09:43:25 PDT, todd glassey said: > Why would you want a S-0 Clock??? You are not a time-space lab, and so > you would want something like a stratum-2 time source which comes from a > provable provider. There are laws by the way on what are official and > non-official sources of time. In the US for instance these are 15 USC > 271 and 272, and the right to deploy the time is codified in 15 USC 260 > so which source of time is used is important. Actually reading sections 260, 271, and 272 doesn't seem to actually talk much about it, and unless you really care in a legal sense if your time is derived from a WWVB signal or a GPS clock, it probably doesn't matter. OK, maybe if you're listening to the Canadian radio signal, or the European competitor to the GPS constellation it matters. Does anybody *really* care, given that all these sources are usually synced to each other well enough that it doesn't matter accuracy-wise? The reason he wants a stratum-zero clock source is because when he sets up his server that reads from that clock, it will in NTP-speak end up being a stratum-1 clock, which is what he wants to deploy, then when he distributes it to other servers, they'll become the stratum-2 clocks you mention. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tariq198487 at hotmail.com Mon Mar 29 14:06:08 2010 From: tariq198487 at hotmail.com (Tarig Yassin) Date: Mon, 29 Mar 2010 22:06:08 +0300 Subject: DNS TXT field usage ? In-Reply-To: <4BAF45D7.5000102@yahoo.fr> References: <4BAF45D7.5000102@yahoo.fr> Message-ID: Hi Jul Dkim , SPF ,and Domainkey are sender authentication methods for email system. Which use Public Key Cryptography. The mail server apends signiture to every outgoing message using private key. the recepient mail server to verify needs the public key which placed in the sender DNS server. see dig suin.edu.sd txt --> for SPF dig _domainkey.suin.edu.sd txt --> for DKIM regards, -- Tarig Y. Adam Chief Technology Officer Sudanese Universities' Information Network (SUIN) T: +249925659149 w: www.suin.edu.sd > Date: Sun, 28 Mar 2010 14:04:39 +0200 > From: jul_bsd at yahoo.fr > To: nanog at nanog.org > Subject: DNS TXT field usage ? > > Hello, > > While watching some parked domains, I recently observed one which has a > TXT field containing some crypto value, something like a ssh key/RSA 512 > or 1024 output (only the crypto part 'cvxvcvcxvcxv=' ). > > For now, I have referenced the following usage of TXT > - DNS Server information/version > - SPF (format like "v=spf1 a mx -all") [1] > - DKIM (format like "k=rsa\; t=y\; p=MIGfMA0GCSqGSIb3 [...] > YA+OwSMWQIDAQAB", but always in _domainkey.) [2] > - not DNSSec as I supposed first (only DNSKEY, RR, RSIG, NSEC, not TXT) > > Does someone know at what kind of usage this kind of value could > correspond ? (even if, nearly everything is possible) > > Maybe somebody knows of a webpage referencing common usage of DNS fields ? > I found http://www.iana.org/assignments/dns-parameters but it points > only on RFC not practical usage. > > > Thanks a lot. > Best regards, > > Jul > > > [1] http://en.wikipedia.org/wiki/Sender_Policy_Framework > [2] http://www.ietf.org/rfc/rfc4871.txt (7.4) > > Note: current RFC referencing TXT field is > http://www.ietf.org/rfc/rfc1035.txt > "TXT RRs are used to hold descriptive text." > _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. https://signup.live.com/signup.aspx?id=60969 From jtk at cymru.com Mon Mar 29 17:07:44 2010 From: jtk at cymru.com (John Kristoff) Date: Mon, 29 Mar 2010 17:07:44 -0500 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <20100326220922.GH12189@angus.ind.WPI.EDU> References: <20100326220922.GH12189@angus.ind.WPI.EDU> Message-ID: <20100329170744.004d1c94@t61p> On Fri, 26 Mar 2010 18:09:22 -0400 Chuck Anderson wrote: > Anyone have suggestions on Ethernet LAN loop-prevention? With the > advent of Auto MDI/MDI-X ports on switches, it seems way too easy to > accidentally or maliciously create loops between network jacks. We Some time ago I did some work on implementing what cisco called 'port security'. The idea was to add some layer 2 protection from a security perspective. It turns out in practice, at least in the environment I was in, they never happen. However, it did offer protection for loops since if a secured port saw a source address show up another another port, it would block it and generate logs, which we monitored and could then go deal with while the network remained up. There are some potential gotchas depending on how you implement port security so you need consider carefully how you implement it if you do it. Its been awhile since I've done anything in this space, but this better captures my experience since my memory of it is beginning to fade: John From dotis at mail-abuse.org Mon Mar 29 17:19:36 2010 From: dotis at mail-abuse.org (Douglas Otis) Date: Mon, 29 Mar 2010 15:19:36 -0700 Subject: DNS TXT field usage ? In-Reply-To: References: <4BAF45D7.5000102@yahoo.fr> Message-ID: <4BB12778.10505@mail-abuse.org> On 3/29/10 12:06 PM, Tarig Yassin wrote: > Hi Jul > > > Dkim, SPF, and Domainkey are sender authentication methods for email system. Which use Public Key Cryptography. > DKIM and Domainkeys use public key cryptography to authenticate signature sources used for signing at least email From headers and signature headers. However, SPF uses chained IP address lists to establish source authorization, but not authentication. Since outbound MTAs might handle multiple domains, it would be incorrect to assume authorization implies authentication and to expect email domains have been previously verified by the source. For example, Sender-ID might use the same SPF record, but this expects Purported Responsible Addresses (PRA) rather than Mail Froms have been verified. On the other hand, SPF was designed to ignore the PRA, and neither section 2.2 or 2.4 of RFC4408 imposes prior verification demands on Mail From or HELO, which would conflict with normal forwarding. :^( Both DKIM and Domainkey share the same domain label of "._domainkey.", whereas the first SPF record in a chain would be accessed without any prefix label. While bad actors could use either scheme to obscure encoded DNS tunnel traffic, ascertaining abnormal use would be especially difficult whenever the first SPF records in a chain includes local-part encoding for subsequent SPF record prefixes. :^( -Doug From dougb at dougbarton.us Mon Mar 29 18:17:28 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 29 Mar 2010 16:17:28 -0700 Subject: IP4 Space In-Reply-To: <201003261725.30279.lowen@pari.edu> References: <201003261725.30279.lowen@pari.edu> Message-ID: <4BB13508.3010701@dougbarton.us> On 03/26/10 14:25, Lamar Owen wrote: > While my hypothetical answer was intentionally worst-case, with just-barely- > too-old hypothetical hardware being mentioned, in reality my situation is > dealing with in some cases much older equipment. I could go into detail, but > you guys don't want to read my pity party, I'm sure. I understand what you're saying, and I "get" the issue of not being able to upgrade legacy equipment in the current economic client. However, none of that is relevant to the fact that a change IS coming, whether you're ready for it or not. The questions are, what will the change(s) be, how soon, and how will it/they affect me? If your network doesn't change much at all chances are you may never need to request more IPv4 space, so the coming events won't affect you at all, keep doing what you're doing. If your network does have a "moderate" need for more IPv4 space in the future you may be able to get away with shuffling some things around, being more stringent about putting internal-only resources on RFC 1918 space, etc. Costs here are minimal, but as you pointed out "time is money" so they are not free. However, overall impact is negligible. However, if your network is growing, or can be anticipated to grow in the next 5 years, here is where the pain starts. You may not be able to get IPv4 space when you need it, so the only options available to you are some form of NAT, or IPv6. Neither cost is trivial in terms of equipment and deployment time. Both have tradeoffs. So the question is not, "Can I afford to make a change?" The questions are as above, what, and how soon? This is why "we" have been telling people for years to work IPv6 requirements into all NEW stuff (networking hardware, end-user systems, b/w contracts) so that WHEN the changes start to affect you you won't have to do a forklift upgrade. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From oberman at es.net Mon Mar 29 23:59:56 2010 From: oberman at es.net (Kevin Oberman) Date: Mon, 29 Mar 2010 21:59:56 -0700 Subject: IPv4 ANYCAST setup In-Reply-To: Your message of "Fri, 26 Mar 2010 10:06:02 PDT." <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> Message-ID: <20100330045956.EB00B1CC31@ptavv.es.net> > From: Joe Abley > Date: Fri, 26 Mar 2010 10:06:02 -0700 > > On 2010-03-26, at 06:40, Max Larson Henry wrote: > > >>> has someone experience in anycast ipv4 networks (to support DNS)? > >> > >> "Never been done" "Dangerous" "TCP does not work" etc etc etc. > > > > - Yes but as for DNS, anycast is essentially used for user requests (UDP) > > not to perform zone transfer(TCP). > > As others have mentioned, TCP can generally be used for any DNS query, not just AXFR. > > This becomes more important as DNS responses get bigger, e.g. responses from root servers due to the root zone containing DNSSEC information, see . > > If your nameserver can't be reached over TCP, it's likely that there are people who can't talk to your nameserver. This means your DNS records can't be found. This is a bad thing. > > Here, in glorious LOLCAPS: > > ALWAYS MAKE SURE YOUR DNS SERVER CAN BE REACHED OVER TCP > TCP IS NOT JUST FOR ZONE TRANSFERS > FIX YOUR FIREWALLS > > :-) Fix your security officers! I have talked to multiple security officers (who are generally not really knowledgeable on networks) who had 53/tcp blocked and none have yet agreed to change it. The last one told me that blocking 53/tcp is "standard industry practice" as per his firewall training. Point out what RFCs said simply bounced off of him. He said that if the protocols would not handle blocked 53/tcp, the protocols would have to be changed. Opening the port was simply not open to discussion. They don't seen to really care if things are broken and seem to feel that it is up to "the network" to accommodate their idea of normal firewall configuration. I will say that these were at federal government facilities. I hope the commercial world is a bit more in touch with reality. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From oberman at es.net Tue Mar 30 00:14:29 2010 From: oberman at es.net (Kevin Oberman) Date: Mon, 29 Mar 2010 22:14:29 -0700 Subject: "Is TDM going the way of dial-up?" In-Reply-To: Your message of "Fri, 26 Mar 2010 16:43:23 GMT." <1003261643.AA01673@ivan.Harhan.ORG> Message-ID: <20100330051429.E44F41CC31@ptavv.es.net> > Date: Fri, 26 Mar 2010 16:43:23 GMT > From: msokolov at ivan.Harhan.ORG (Michael Sokolov) > > Rick Ernst wrote: > > > I've noticed over the last 3 years or so that TDM, specifically T-1, access > > and transport has been in a steady decline. Customers are moving to FTTH > > and cable, or going WiMAX and Metro-Ethernet. Ethernet seems to have taken > > an even bigger bite out of DS-3. The bigger pipes seem to favor ethernet. A > > recent upgrade from OC-3 to GigE transport actually saved us a large chunk > > of money. > > > > I'm wondering if others are seeing the same behavior, if it's > > market-dependant, or if I'm just imagining things. > > Unfortunately what you are seeing is indeed where the world is going, > and it is extremely painful to watch. My personal preference is the > direct opposite of that: Ethernet for non-LAN use is my very antithesis, > I hate it to the core of my being. V.35/HDLC forever for me! I will > continue using HDLC over traditional synchronous serial WAN media for as > long as I am alive. > > MS > > P.S. This message is being sent from a VAX running a variant of 4.3BSD > (Quasijarus). Almost the entire ARPA Internet software stack that's > running on my VAXen is mostly unchanged from how it was in 1988. Much as I love Sonet and the like, I will channel Randy and say that I hope all of my competitors do this. (OK. We really don't have competitors.) And, if you are using a 1988 TCP stack on a 4.3 system, you are not likely to ever efficiently utilize a higher speed link and will not behave well on any link. TCP has come a long way in the past 12 years. (Of course, I can't guess what "mostly unchanged" means.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From msokolov at ivan.Harhan.ORG Tue Mar 30 00:28:40 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Tue, 30 Mar 2010 05:28:40 GMT Subject: "Is TDM going the way of dial-up?" Message-ID: <1003300528.AA08926@ivan.Harhan.ORG> Kevin Oberman wrote: > And, if you are using a 1988 TCP stack on a 4.3 system, you are not > likely to ever efficiently utilize a higher speed link What higher speed link? I'm very happy with 384 kbps symmetric, using SDSL as ARPANET replacement. I have designed and built my own SDSL to EIA-530 CSU/DSU so I can use a Cisco 2500 router instead of that nasty new-fangled Netopia which has (oh horror!) RJ45 Ethernet instead of proper AUI. Oh, did I forget to mention that my Ethernet is coaxial? To me all that UTP stuff isn't true Ethernet. > and will not > behave well on any link. TCP has come a long way in the past 12 > years. (Of course, I can't guess what "mostly unchanged" means.) Backward compatibility rules! MS From lou at metron.com Tue Mar 30 01:17:25 2010 From: lou at metron.com (Lou Katz) Date: Mon, 29 Mar 2010 23:17:25 -0700 Subject: 192.0.0.0/24 Message-ID: <20100330061725.GA81284@metron.com> We recently were told to contact a client (via ftp) at 192.0.0.201. IANA lists this as Special Use, but refers to "RFC 3330 for additional information. http://www.rfc-editor.org/rfc/rfc3330.txt". This RFC says that it might be assigned in the future. So, did the folks who sent us the IP address fat-finger, or has this been assigned? There does not appear to be any route to it. -- -=[L]=- `is not a sentence' is not a sentence. From fergdawgster at gmail.com Tue Mar 30 01:28:21 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 29 Mar 2010 23:28:21 -0700 Subject: 192.0.0.0/24 In-Reply-To: <20100330061725.GA81284@metron.com> References: <20100330061725.GA81284@metron.com> Message-ID: <6cd462c01003292328n2c5d7c82sdaaf3d12a9f2a10e@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Mar 29, 2010 at 11:17 PM, Lou Katz wrote: > > We recently were told to contact a client (via ftp) at 192.0.0.201. IANA > lists this as Special Use, but refers to "RFC 3330 for additional > information. http://www.rfc-editor.org/rfc/rfc3330.txt". This RFC says > that it might be assigned in the future. > > So, did the folks who sent us the IP address fat-finger, or has this been > assigned? There does not appear to be any route to it. That's because there isn't: route-views2.routeviews.org> sho ip bgp 192.0.0.201 BGP routing table entry for 0.0.0.0/0 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 11686 19151 96.4.0.55 from 96.4.0.55 (96.4.0.55) Origin IGP, localpref 100, valid, external, best Last update: Sun Dec 27 02:46:56 1970 - -ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLsZn8q1pz9mNUZTMRAmRdAKDNEdRM+DqS2SPG2t0QdZVsqyUMdwCg7bva 9dRverAlWwIVO7AH1smGEZg= =QjV0 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From netfortius at gmail.com Tue Mar 30 01:47:43 2010 From: netfortius at gmail.com (Stefan) Date: Tue, 30 Mar 2010 01:47:43 -0500 Subject: "Is TDM going the way of dial-up?" In-Reply-To: <4BACD644.5040803@bogus.com> References: <4BACD644.5040803@bogus.com> Message-ID: On Fri, Mar 26, 2010 at 10:44 AM, joel jaeggli wrote: > On 3/26/2010 8:15 AM, Rick Ernst wrote: >> >> I've noticed over the last 3 years or so that TDM, specifically T-1, >> access >> and transport has been in a steady decline. ?Customers are moving to FTTH >> and cable, or going WiMAX and Metro-Ethernet. ?Ethernet seems to have >> taken >> an even bigger bite out of DS-3. ?The bigger pipes seem to favor ethernet. >> A >> recent upgrade from OC-3 to GigE transport actually saved us a large chunk >> of money. >> >> I'm wondering if others are seeing the same behavior, if it's >> market-dependant, or if I'm just imagining things. ?I'm working on >> building >> new infrastructure and my current thoughts are to minimize my TDM >> footprint. ?It would be useful to get a better feel if this is an overall >> trend or something local. >> > > Why I think it comes down to is do you want to use frame-relay, atm, sdh and > ethernet when you can just use ethernet? > > lan-phy ethernet has economies of scale that result in lower cost along > virtually every dimension relative to the alternatives. > >> Thoughts? >> >> Thanks, >> >> Diversity, in case of locations meant to be used as each other's backup/failover ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From randy at psg.com Tue Mar 30 01:59:08 2010 From: randy at psg.com (Randy Bush) Date: Tue, 30 Mar 2010 15:59:08 +0900 Subject: IPv4 ANYCAST setup In-Reply-To: <20100330045956.EB00B1CC31@ptavv.es.net> References: <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> <20100330045956.EB00B1CC31@ptavv.es.net> Message-ID: > I have talked to multiple security officers (who are generally not > really knowledgeable on networks) who had 53/tcp blocked and none have > yet agreed to change it. patience. when things really start to break, and the finger of fate points at them, clue may arise. randy From dot at dotat.at Tue Mar 30 02:57:10 2010 From: dot at dotat.at (Tony Finch) Date: Tue, 30 Mar 2010 08:57:10 +0100 Subject: IPv4 ANYCAST setup In-Reply-To: References: <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> <20100330045956.EB00B1CC31@ptavv.es.net> Message-ID: <7F282E43-B67C-4119-9D85-BF40C1C7BE1E@dotat.at> On 30 Mar 2010, at 07:59, Randy Bush wrote: >> I have talked to multiple security officers (who are generally not >> really knowledgeable on networks) who had 53/tcp blocked and none >> have yet agreed to change it. > > patience. when things really start to break, and the finger of fate > points at them, clue may arise. 36 days until all root servers have DNSSEC data, at which point large replies become normal. Tony (on his iPod). -- f.anthony.n.finch http://dotat.at/ From randy at psg.com Tue Mar 30 03:43:25 2010 From: randy at psg.com (Randy Bush) Date: Tue, 30 Mar 2010 17:43:25 +0900 Subject: IPv4 ANYCAST setup In-Reply-To: <7F282E43-B67C-4119-9D85-BF40C1C7BE1E@dotat.at> References: <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> <20100330045956.EB00B1CC31@ptavv.es.net> <7F282E43-B67C-4119-9D85-BF40C1C7BE1E@dotat.at> Message-ID: >>> I have talked to multiple security officers (who are generally not >>> really knowledgeable on networks) who had 53/tcp blocked and none >>> have yet agreed to change it. >> patience. when things really start to break, and the finger of fate >> points at them, clue may arise. > 36 days until all root servers have DNSSEC data, at which point large > replies become normal. are end user tools, i.e. a web click a button, available so they can test if they are behind a clueless security id10t? is there good simple end user docco they are somewhat likely to find when things break for them? i.e. what can we do to maximize the odds that the victim will quickly find the perp, as opposed to calling our our tech support lines? randy From Valdis.Kletnieks at vt.edu Tue Mar 30 03:53:58 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 30 Mar 2010 04:53:58 -0400 Subject: IPv4 ANYCAST setup In-Reply-To: Your message of "Tue, 30 Mar 2010 15:59:08 +0900." References: <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> <20100330045956.EB00B1CC31@ptavv.es.net> Message-ID: <27565.1269939238@localhost> On Tue, 30 Mar 2010 15:59:08 +0900, Randy Bush said: > > I have talked to multiple security officers (who are generally not > > really knowledgeable on networks) who had 53/tcp blocked and none have > > yet agreed to change it. > > patience. when things really start to break, and the finger of fate > points at them, clue may arise. How many years did it take for firewalls to quit screwing with the ECN bits? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Tue Mar 30 03:55:06 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 30 Mar 2010 04:55:06 -0400 Subject: "Is TDM going the way of dial-up?" In-Reply-To: Your message of "Tue, 30 Mar 2010 05:28:40 -0000." <1003300528.AA08926@ivan.Harhan.ORG> References: <1003300528.AA08926@ivan.Harhan.ORG> Message-ID: <27591.1269939306@localhost> On Tue, 30 Mar 2010 05:28:40 -0000, Michael Sokolov said: > Kevin Oberman wrote: > > > And, if you are using a 1988 TCP stack on a 4.3 system, you are not > > likely to ever efficiently utilize a higher speed link > > What higher speed link? I'm very happy with 384 kbps symmetric, using > SDSL as ARPANET replacement. I have designed and built my own SDSL to > EIA-530 CSU/DSU so I can use a Cisco 2500 router instead of that nasty > new-fangled Netopia which has (oh horror!) RJ45 Ethernet instead of > proper AUI. Oh, did I forget to mention that my Ethernet is coaxial? > To me all that UTP stuff isn't true Ethernet. I call Poe's Law on this one. Mostly because I can't tell which side this one is on. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From regnauld at nsrc.org Tue Mar 30 04:24:20 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 30 Mar 2010 11:24:20 +0200 Subject: IPv4 ANYCAST setup In-Reply-To: References: <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> <20100330045956.EB00B1CC31@ptavv.es.net> Message-ID: <20100330092419.GB24147@macbook.catpipe.net> Randy Bush (randy) writes: > patience. when things really start to break, and the finger of fate > points at them, clue may arise. > When this issue was brought up on the OARC dns-operations list, and it was suggested to make some simply factsheets (a bit like ICANN's IPv6 http://www.icann.org/announcements/factsheet-ipv6-26oct07.pdf), this was poo-pooed as being useless and a waste of time. Since the final victim is the end user, I still think it's worth the effort to try and make security officers and similar network operators aware of the issues and what they can do to mitigate potential problems. See for example: http://www.afnic.fr/actu/nouvelles/240/l-afnic-invite-les-responsables-techniques-reseaux-a-se-preparer-a-la-signature-de-la-racine-dns-en-mai-2010 (Yes, there's an English version too). Cheers, Phil From regnauld at nsrc.org Tue Mar 30 04:29:04 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 30 Mar 2010 11:29:04 +0200 Subject: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) In-Reply-To: References: <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> <20100330045956.EB00B1CC31@ptavv.es.net> <7F282E43-B67C-4119-9D85-BF40C1C7BE1E@dotat.at> Message-ID: <20100330092858.GC24147@macbook.catpipe.net> Randy Bush (randy) writes: > > i.e. what can we do to maximize the odds that the victim will quickly > find the perp, as opposed to calling our our tech support lines? Ah yes, there was the second good reason for actually helping netops and security officers :) Tools: https://www.dns-oarc.net/oarc/services/replysizetest https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources, under troubleshooting: http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues http://secspider.cs.ucla.edu/ Info sheets: http://www.afnic.fr/actu/nouvelles/240/l-afnic-invite-les-responsables-techniques-reseaux-a-se-preparer-a-la-signature-de-la-racine-dns-en-mai-2010 (click English, top right) ... plenty of links there too. Cheers, Phil From jim at reptiles.org Tue Mar 30 04:34:06 2010 From: jim at reptiles.org (Jim Mercer) Date: Tue, 30 Mar 2010 05:34:06 -0400 Subject: Useful URL for network operators In-Reply-To: References: Message-ID: <20100330093406.GA74607@reptiles.org> On Sat, Mar 27, 2010 at 11:36:52AM -0700, Randy Bush wrote: > could you please keep a constant email address so we don't have to keep > adding to our mail filters? thanks. he is invading other lists as well, looks like he is trying to become a net.kook. -- Date: Tue, 30 Mar 2010 08:10:32 +0200 From: Guillaume FORTAINE To: menog at menog.net Subject: Re: [menog] Useful URL for network operators Dear all, Once again, please ignore Jim Mercer. He should do more homeworks too. a) I have never heard of Randy Bush b) I didn't coin the term "EDoS" : ... c) I have never heard of him Really, I am a bit tired from quick and poor replies from NANOGers. Simply mediocre engineers. Best Regards, Guillaume FORTAINE -- -- Jim Mercer jim at reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From robert at ripe.net Tue Mar 30 04:37:49 2010 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 30 Mar 2010 11:37:49 +0200 Subject: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) In-Reply-To: <20100330092858.GC24147@macbook.catpipe.net> References: <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> <20100330045956.EB00B1CC31@ptavv.es.net> <7F282E43-B67C-4119-9D85-BF40C1C7BE1E@dotat.at> <20100330092858.GC24147@macbook.catpipe.net> Message-ID: <4BB1C66D.7000808@ripe.net> I must observe that these are not really the links you'd want to give your end users to check out. Their audience is very different. While the article on RIPE Labs comes close, they don't really answer the "does it work or does it not?" question with a green/red light, and they don't provide a good explanation to the audience Randy is referring to. Robert On 2010.03.30. 11:29, Phil Regnauld wrote: > Randy Bush (randy) writes: >> >> i.e. what can we do to maximize the odds that the victim will quickly >> find the perp, as opposed to calling our our tech support lines? > > Ah yes, there was the second good reason for actually helping netops > and security officers :) > > Tools: > > https://www.dns-oarc.net/oarc/services/replysizetest > > https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources, > under troubleshooting: > http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues > http://secspider.cs.ucla.edu/ > > Info sheets: > > http://www.afnic.fr/actu/nouvelles/240/l-afnic-invite-les-responsables-techniques-reseaux-a-se-preparer-a-la-signature-de-la-racine-dns-en-mai-2010 > (click English, top right) > > ... plenty of links there too. > > Cheers, > Phil > From regnauld at nsrc.org Tue Mar 30 04:52:27 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 30 Mar 2010 11:52:27 +0200 Subject: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) In-Reply-To: <4BB1C66D.7000808@ripe.net> References: <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> <20100330045956.EB00B1CC31@ptavv.es.net> <7F282E43-B67C-4119-9D85-BF40C1C7BE1E@dotat.at> <20100330092858.GC24147@macbook.catpipe.net> <4BB1C66D.7000808@ripe.net> Message-ID: <20100330095226.GE24147@macbook.catpipe.net> Robert Kisteleki (robert) writes: > I must observe that these are not really the links you'd want to > give your end users to check out. Their audience is very different. > While the article on RIPE Labs comes close, they don't really answer > the "does it work or does it not?" question with a green/red light, > and they don't provide a good explanation to the audience Randy is > referring to. Fair enough. Some simple "check your DNS reply size test [what is this ?]" page ought to be set up, with a simple explanagtion. "checkmydns.org" is available. If I get 5 minutes... :) From lists at quux.de Tue Mar 30 04:58:16 2010 From: lists at quux.de (Jens Link) Date: Tue, 30 Mar 2010 11:58:16 +0200 Subject: IPv4 ANYCAST setup In-Reply-To: <20100330045956.EB00B1CC31@ptavv.es.net> (Kevin Oberman's message of "Mon\, 29 Mar 2010 21\:59\:56 -0700") References: <20100330045956.EB00B1CC31@ptavv.es.net> Message-ID: <87mxxqb07b.fsf@bowmore.quux.de> "Kevin Oberman" writes: > He said that if the protocols would not handle blocked 53/tcp, the > protocols would have to be changed. Opening the port was simply not > open to discussion. Let me guess: They also completely blocked ICMP. I always tell these customers to switch to IPv6 real fast and to turn of ICMPv6 to make their networks really secure. ;-) > I will say that these were at federal government facilities. I hope the > commercial world is a bit more in touch with reality. You can find clueless people everywhere. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- From bmanning at vacation.karoshi.com Tue Mar 30 05:05:27 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 30 Mar 2010 10:05:27 +0000 Subject: IPv4 ANYCAST setup In-Reply-To: References: <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> <20100330045956.EB00B1CC31@ptavv.es.net> <7F282E43-B67C-4119-9D85-BF40C1C7BE1E@dotat.at> Message-ID: <20100330100527.GC30288@vacation.karoshi.com.> On Tue, Mar 30, 2010 at 05:43:25PM +0900, Randy Bush wrote: > >>> I have talked to multiple security officers (who are generally not > >>> really knowledgeable on networks) who had 53/tcp blocked and none > >>> have yet agreed to change it. > >> patience. when things really start to break, and the finger of fate > >> points at them, clue may arise. > > 36 days until all root servers have DNSSEC data, at which point large > > replies become normal. > > are end user tools, i.e. a web click a button, available so they can > test if they are behind a clueless security id10t? no - in part because using a browser to debug DNS involves a third app (and likly a third/forth) platform. the nifty OARC testpoint is nearly worthless for real operations, since its not located at/near a DNS authoritative source. the K testpoint is good, I should prolly put back the one off B. > is there good simple end user docco they are somewhat likely to find > when things break for them? not yet. in part because out of the few simple parts, many, many combinations of failure can occur. ) MTU strictures: v6/v4 tunneling v6/v4 MTU clamping ) Fragmenation UDP ) Port blocking ) Resolver Behaviour EDNS awareness > i.e. what can we do to maximize the odds that the victim will quickly > find the perp, as opposed to calling our our tech support lines? thats a tough call. as tech support staff, we are almost always an outside observer on the path btwn the victim and the perp. troubleshooting is going to be problematic. > > randy From dot at dotat.at Tue Mar 30 05:53:12 2010 From: dot at dotat.at (Tony Finch) Date: Tue, 30 Mar 2010 11:53:12 +0100 Subject: IPv4 ANYCAST setup In-Reply-To: <87mxxqb07b.fsf@bowmore.quux.de> References: <20100330045956.EB00B1CC31@ptavv.es.net> <87mxxqb07b.fsf@bowmore.quux.de> Message-ID: "Kevin Oberman" writes: > He said that if the protocols would not handle blocked 53/tcp, the > protocols would have to be changed. Opening the port was simply not > open to discussion. Do they also believe that all DNS replies are less than 512 bytes? :-) Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From Valdis.Kletnieks at vt.edu Tue Mar 30 06:33:39 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 30 Mar 2010 07:33:39 -0400 Subject: Useful URL for network operators In-Reply-To: Your message of "Tue, 30 Mar 2010 05:34:06 EDT." <20100330093406.GA74607@reptiles.org> References: <20100330093406.GA74607@reptiles.org> Message-ID: <1191.1269948819@localhost> On Tue, 30 Mar 2010 05:34:06 EDT, Jim Mercer said: > Once again, please ignore Jim Mercer. > He should do more homeworks too. He's said similar about a number of people who have more operations clue than he does. I'd comment, except Woody Allen already did it better: http://www.youtube.com/watch?v=9wWUc8BZgWE > a) I have never heard of Randy Bush That's OK, I encoura.. oh nevermind, it's shooting fish in a barrel. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wmullaney at annese.com Tue Mar 30 06:36:04 2010 From: wmullaney at annese.com (William Mullaney) Date: Tue, 30 Mar 2010 07:36:04 -0400 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: <20100326220922.GH12189@angus.ind.WPI.EDU> References: <20100326220922.GH12189@angus.ind.WPI.EDU> Message-ID: We had a school district that had a large number of "dumb" switches in each class room hanging off real ones. These would get looped when a student or staff member plugged a patch cable into two ports on the end switch, taking down large portions of the network. It seems Cisco 3500's ignore a BPDU that comes in the same port it comes out. We switched them to 3750's as part of other upgrades, which eliminated the BPDU problem (3560's and 3550's also work correctly), RSTP, enabled port fast, root guard, loop back detection, and storm control. Then set the switches to automatically come back in service from err-disable after 60 seconds or so. In every single test we did (looping off a dumb switch, looping two ports on the 3750, looping between two 3750 in different stacks), there was immediate blocking occurring that prevented any non-sense from effecting the network. Of course the little switches get taken out along with anything connected, but that's really just an indicator of the need for more drops from real switches. Additionally, turning on only one of the features at a time still shut down the port within a second or so. I don't really like BPDUGuard when rootguard is available, as I think other devices should be able to participate in STP so long as they aren't trying to reconverge the network by grabbing root or becoming a transit between two building switches. As for RSTP, it's on for every switch we deploy unless there is some compelling reason not to do so. I have yet to find another switch that will not work even if it only supports "old" STP. -WT -----Original Message----- From: Chuck Anderson [mailto:cra at WPI.EDU] Sent: Friday, March 26, 2010 6:09 PM To: nanog at nanog.org Subject: Auto MDI/MDI-X + conference rooms + bored == loop Anyone have suggestions on Ethernet LAN loop-prevention? With the advent of Auto MDI/MDI-X ports on switches, it seems way too easy to accidentally or maliciously create loops between network jacks. We have bored or inattentive people plugging in patch cords between adjacent network jacks. STP for loop-prevention isn't working so well for us. STP "edge" or "portfast" or "faststart" modes are required for end-station ports (with normal STP, DHCP often times out after 30+ seconds it takes to go into Forwarding state). Since the "edge" STP mode goes into Forwarding state immediately, there is a period when loops will form, causing havok with upstream gear until STP blocks the port (if it ever does see below). "Desktop" switches. You know, those 4 or 5 port Gigabit Ethernet switches. Apparently, many of them don't do any kind of STP at all. Recommendations on ones that do STP? RSTP: is it any better than traditional STP in regards to "edge" ports and blocking before a loop gets out of hand? Or perhaps blocking for 5-10 seconds before going into Forwarding state, hopefully preventing loops before they happen but also allowing DHCP clients to get an address without timeouts? Recommendations on "Desktop" switches that do RSTP? Thanks for your suggestions/discussion. -- - Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/) From stephen.tandy at trigenis.com Tue Mar 30 07:58:44 2010 From: stephen.tandy at trigenis.com (Stephen Tandy) Date: Tue, 30 Mar 2010 13:58:44 +0100 Subject: NANOG Digest, Vol 26, Issue 142 Message-ID: Sent from my Windows? phone. -----Original Message----- From: nanog-request at nanog.org Sent: 30 March 2010 13:00 To: nanog at nanog.org Subject: NANOG Digest, Vol 26, Issue 142 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) (Robert Kisteleki) 2. Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) (Phil Regnauld) 3. Re: IPv4 ANYCAST setup (Jens Link) 4. Re: IPv4 ANYCAST setup (bmanning at vacation.karoshi.com) 5. Re: IPv4 ANYCAST setup (Tony Finch) 6. Re: Useful URL for network operators (Valdis.Kletnieks at vt.edu) 7. RE: Auto MDI/MDI-X + conference rooms + bored == loop (William Mullaney) ---------------------------------------------------------------------- Message: 1 Date: Tue, 30 Mar 2010 11:37:49 +0200 From: Robert Kisteleki Subject: Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) To: nanog at nanog.org Message-ID: <4BB1C66D.7000808 at ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I must observe that these are not really the links you'd want to give your end users to check out. Their audience is very different. While the article on RIPE Labs comes close, they don't really answer the "does it work or does it not?" question with a green/red light, and they don't provide a good explanation to the audience Randy is referring to. Robert On 2010.03.30. 11:29, Phil Regnauld wrote: > Randy Bush (randy) writes: >> >> i.e. what can we do to maximize the odds that the victim will quickly >> find the perp, as opposed to calling our our tech support lines? > > Ah yes, there was the second good reason for actually helping netops > and security officers :) > > Tools: > > https://www.dns-oarc.net/oarc/services/replysizetest > > https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources, > under troubleshooting: > http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues > http://secspider.cs.ucla.edu/ > > Info sheets: > > http://www.afnic.fr/actu/nouvelles/240/l-afnic-invite-les-responsables-techniques-reseaux-a-se-preparer-a-la-signature-de-la-racine-dns-en-mai-2010 > (click English, top right) > > ... plenty of links there too. > > Cheers, > Phil > ------------------------------ Message: 2 Date: Tue, 30 Mar 2010 11:52:27 +0200 From: Phil Regnauld Subject: Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) To: Robert Kisteleki Cc: nanog at nanog.org Message-ID: <20100330095226.GE24147 at macbook.catpipe.net> Content-Type: text/plain; charset=us-ascii Robert Kisteleki (robert) writes: > I must observe that these are not really the links you'd want to > give your end users to check out. Their audience is very different. > While the article on RIPE Labs comes close, they don't really answer > the "does it work or does it not?" question with a green/red light, > and they don't provide a good explanation to the audience Randy is > referring to. Fair enough. Some simple "check your DNS reply size test [what is this ?]" page ought to be set up, with a simple explanagtion. "checkmydns.org" is available. If I get 5 minutes... :) ------------------------------ Message: 3 Date: Tue, 30 Mar 2010 11:58:16 +0200 From: Jens Link Subject: Re: IPv4 ANYCAST setup To: nanog at nanog.org Message-ID: <87mxxqb07b.fsf at bowmore.quux.de> Content-Type: text/plain; charset=us-ascii "Kevin Oberman" writes: > He said that if the protocols would not handle blocked 53/tcp, the > protocols would have to be changed. Opening the port was simply not > open to discussion. Let me guess: They also completely blocked ICMP. I always tell these customers to switch to IPv6 real fast and to turn of ICMPv6 to make their networks really secure. ;-) > I will say that these were at federal government facilities. I hope the > commercial world is a bit more in touch with reality. You can find clueless people everywhere. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- ------------------------------ Message: 4 Date: Tue, 30 Mar 2010 10:05:27 +0000 From: bmanning at vacation.karoshi.com Subject: Re: IPv4 ANYCAST setup To: Randy Bush Cc: "nanog at nanog.org" Message-ID: <20100330100527.GC30288 at vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii On Tue, Mar 30, 2010 at 05:43:25PM +0900, Randy Bush wrote: > >>> I have talked to multiple security officers (who are generally not > >>> really knowledgeable on networks) who had 53/tcp blocked and none > >>> have yet agreed to change it. > >> patience. when things really start to break, and the finger of fate > >> points at them, clue may arise. > > 36 days until all root servers have DNSSEC data, at which point large > > replies become normal. > > are end user tools, i.e. a web click a button, available so they can > test if they are behind a clueless security id10t? no - in part because using a browser to debug DNS involves a third app (and likly a third/forth) platform. the nifty OARC testpoint is nearly worthless for real operations, since its not located at/near a DNS authoritative source. the K testpoint is good, I should prolly put back the one off B. > is there good simple end user docco they are somewhat likely to find > when things break for them? not yet. in part because out of the few simple parts, many, many combinations of failure can occur. ) MTU strictures: v6/v4 tunneling v6/v4 MTU clamping ) Fragmenation UDP ) Port blocking ) Resolver Behaviour EDNS awareness > i.e. what can we do to maximize the odds that the victim will quickly > find the perp, as opposed to calling our our tech support lines? thats a tough call. as tech support staff, we are almost always an outside observer on the path btwn the victim and the perp. troubleshooting is going to be problematic. > > randy ------------------------------ Message: 5 Date: Tue, 30 Mar 2010 11:53:12 +0100 From: Tony Finch Subject: Re: IPv4 ANYCAST setup To: nanog at nanog.org Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII "Kevin Oberman" writes: > He said that if the protocols would not handle blocked 53/tcp, the > protocols would have to be changed. Opening the port was simply not > open to discussion. Do they also believe that all DNS replies are less than 512 bytes? :-) Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ------------------------------ Message: 6 Date: Tue, 30 Mar 2010 07:33:39 -0400 From: Valdis.Kletnieks at vt.edu Subject: Re: Useful URL for network operators To: Jim Mercer Cc: nanog at nanog.org Message-ID: <1191.1269948819 at localhost> Content-Type: text/plain; charset="us-ascii" On Tue, 30 Mar 2010 05:34:06 EDT, Jim Mercer said: > Once again, please ignore Jim Mercer. > He should do more homeworks too. He's said similar about a number of people who have more operations clue than he does. I'd comment, except Woody Allen already did it better: http://www.youtube.com/watch?v=9wWUc8BZgWE > a) I have never heard of Randy Bush That's OK, I encoura.. oh nevermind, it's shooting fish in a barrel. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available Url : http://mailman.nanog.org/mailman/nanog/attachments/20100330/dfea2bda/attachment-0001.pgp ------------------------------ Message: 7 Date: Tue, 30 Mar 2010 07:36:04 -0400 From: "William Mullaney" Subject: RE: Auto MDI/MDI-X + conference rooms + bored == loop To: "Chuck Anderson" , Message-ID: Content-Type: text/plain; charset="us-ascii" We had a school district that had a large number of "dumb" switches in each class room hanging off real ones. These would get looped when a student or staff member plugged a patch cable into two ports on the end switch, taking down large portions of the network. It seems Cisco 3500's ignore a BPDU that comes in the same port it comes out. We switched them to 3750's as part of other upgrades, which eliminated the BPDU problem (3560's and 3550's also work correctly), RSTP, enabled port fast, root guard, loop back detection, and storm control. Then set the switches to automatically come back in service from err-disable after 60 seconds or so. In every single test we did (looping off a dumb switch, looping two ports on the 3750, looping between two 3750 in different stacks), there was immediate blocking occurring that prevented any non-sense from effecting the network. Of course the little switches get taken out along with anything connected, but that's really just an indicator of the need for more drops from real switches. Additionally, turning on only one of the features at a time still shut down the port within a second or so. I don't really like BPDUGuard when rootguard is available, as I think other devices should be able to participate in STP so long as they aren't trying to reconverge the network by grabbing root or becoming a transit between two building switches. As for RSTP, it's on for every switch we deploy unless there is some compelling reason not to do so. I have yet to find another switch that will not work even if it only supports "old" STP. -WT -----Original Message----- From: Chuck Anderson [mailto:cra at WPI.EDU] Sent: Friday, March 26, 2010 6:09 PM To: nanog at nanog.org Subject: Auto MDI/MDI-X + conference rooms + bored == loop Anyone have suggestions on Ethernet LAN loop-prevention? With the advent of Auto MDI/MDI-X ports on switches, it seems way too easy to accidentally or maliciously create loops between network jacks. We have bored or inattentive people plugging in patch cords between adjacent network jacks. STP for loop-prevention isn't working so well for us. STP "edge" or "portfast" or "faststart" modes are required for end-station ports (with normal STP, DHCP often times out after 30+ seconds it takes to go into Forwarding state). Since the "edge" STP mode goes into Forwarding state immediately, there is a period when loops will form, causing havok with upstream gear until STP blocks the port (if it ever does see below). "Desktop" switches. You know, those 4 or 5 port Gigabit Ethernet switches. Apparently, many of them don't do any kind of STP at all. Recommendations on ones that do STP? RSTP: is it any better than traditional STP in regards to "edge" ports and blocking before a loop gets out of hand? Or perhaps blocking for 5-10 seconds before going into Forwarding state, hopefully preventing loops before they happen but also allowing DHCP clients to get an address without timeouts? Recommendations on "Desktop" switches that do RSTP? Thanks for your suggestions/discussion. -- - Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/) ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 26, Issue 142 ************************************** From karnaugh at karnaugh.za.net Tue Mar 30 08:03:48 2010 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Tue, 30 Mar 2010 15:03:48 +0200 Subject: FTC / Nexband Message-ID: <78bfcf051003300603u10d0a4f9r1b094280c4bd32a2@mail.gmail.com> Hi Wondering if anyone has some contact with FTC or Nexband or whoever. I can't find Someone without clue has decided it's a good idea to make almost all of 66.211.112.0/20 share the same PTR record. This has bad consequences, and is beginning to irritate me. [coffee ~]$ host 66.211.118.239 239.118.211.66.in-addr.arpa domain name pointer adsl.fultontelephone.net. [coffee ~]$ host 66.211.118.221 221.118.211.66.in-addr.arpa domain name pointer adsl.fultontelephone.net. [coffee ~]$ host adsl.fultontelephone.net | wc -l 4044 In the real world, the result is more like: [coffee ~]$ dig +short adsl.fultontelephone.net A ;; Truncated, retrying in TCP mode. dig: dns_rdata_totext: ran out of space So yeah... if someone wants to correct that, it would be great. And if everyone else in the world can please not EVER do something like this, that would also be good. From doon.bulk at inoc.net Tue Mar 30 08:05:08 2010 From: doon.bulk at inoc.net (Patrick Muldoon) Date: Tue, 30 Mar 2010 09:05:08 -0400 Subject: 192.0.0.0/24 In-Reply-To: <20100330061725.GA81284@metron.com> References: <20100330061725.GA81284@metron.com> Message-ID: On Mar 30, 2010, at 2:17 AM, Lou Katz wrote: > We recently were told to contact a client (via ftp) at 192.0.0.201. IANA lists this as > Special Use, but refers to "RFC 3330 for additional information. http://www.rfc-editor.org/rfc/rfc3330.txt". > This RFC says that it might be assigned in the future. > My guess is your client is using it that IP internally, perhaps mistakenly thinking it is RFC1918 space? I've seen this a lot when dealing with the less clued. -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C /* Don't meddle in the affairs of sysadmins, * for they are subtle and quick to anger. */ From stephen.tandy at trigenis.com Tue Mar 30 08:09:32 2010 From: stephen.tandy at trigenis.com (Stephen Tandy) Date: Tue, 30 Mar 2010 14:09:32 +0100 Subject: NANOG Digest, Vol 26, Issue 142 Message-ID: Sent from my Windows? phone. -----Original Message----- From: nanog-request at nanog.org Sent: 30 March 2010 13:00 To: nanog at nanog.org Subject: NANOG Digest, Vol 26, Issue 142 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) (Robert Kisteleki) 2. Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) (Phil Regnauld) 3. Re: IPv4 ANYCAST setup (Jens Link) 4. Re: IPv4 ANYCAST setup (bmanning at vacation.karoshi.com) 5. Re: IPv4 ANYCAST setup (Tony Finch) 6. Re: Useful URL for network operators (Valdis.Kletnieks at vt.edu) 7. RE: Auto MDI/MDI-X + conference rooms + bored == loop (William Mullaney) ---------------------------------------------------------------------- Message: 1 Date: Tue, 30 Mar 2010 11:37:49 +0200 From: Robert Kisteleki Subject: Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) To: nanog at nanog.org Message-ID: <4BB1C66D.7000808 at ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I must observe that these are not really the links you'd want to give your end users to check out. Their audience is very different. While the article on RIPE Labs comes close, they don't really answer the "does it work or does it not?" question with a green/red light, and they don't provide a good explanation to the audience Randy is referring to. Robert On 2010.03.30. 11:29, Phil Regnauld wrote: > Randy Bush (randy) writes: >> >> i.e. what can we do to maximize the odds that the victim will quickly >> find the perp, as opposed to calling our our tech support lines? > > Ah yes, there was the second good reason for actually helping netops > and security officers :) > > Tools: > > https://www.dns-oarc.net/oarc/services/replysizetest > > https://www.dnssec-deployment.org/wiki/index.php/Tools_and_Resources, > under troubleshooting: > http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues > http://secspider.cs.ucla.edu/ > > Info sheets: > > http://www.afnic.fr/actu/nouvelles/240/l-afnic-invite-les-responsables-techniques-reseaux-a-se-preparer-a-la-signature-de-la-racine-dns-en-mai-2010 > (click English, top right) > > ... plenty of links there too. > > Cheers, > Phil > ------------------------------ Message: 2 Date: Tue, 30 Mar 2010 11:52:27 +0200 From: Phil Regnauld Subject: Re: DNSSEC deployment testing and awareness (Was: Re: IPv4 ANYCAST setup) To: Robert Kisteleki Cc: nanog at nanog.org Message-ID: <20100330095226.GE24147 at macbook.catpipe.net> Content-Type: text/plain; charset=us-ascii Robert Kisteleki (robert) writes: > I must observe that these are not really the links you'd want to > give your end users to check out. Their audience is very different. > While the article on RIPE Labs comes close, they don't really answer > the "does it work or does it not?" question with a green/red light, > and they don't provide a good explanation to the audience Randy is > referring to. Fair enough. Some simple "check your DNS reply size test [what is this ?]" page ought to be set up, with a simple explanagtion. "checkmydns.org" is available. If I get 5 minutes... :) ------------------------------ Message: 3 Date: Tue, 30 Mar 2010 11:58:16 +0200 From: Jens Link Subject: Re: IPv4 ANYCAST setup To: nanog at nanog.org Message-ID: <87mxxqb07b.fsf at bowmore.quux.de> Content-Type: text/plain; charset=us-ascii "Kevin Oberman" writes: > He said that if the protocols would not handle blocked 53/tcp, the > protocols would have to be changed. Opening the port was simply not > open to discussion. Let me guess: They also completely blocked ICMP. I always tell these customers to switch to IPv6 real fast and to turn of ICMPv6 to make their networks really secure. ;-) > I will say that these were at federal government facilities. I hope the > commercial world is a bit more in touch with reality. You can find clueless people everywhere. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://www.quux.de | http://blog.quux.de | jabber: jenslink at guug.de | ------------------------------------------------------------------------- ------------------------------ Message: 4 Date: Tue, 30 Mar 2010 10:05:27 +0000 From: bmanning at vacation.karoshi.com Subject: Re: IPv4 ANYCAST setup To: Randy Bush Cc: "nanog at nanog.org" Message-ID: <20100330100527.GC30288 at vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii On Tue, Mar 30, 2010 at 05:43:25PM +0900, Randy Bush wrote: > >>> I have talked to multiple security officers (who are generally not > >>> really knowledgeable on networks) who had 53/tcp blocked and none > >>> have yet agreed to change it. > >> patience. when things really start to break, and the finger of fate > >> points at them, clue may arise. > > 36 days until all root servers have DNSSEC data, at which point large > > replies become normal. > > are end user tools, i.e. a web click a button, available so they can > test if they are behind a clueless security id10t? no - in part because using a browser to debug DNS involves a third app (and likly a third/forth) platform. the nifty OARC testpoint is nearly worthless for real operations, since its not located at/near a DNS authoritative source. the K testpoint is good, I should prolly put back the one off B. > is there good simple end user docco they are somewhat likely to find > when things break for them? not yet. in part because out of the few simple parts, many, many combinations of failure can occur. ) MTU strictures: v6/v4 tunneling v6/v4 MTU clamping ) Fragmenation UDP ) Port blocking ) Resolver Behaviour EDNS awareness > i.e. what can we do to maximize the odds that the victim will quickly > find the perp, as opposed to calling our our tech support lines? thats a tough call. as tech support staff, we are almost always an outside observer on the path btwn the victim and the perp. troubleshooting is going to be problematic. > > randy ------------------------------ Message: 5 Date: Tue, 30 Mar 2010 11:53:12 +0100 From: Tony Finch Subject: Re: IPv4 ANYCAST setup To: nanog at nanog.org Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII "Kevin Oberman" writes: > He said that if the protocols would not handle blocked 53/tcp, the > protocols would have to be changed. Opening the port was simply not > open to discussion. Do they also believe that all DNS replies are less than 512 bytes? :-) Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ------------------------------ Message: 6 Date: Tue, 30 Mar 2010 07:33:39 -0400 From: Valdis.Kletnieks at vt.edu Subject: Re: Useful URL for network operators To: Jim Mercer Cc: nanog at nanog.org Message-ID: <1191.1269948819 at localhost> Content-Type: text/plain; charset="us-ascii" On Tue, 30 Mar 2010 05:34:06 EDT, Jim Mercer said: > Once again, please ignore Jim Mercer. > He should do more homeworks too. He's said similar about a number of people who have more operations clue than he does. I'd comment, except Woody Allen already did it better: http://www.youtube.com/watch?v=9wWUc8BZgWE > a) I have never heard of Randy Bush That's OK, I encoura.. oh nevermind, it's shooting fish in a barrel. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available Url : http://mailman.nanog.org/mailman/nanog/attachments/20100330/dfea2bda/attachment-0001.pgp ------------------------------ Message: 7 Date: Tue, 30 Mar 2010 07:36:04 -0400 From: "William Mullaney" Subject: RE: Auto MDI/MDI-X + conference rooms + bored == loop To: "Chuck Anderson" , Message-ID: Content-Type: text/plain; charset="us-ascii" We had a school district that had a large number of "dumb" switches in each class room hanging off real ones. These would get looped when a student or staff member plugged a patch cable into two ports on the end switch, taking down large portions of the network. It seems Cisco 3500's ignore a BPDU that comes in the same port it comes out. We switched them to 3750's as part of other upgrades, which eliminated the BPDU problem (3560's and 3550's also work correctly), RSTP, enabled port fast, root guard, loop back detection, and storm control. Then set the switches to automatically come back in service from err-disable after 60 seconds or so. In every single test we did (looping off a dumb switch, looping two ports on the 3750, looping between two 3750 in different stacks), there was immediate blocking occurring that prevented any non-sense from effecting the network. Of course the little switches get taken out along with anything connected, but that's really just an indicator of the need for more drops from real switches. Additionally, turning on only one of the features at a time still shut down the port within a second or so. I don't really like BPDUGuard when rootguard is available, as I think other devices should be able to participate in STP so long as they aren't trying to reconverge the network by grabbing root or becoming a transit between two building switches. As for RSTP, it's on for every switch we deploy unless there is some compelling reason not to do so. I have yet to find another switch that will not work even if it only supports "old" STP. -WT -----Original Message----- From: Chuck Anderson [mailto:cra at WPI.EDU] Sent: Friday, March 26, 2010 6:09 PM To: nanog at nanog.org Subject: Auto MDI/MDI-X + conference rooms + bored == loop Anyone have suggestions on Ethernet LAN loop-prevention? With the advent of Auto MDI/MDI-X ports on switches, it seems way too easy to accidentally or maliciously create loops between network jacks. We have bored or inattentive people plugging in patch cords between adjacent network jacks. STP for loop-prevention isn't working so well for us. STP "edge" or "portfast" or "faststart" modes are required for end-station ports (with normal STP, DHCP often times out after 30+ seconds it takes to go into Forwarding state). Since the "edge" STP mode goes into Forwarding state immediately, there is a period when loops will form, causing havok with upstream gear until STP blocks the port (if it ever does see below). "Desktop" switches. You know, those 4 or 5 port Gigabit Ethernet switches. Apparently, many of them don't do any kind of STP at all. Recommendations on ones that do STP? RSTP: is it any better than traditional STP in regards to "edge" ports and blocking before a loop gets out of hand? Or perhaps blocking for 5-10 seconds before going into Forwarding state, hopefully preventing loops before they happen but also allowing DHCP clients to get an address without timeouts? Recommendations on "Desktop" switches that do RSTP? Thanks for your suggestions/discussion. -- - Chuck (354 Days until IPv4 depletion: http://ipv4depletion.com/) ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 26, Issue 142 ************************************** From bmanning at vacation.karoshi.com Tue Mar 30 08:09:17 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 30 Mar 2010 13:09:17 +0000 Subject: FTC / Nexband In-Reply-To: <78bfcf051003300603u10d0a4f9r1b094280c4bd32a2@mail.gmail.com> References: <78bfcf051003300603u10d0a4f9r1b094280c4bd32a2@mail.gmail.com> Message-ID: <20100330130917.GA32495@vacation.karoshi.com.> On Tue, Mar 30, 2010 at 03:03:48PM +0200, Colin Alston wrote: > In the real world, the result is more like: > > [coffee ~]$ dig +short adsl.fultontelephone.net A > ;; Truncated, retrying in TCP mode. > dig: dns_rdata_totext: ran out of space > > So yeah... if someone wants to correct that, it would be great. > > And if everyone else in the world can please not EVER do something > like this, that would also be good. anyone for reverse mapping an IPv6 /32? --bill From skandor at gmail.com Tue Mar 30 08:13:29 2010 From: skandor at gmail.com (A.B. Jr.) Date: Tue, 30 Mar 2010 10:13:29 -0300 Subject: BER performance on fiber links Message-ID: <25f9e2131003300613p1ed64f11kcaeb3051b4ebb698@mail.gmail.com> Hi all, What is the bit error rate that can be expected from a modern hi capacity mostly optical point to point circuits ? 10 E-7 would be too conservative or too agressive? What if the "circuit" is in fact Ethernet LAN to LAN transport? How many frames can one expect to be discarded due to link errors? Thank you in advance. A.B. From LarrySheldon at cox.net Tue Mar 30 09:55:50 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 30 Mar 2010 09:55:50 -0500 Subject: Useful URL for network operators In-Reply-To: <20100330093406.GA74607@reptiles.org> References: <20100330093406.GA74607@reptiles.org> Message-ID: <4BB210F6.9010107@cox.net> On 3/30/2010 04:34, Jim Mercer wrote: > he is invading other lists as well, looks like he is trying to become a net.kook. EXPN 'become' -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Tue Mar 30 10:04:40 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 30 Mar 2010 10:04:40 -0500 Subject: NANOG Digest, Vol 26, Issue 142 In-Reply-To: References: Message-ID: <4BB21308.8060104@cox.net> On 3/30/2010 08:09, Stephen Tandy wrote: > > > Sent from my Windows?? phone. > > -----Original Message----- > From: nanog-request at nanog.org > Sent: 30 March 2010 13:00 > To: nanog at nanog.org > Subject: NANOG Digest, Vol 26, Issue 142 > > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." [Snip] I keep seeing these. Is there a point? > You can find clueless people everywhere. > > Jens -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From lowen at pari.edu Tue Mar 30 10:09:12 2010 From: lowen at pari.edu (Lamar Owen) Date: Tue, 30 Mar 2010 11:09:12 -0400 Subject: IP4 Space In-Reply-To: <4BB13508.3010701@dougbarton.us> References: Message-ID: <201003301109.12144.lowen@pari.edu> On Monday 29 March 2010 07:17:28 pm Doug Barton wrote: > However, none of that is relevant to the fact that a change IS coming, > whether you're ready for it or not. The questions are, what will the > change(s) be, how soon, and how will it/they affect me? [snip] > So the question is not, "Can I afford to make a change?" The questions > are as above, what, and how soon? This is why "we" have been telling > people for years to work IPv6 requirements into all NEW stuff > (networking hardware, end-user systems, b/w contracts) so that WHEN the > changes start to affect you you won't have to do a forklift upgrade. The nature of these changes (what, how soon, how will I be affected) will be entirely determined by how many can afford the costs of the implementation, and how soon they can afford it, as well as how quickly others can afford it; the more 'others' that can afford it, the more desirable affording it becomes to that set of all 'others' severally. One problem I see is one of marketing; marketing towards a negative is typically much less effective than marketing a positive. Market what people can do with IPv6, not what they can't do without IPv6. The 'IPv4 address space is running out' line is much weaker than it should be (with CxO's), because it's marketing a negative. The 'wow, here's valuable stuff you can do only with IPv6' is much more compelling. What is that 'valuable stuff?' (rhetorical question, I've seen some lists, they're not a compelling as they could be) The biggest problem with using the IPv4 allocation shortage as a negative is that it's not even a hard negative, really, not like Y2K, the most successful negative marketing example that I can think of, was. But this is different; when the IPv4 space is fully allocated, my existing services won't just up and quit. I'll have to do something other than get more IPv4, of course, and I'll start by being creative with how the existing services are allocated their IPv4 space, work my way up to some NAT-PT to overlap multiple services on a single IP, all the while looking at what the IPv6 addition will cost me, and will gain me. I mean, really: address space doesn't technically run out; it just all gets allocated; IP addresses are not consumables, but to a degree they're capital. But what the RIR's give, the RIR's can take away, or rearrange. And you asymptotically approach having 4 billion AS's running /32 networks with multi- layer NAT on the eyeballs and deep name-based virtual hosting (usable since HTTP v1.1) on the content side. And an enhancement to DNS allowing a port number to be part of an A record. But if no one (or close enough to 'no one') can afford to do IPv6, then IPv6 won't happen and the above scenario becomes more likely. Likewise, if everyone (or close enough to 'everyone') can afford to do IPv6, then IPv6 will happen quickly. Those are the two ends of the 'affordability' vs. 'implementation speed' continuum. Tactically, can I afford to do IPv6? No; and it's mostly a labor issue, even though hardware and software upgrades must be purchased. Tactically, can I afford to not do IPv6? Yes. The cost of not implementing in the tactical short-term is not yet enough to offset the cost of implementing, although both costs go up the longer the delay is. Strategically, can I afford to do IPv6? Hopefully, but it might require some creative budgeting (hmm, IPv6, or replace the batteries in the UPS's....). Strategically, can I afford to not do IPv6? Of course not; my strategic plan must involve IPv6 in some way; it's been in the strategic plan for a while, now, in both Porsche and Volkswagen editions (flat 6 vs flat 4...sorry for the arcane pun). But I've got to keep my fiscal head above water before I can implement the strategic plan, otherwise there won't be a strategic plan or even a need for a strategic plan. From lowen at pari.edu Tue Mar 30 10:16:56 2010 From: lowen at pari.edu (Lamar Owen) Date: Tue, 30 Mar 2010 11:16:56 -0400 Subject: Useful URL for network operators In-Reply-To: <20100330093406.GA74607@reptiles.org> References: Message-ID: <201003301116.56984.lowen@pari.edu> On Tuesday 30 March 2010 05:34:06 am Jim Mercer wrote: > he is invading other lists as well, looks like he is trying to become a > net.kook. Kibo did it with more taste. From leo.vegoda at icann.org Tue Mar 30 10:24:05 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 30 Mar 2010 08:24:05 -0700 Subject: 192.0.0.0/24 In-Reply-To: <20100330061725.GA81284@metron.com> References: <20100330061725.GA81284@metron.com> Message-ID: On 29 Mar 2010, at 11:17, Lou Katz wrote: > We recently were told to contact a client (via ftp) at 192.0.0.201. IANA lists this as > Special Use, but refers to "RFC 3330 for additional information. http://www.rfc-editor.org/rfc/rfc3330.txt". > This RFC says that it might be assigned in the future. RFC 3330 was obsoleted with the publication of RFC 5735. I thought I'd updated all the references we made to RFC 3330 but if I've missed one I'd be grateful if you could point me to it. > So, did the folks who sent us the IP address fat-finger, or has this been assigned? > There does not appear to be any route to it. 192.0.0.0/24 is used for the IANA IPv4 Special Purpose Address Registry: http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml No assignments have been made yet but I'd strongly advise people not to use addresses in this range as a substitute for the space reserved in RFC 1918. It's likely to cause operational problems at some point in the future. Regards, Leo Vegoda From roberts at isoc.org Tue Mar 30 10:28:46 2010 From: roberts at isoc.org (Phil Roberts) Date: Tue, 30 Mar 2010 10:28:46 -0500 Subject: Internet Society IPv6 Workshop Message-ID: <4BB218AE.2040908@isoc.org> The Internet Society is hosting an IPv6 Deployment Day on April 22 in Seattle, Washington. The meeting is intended for operators who have deployed, are deploying, or are planning to deploy IPv6 in their networks. The proposed topics include business related issues for IPv6 deployment, discussion of pitfalls in IPv6 deployment, and specific technical issues due to IPv6 deployment that potentially affect the whole Internet. This is an open meeting and all are welcome, but space is limited so you will need to register: https://www.isoc.org/isoc/conferences/registration/?id=7ce20e4c88b7e328. If you have any questions please feel free to contact me, Phil Roberts (roberts at isoc.org), or Mat Ford (ford at isoc.org). From trey at arena.net Tue Mar 30 10:35:08 2010 From: trey at arena.net (Trey Valenta) Date: Tue, 30 Mar 2010 08:35:08 -0700 Subject: Auto MDI/MDI-X + conference rooms + bored == loop In-Reply-To: References: <20100326220922.GH12189@angus.ind.WPI.EDU> Message-ID: <1269963308.12231.12.camel@trey.arena.local> I had a similar issue in which someone had accidentally looked a Cisco VoIP phone back into the network. However, I found it strange how often this would occur and eventually came across this field notice that might apply to others on the list: http://www.cisco.com/en/US/ts/fn/610/fn61863.html Problem Description Disconnecting power from a locally powered Cisco IP Phone connected to a non-Power Over Ethernet (POE) Cisco switch may expose the customer's network to loop back storms that destabalize the virtual local area network (VLAN). This exposure can be mitigated by configuring the switches with automatic loop detection and port recovery. Notes indicate this normally applies onto to 10Mb connections, but that there have been reported cases on a 100Mbit network when the VoIP phone is connected to a "highly sensitive uplink switch". Trey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From asnoka at gmail.com Tue Mar 30 18:50:04 2010 From: asnoka at gmail.com (asnoka) Date: Tue, 30 Mar 2010 23:50:04 +0000 Subject: Disable IPv4 routing for routing-instance? Message-ID: <1269993004.5171.4.camel@localhost> Hello list, Junos provice a method to disable isis ipv4 routing support like this: isis { no-ipv4-routing; } However,we want to disable ipv4 routing for an VRF like that,is there any method for us to do so? Thanks a lot. From Ed.Lewis at neustar.biz Tue Mar 30 11:01:24 2010 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 30 Mar 2010 12:01:24 -0400 Subject: 192.0.0.0/24 In-Reply-To: References: <20100330061725.GA81284@metron.com> Message-ID: At 8:24 -0700 3/30/10, Leo Vegoda wrote: >192.0.0.0/24 is used for the IANA IPv4 Special Purpose Address Registry: For the record, there's an RFC dedicated to that range (which Leo co-edited): http://www.rfc-editor.org/in-notes/rfc5736.txt -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 New pithy statement under construction... From braaen at zcorum.com Tue Mar 30 11:52:43 2010 From: braaen at zcorum.com (Brian Raaen) Date: Tue, 30 Mar 2010 12:52:43 -0400 Subject: Hotmail/MSN/Live.com Abuse contact Message-ID: <201003301252.43668.braaen@zcorum.com> As I have not been contacted after filling out the web form and any mail I try and send to abuse at hotmail.com or postmaster at live.com is being blocked can someone in the Abuse department contact me at abuse at rhemasound.org Thanks. Sorry about making noise on the list but all other attempts have failed. -- ---------------------- Brian Raaen Network Engineer From sfouant at shortestpathfirst.net Tue Mar 30 12:17:03 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Tue, 30 Mar 2010 13:17:03 -0400 Subject: Disable IPv4 routing for routing-instance? In-Reply-To: <1269993004.5171.4.camel@localhost> References: <1269993004.5171.4.camel@localhost> Message-ID: <003e01cad02c$d15a60a0$740f21e0$@net> > -----Original Message----- > From: asnoka [mailto:asnoka at gmail.com] > Sent: Tuesday, March 30, 2010 7:50 PM > To: nanog at nanog.org > Subject: Disable IPv4 routing for routing-instance? > > Hello list, > Junos provice a method to disable isis ipv4 routing support like > this: > > isis { > no-ipv4-routing; > } > > However,we want to disable ipv4 routing for an VRF like that,is there > any method for us to do so? You might want to try checking out the Juniper-NSP mailing list for future questions of this nature - http://puck.nether.net/mailman/listinfo/juniper-nsp But while we are on the topic, you can disable the IPv4 routing for a VRF with the following: 'set routing-instances protocols isis no-ipv4-routing' Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From tkapela at gmail.com Tue Mar 30 12:19:49 2010 From: tkapela at gmail.com (Anton Kapela) Date: Tue, 30 Mar 2010 13:19:49 -0400 Subject: Mindfulness (was Re: NANOG Digest, Vol 26, Issue 142) In-Reply-To: <4BB21308.8060104@cox.net> References: <4BB21308.8060104@cox.net> Message-ID: On Mar 30, 2010, at 11:04 AM, Larry Sheldon wrote: > I keep seeing these. Is there a point? (see sub:) -Tk From randy at psg.com Tue Mar 30 13:49:12 2010 From: randy at psg.com (Randy Bush) Date: Wed, 31 Mar 2010 03:49:12 +0900 Subject: NANOG Digest, Vol 26, Issue 142 In-Reply-To: <4BB21308.8060104@cox.net> References: <4BB21308.8060104@cox.net> Message-ID: >> Sent from my Windows?? phone. > I keep seeing these. Is there a point? don't use a windows phone? :) From LarrySheldon at cox.net Tue Mar 30 13:54:33 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 30 Mar 2010 13:54:33 -0500 Subject: NANOG Digest, Vol 26, Issue 142 In-Reply-To: References: <4BB21308.8060104@cox.net> Message-ID: <4BB248E9.8020909@cox.net> On 3/30/2010 13:49, Randy Bush wrote: >>> Sent from my Windows?? phone. >> I keep seeing these. Is there a point? > > don't use a windows phone? :) ??? I've got a wall-phone near the sink, but I don't use it to read email. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From fw at deneb.enyo.de Tue Mar 30 14:29:22 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 30 Mar 2010 21:29:22 +0200 Subject: DNSSEC deployment testing and awareness In-Reply-To: <20100330095226.GE24147@macbook.catpipe.net> (Phil Regnauld's message of "Tue, 30 Mar 2010 11:52:27 +0200") References: <60311E48-70BA-4675-8C69-268E66AC7961@hopcount.ca> <20100330045956.EB00B1CC31@ptavv.es.net> <7F282E43-B67C-4119-9D85-BF40C1C7BE1E@dotat.at> <20100330092858.GC24147@macbook.catpipe.net> <4BB1C66D.7000808@ripe.net> <20100330095226.GE24147@macbook.catpipe.net> Message-ID: <87zl1pr4kt.fsf@mid.deneb.enyo.de> * Phil Regnauld: > Fair enough. Some simple "check your DNS reply size test > [what is this ?]" page ought to be set up, with a simple > explanagtion. "checkmydns.org" is available. If I get 5 > minutes... :) Reply sizes are a red herring. You need something that looks at the result of ./IN/DNSKEY, ./IN/RRSIG, ./IN/NSEC. At least one of these queries should return data, some of the time. (Unfortunately, the test is probabilistic.) Then you know that your resolver can receive data from the signed root and will not cease to work when all the roots serve the signed zone. Other tests can't tell you that. If your resolver is DNSSEC-aware, you can force cache misses by using random query names with a non-existing TLD. This variant of the test is much easier to carry out. From jason at lixfeld.ca Tue Mar 30 14:55:24 2010 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 30 Mar 2010 15:55:24 -0400 Subject: Collapsing device management peripherals Message-ID: <7EEDE886-0E1B-4377-8DEE-889AFF00D37D@lixfeld.ca> Right now, I've got a pull-out KVM connected to an external KVM switch that connects to the management ports on our blade centers, etc. I've also got a separate console server for our network devices with a modem for out of band. I'd love to be able to collapse these three devices into one. I've seen pull-out KVMs that have an integrated KVM switch, but I haven't seen anything that is also IP enabled to cover the console server component as well. Has anyone seen such an animal, by chance? From peter.hicks at poggs.co.uk Tue Mar 30 15:05:32 2010 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Tue, 30 Mar 2010 21:05:32 +0100 Subject: Collapsing device management peripherals In-Reply-To: <7EEDE886-0E1B-4377-8DEE-889AFF00D37D@lixfeld.ca> References: <7EEDE886-0E1B-4377-8DEE-889AFF00D37D@lixfeld.ca> Message-ID: <4BB2598C.3010301@poggs.co.uk> Jason Lixfeld wrote: > Right now, I've got a pull-out KVM connected to an external KVM > switch that connects to the management ports on our blade centers, > etc. I've also got a separate console server for our network devices > with a modem for out of band. > > I'd love to be able to collapse these three devices into one. I've > seen pull-out KVMs that have an integrated KVM switch, but I haven't > seen anything that is also IP enabled to cover the console server > component as well. > > Has anyone seen such an animal, by chance? Check what OpenGear have to offer. I recall looking at their integrated infrastructure management kit a while back. P From jgreco at ns.sol.net Tue Mar 30 16:30:48 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 30 Mar 2010 15:30:48 -0600 (CST) Subject: IPv4 ANYCAST setup In-Reply-To: from "Tony Finch" at Mar 30, 2010 11:53:12 AM Message-ID: <201003302130.o2ULUmol092239@aurora.sol.net> > "Kevin Oberman" writes: > > He said that if the protocols would not handle blocked 53/tcp, the > > protocols would have to be changed. Opening the port was simply not > > open to discussion. > > Do they also believe that all DNS replies are less than 512 bytes? :-) Sure, why not. The phrase "simply not open to discussion" in this context can be accurately read as "we were told this was good, but couldn't possibly defend the line of reasoning since we have no clue what it was." It's like debating PMTU brokenness with someone who feels that blocking all ICMP is a Really Smart Clever Good Thing To Do, because someone told them all about evil ICMP. Sometimes, the happiest solution is to let the pain rain. ... 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 martin at theicelandguy.com Tue Mar 30 18:50:52 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 30 Mar 2010 19:50:52 -0400 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <4B98C6E4.6020203@nic-naa.net> References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> Message-ID: None. On 3/11/10, Eric Brunner-Williams wrote: > What NANOG contributors, if any, are invited by a government, to join > their national delegation to the initial meeting of the ITU's IPv6 > Group in Geneva next week? > > -- Sent from my mobile device Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From jared at puck.nether.net Tue Mar 30 19:03:06 2010 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 30 Mar 2010 20:03:06 -0400 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> Message-ID: You can speak for yourself :) Some of us are watching the lists on the appropriate mailing list(s) hosted by the US State Department. I know I facilitated a few people joining them. - Jared On Mar 30, 2010, at 7:50 PM, Martin Hannigan wrote: > None. > > > > > On 3/11/10, Eric Brunner-Williams wrote: >> What NANOG contributors, if any, are invited by a government, to join >> their national delegation to the initial meeting of the ITU's IPv6 >> Group in Geneva next week? >> >> > > -- > Sent from my mobile device > > Martin Hannigan martin at theicelandguy.com > p: +16178216079 > Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From richard.barnes at gmail.com Tue Mar 30 19:05:06 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 30 Mar 2010 20:05:06 -0400 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> Message-ID: <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> There were a few representatives of the Internet community at the meeting. All five RIRs were represented, as was ISOC. The notable absence was ICANN. Of course, this sample is by no means representative of the entire community, but it's more than "None." On Tue, Mar 30, 2010 at 7:50 PM, Martin Hannigan wrote: > None. > > > > > On 3/11/10, Eric Brunner-Williams wrote: >> What NANOG contributors, if any, are invited by a government, to join >> their national delegation to the initial meeting of the ITU's IPv6 >> Group in Geneva next week? >> >> > > -- > Sent from my mobile device > > Martin Hannigan ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? martin at theicelandguy.com > p: +16178216079 > Power, Network, and Costs Consulting for Iceland Datacenters and Occupants > > From drc at virtualized.org Tue Mar 30 19:15:47 2010 From: drc at virtualized.org (David Conrad) Date: Tue, 30 Mar 2010 14:15:47 -1000 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> Message-ID: Well, actually, ICANN was in Geneva specifically for the meeting, but we weren't allowed into the room. Quite annoying, actually. Regards, -drc On Mar 30, 2010, at 2:05 PM, Richard Barnes wrote: > There were a few representatives of the Internet community at the > meeting. All five RIRs were represented, as was ISOC. The notable > absence was ICANN. Of course, this sample is by no means > representative of the entire community, but it's more than "None." > > > > On Tue, Mar 30, 2010 at 7:50 PM, Martin Hannigan > wrote: >> None. >> >> >> >> >> On 3/11/10, Eric Brunner-Williams wrote: >>> What NANOG contributors, if any, are invited by a government, to join >>> their national delegation to the initial meeting of the ITU's IPv6 >>> Group in Geneva next week? >>> >>> >> >> -- >> Sent from my mobile device >> >> Martin Hannigan martin at theicelandguy.com >> p: +16178216079 >> Power, Network, and Costs Consulting for Iceland Datacenters and Occupants >> >> > > From martin at theicelandguy.com Tue Mar 30 19:25:59 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 30 Mar 2010 20:25:59 -0400 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> Message-ID: Eric asked who was invited by a government to join a delegation. I think that the ITU invited the RIR's. Jared. Mailing lists don't count :) Best, Marty On 3/30/10, Richard Barnes wrote: > There were a few representatives of the Internet community at the > meeting. All five RIRs were represented, as was ISOC. The notable > absence was ICANN. Of course, this sample is by no means > representative of the entire community, but it's more than "None." > > > > On Tue, Mar 30, 2010 at 7:50 PM, Martin Hannigan > wrote: >> None. >> >> >> >> >> On 3/11/10, Eric Brunner-Williams wrote: >>> What NANOG contributors, if any, are invited by a government, to join >>> their national delegation to the initial meeting of the ITU's IPv6 >>> Group in Geneva next week? >>> >>> >> >> -- >> Sent from my mobile device >> >> Martin Hannigan ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? martin at theicelandguy.com >> p: +16178216079 >> Power, Network, and Costs Consulting for Iceland Datacenters and Occupants >> >> > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From jared at puck.nether.net Tue Mar 30 19:37:18 2010 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 30 Mar 2010 20:37:18 -0400 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> Message-ID: On Mar 30, 2010, at 8:25 PM, Martin Hannigan wrote: > Eric asked who was invited by a government to join a delegation. I > think that the ITU invited the RIR's. > > Jared. Mailing lists don't count :) When the invitation goes out to the list membership saying "Who is going to be at X and needs creds/whatnot" that certainly counts. Sorry you don't see it that way. - Jared From woody at pch.net Tue Mar 30 19:51:31 2010 From: woody at pch.net (Bill Woodcock) Date: Tue, 30 Mar 2010 16:51:31 -0800 (PST) Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> Message-ID: On Tue, 30 Mar 2010, Jared Mauch wrote: > You can speak for yourself :) > Some of us are watching the lists on the appropriate mailing list(s) hosted by the US State Department. I know I facilitated a few people joining them. Yep, I would agree that the "Internet technical community," as they like to pigeonhole us, were well-represented at the meeting, and in the process running up to the meeting. -Bill From martin at theicelandguy.com Tue Mar 30 20:50:37 2010 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 30 Mar 2010 21:50:37 -0400 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> Message-ID: I'm not disagreeing. But see DRC's comment. Best, -M< On 3/30/10, Jared Mauch wrote: > > On Mar 30, 2010, at 8:25 PM, Martin Hannigan wrote: > >> Eric asked who was invited by a government to join a delegation. I >> think that the ITU invited the RIR's. >> >> Jared. Mailing lists don't count :) > > When the invitation goes out to the list membership saying "Who is going to > be at X and needs creds/whatnot" that certainly counts. > > Sorry you don't see it that way. > > - Jared -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants From trelane at trelane.net Tue Mar 30 22:07:10 2010 From: trelane at trelane.net (Andrew D Kirch) Date: Tue, 30 Mar 2010 23:07:10 -0400 Subject: Useful URL for network operators In-Reply-To: <4BAE5A3D.4080804@cox.net> References: <4BAE5A3D.4080804@cox.net> Message-ID: <4BB2BC5E.90501@trelane.net> Larry Sheldon wrote: > On 3/27/2010 12:10, Guillaume FORTAINE wrote: > nymshifting son of a ..... > > More stringent measures are required. > > I second this. I want this guy gone. (The frog, not Larry) Andrew From steve at ibctech.ca Tue Mar 30 22:14:52 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 30 Mar 2010 23:14:52 -0400 Subject: Finding content in your job title Message-ID: <4BB2BE2C.9000901@ibctech.ca> Hi all, This is perhaps a rather silly question, but one that I'd like to have answered. I'm young in the game, and over the years I've imagined numerous job titles that should go on my business card. They went from cool, to high-priority, to plain unimaginable. Now, after 10 years, I reflect back on what I've done, and what I do now. To me, if a business is loose-knit with no clear job descriptions or titles (ie. too small to have CXO etc), I feel that a business card should reflect what one feels is the primary job responsibility, or what they do the most (or love the most). For instance, I like to present myself as a 'network engineer'. I have never taken formal education, don't hold any certifications (well, since 2001), and can't necessarily prove my worth. How does the ops community feel about using this designation? Is it intrusive or offensive to those who hold real engineering degrees? I'm content with 'network manager', given that I still do perform (in my sleep) numerous system tasks and have to sometimes deal with front-line helpdesk stuff. Instead of acting like I'm trying to sell myself out, I'll leave out what I actually do and ask those who sig themselves with 'network engineer' what they do day-to-day to acquire that title, and if they feel comfortable with having it. Steve From sfouant at shortestpathfirst.net Tue Mar 30 22:18:39 2010 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Tue, 30 Mar 2010 23:18:39 -0400 Subject: Useful URL for network operators In-Reply-To: <4BB2BC5E.90501@trelane.net> References: <4BAE5A3D.4080804@cox.net> <4BB2BC5E.90501@trelane.net> Message-ID: <005f01cad080$dcbee610$963cb230$@net> > -----Original Message----- > From: Andrew D Kirch [mailto:trelane at trelane.net] > Sent: Tuesday, March 30, 2010 11:07 PM > To: Larry Sheldon > Cc: nanog at nanog.org > Subject: Re: Useful URL for network operators > > Larry Sheldon wrote: > > On 3/27/2010 12:10, Guillaume FORTAINE wrote: > > nymshifting son of a ..... > > > > More stringent measures are required. > > > > > I second this. I want this guy gone. (The frog, not Larry) Hey now, I don't like this guys tactics either, but frog??? ;) Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D From jmamodio at gmail.com Tue Mar 30 22:20:25 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 30 Mar 2010 22:20:25 -0500 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: I'd say that probably around here for those like me that have been in operations/engineering management positions we don't give a squat about what title your biz card says you have, your actions and performance speak by themselves. There are no kings around here so titles most of the time are worthless. By asking what title may impress others is sort of a -1 to start. Cheers Jorge On Tue, Mar 30, 2010 at 10:14 PM, Steve Bertrand wrote: > Hi all, > > This is perhaps a rather silly question, but one that I'd like to have > answered. > > I'm young in the game, and over the years I've imagined numerous job > titles that should go on my business card. They went from cool, to > high-priority, to plain unimaginable. > > Now, after 10 years, I reflect back on what I've done, and what I do > now. To me, if a business is loose-knit with no clear job descriptions > or titles (ie. too small to have CXO etc), I feel that a business card > should reflect what one feels is the primary job responsibility, or what > they do the most (or love the most). > > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, since > 2001), and can't necessarily prove my worth. > > How does the ops community feel about using this designation? Is it > intrusive or offensive to those who hold real engineering degrees? I'm > content with 'network manager', given that I still do perform (in my > sleep) numerous system tasks and have to sometimes deal with front-line > helpdesk stuff. > > Instead of acting like I'm trying to sell myself out, I'll leave out > what I actually do and ask those who sig themselves with 'network > engineer' what they do day-to-day to acquire that title, and if they > feel comfortable with having it. > > Steve From bmanning at vacation.karoshi.com Tue Mar 30 22:22:13 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 31 Mar 2010 03:22:13 +0000 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <20100331032213.GA5543@vacation.karoshi.com.> On Tue, Mar 30, 2010 at 11:14:52PM -0400, Steve Bertrand wrote: > Hi all, > > This is perhaps a rather silly question, but one that I'd like to have > answered. > > I'm young in the game, and over the years I've imagined numerous job > titles that should go on my business card. They went from cool, to > high-priority, to plain unimaginable. > > Now, after 10 years, I reflect back on what I've done, and what I do > now. To me, if a business is loose-knit with no clear job descriptions > or titles (ie. too small to have CXO etc), I feel that a business card > should reflect what one feels is the primary job responsibility, or what > they do the most (or love the most). > > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, since > 2001), and can't necessarily prove my worth. > > How does the ops community feel about using this designation? Is it > intrusive or offensive to those who hold real engineering degrees? I'm > content with 'network manager', given that I still do perform (in my > sleep) numerous system tasks and have to sometimes deal with front-line > helpdesk stuff. > > Instead of acting like I'm trying to sell myself out, I'll leave out > what I actually do and ask those who sig themselves with 'network > engineer' what they do day-to-day to acquire that title, and if they > feel comfortable with having it. > > Steve > well, there are communities which use the term "engineer" as a term of art adn frown on this group co-opting the term "network enginer" ... maybe you really don't want to go there (even if it is what you do). I've used memorable terms in the past, gadfly, plumber, chief bottle-washer, and have seen goddess, evangelist, and more. --bill From steve at ibctech.ca Tue Mar 30 22:26:17 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 30 Mar 2010 23:26:17 -0400 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <4BB2C0D9.4020607@ibctech.ca> On 2010.03.30 23:20, Jorge Amodio wrote: > I'd say that probably around here for those like me that have been in > operations/engineering management positions we don't give a squat > about what title your biz card says you have, your actions and > performance speak by themselves. > > There are no kings around here so titles most of the time are worthless. > > By asking what title may impress others is sort of a -1 to start. It isn't about impression. I'd put 'janitor' on my business card for all I really care. I know what I love to do, and I know what I am great at. 10 years in the industry now. The only person who I try to impress is myself... by staying current on BCP and better ways to do things. My curiosity has the best of me, so I am looking for opinions. You have one ;) Those who know me know what I can do, and in reality, that is all I care about. I'm not out to impress anyone. I just want to be a good netizen like the rest. Impression isn't what I'm after. What I'm curious about is the potential over-use of the term 'engineer'. Cheers, Steve From LarrySheldon at cox.net Tue Mar 30 22:30:38 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 30 Mar 2010 22:30:38 -0500 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <4BB2C1DE.1070004@cox.net> On 3/30/2010 22:14, Steve Bertrand wrote: > Hi all, > > This is perhaps a rather silly question, but one that I'd like to have > answered. > > I'm young in the game, and over the years I've imagined numerous job > titles that should go on my business card. They went from cool, to > high-priority, to plain unimaginable. > > Now, after 10 years, I reflect back on what I've done, and what I do > now. To me, if a business is loose-knit with no clear job descriptions > or titles (ie. too small to have CXO etc), I feel that a business card > should reflect what one feels is the primary job responsibility, or what > they do the most (or love the most). > > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, since > 2001), and can't necessarily prove my worth. > > How does the ops community feel about using this designation? Is it > intrusive or offensive to those who hold real engineering degrees? I'm > content with 'network manager', given that I still do perform (in my > sleep) numerous system tasks and have to sometimes deal with front-line > helpdesk stuff. > > Instead of acting like I'm trying to sell myself out, I'll leave out > what I actually do and ask those who sig themselves with 'network > engineer' what they do day-to-day to acquire that title, and if they > feel comfortable with having it. When the University I worked for went all touchy-feely and told us to pick titles for ourselves I wanted to use "Savant". They wouldn't let me, so I tried "Jack Of All Trades". Vetoed. So I just stayed with the cards I had that said Associate Director for Telecommunications and Computers. Which is about as void of meaning then and now as anything I have ever heard of. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From randy at psg.com Tue Mar 30 22:30:49 2010 From: randy at psg.com (Randy Bush) Date: Wed, 31 Mar 2010 12:30:49 +0900 Subject: BGP Update Report In-Reply-To: References: <201003192200.o2JM01vK037512@wattle.apnic.net> <20100328132943.GB59866@gweep.net> <226B7CBF-ED2E-40A1-A3BC-DD9C43C71C0D@gmail.com> Message-ID: > It's not just AS_PATH, a lot of the reason so many duplicate updates > occur (nearly 50% of all updates at times, and often more during the > busiest times) is because on the other end implementations don't keep > egress advertisement state per attribute (e.g., if cluster_list length > just triggered an internal transition then a new update is sent to > external peers with no new information because the determining > internal attributes are stripped before transmitting the new update), > yet those *prefixes* might well be suppressed as a result of the > implementation and/or network architecture on the other end of the BGP > connection. > > Then you couple what Joe was pointing out, where intermediate nodes > with consistently unstable links or "paths" result in penalizing an > entire prefix, not just the unstable paths, and it makes for more > brokenness than benefit when route flap damping is employed. > > It's not that people haven't studied and understand why this occurs, > the issue is that implementation optimizations seem to always win out > today over systemic state effects (i.e., that "be conservative in what > you send" thing doesn't seem to apply in practice, unfortunately). might some of this be that the implementations use router-id to fill in an unconfigured rr cluster-id? randy From nanog at daork.net Tue Mar 30 22:30:43 2010 From: nanog at daork.net (Nathan Ward) Date: Wed, 31 Mar 2010 16:30:43 +1300 Subject: Finding content in your job title In-Reply-To: <4BB2C0D9.4020607@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C0D9.4020607@ibctech.ca> Message-ID: On 31/03/2010, at 4:26 PM, Steve Bertrand wrote: > On 2010.03.30 23:20, Jorge Amodio wrote: >> I'd say that probably around here for those like me that have been in >> operations/engineering management positions we don't give a squat >> about what title your biz card says you have, your actions and >> performance speak by themselves. >> >> There are no kings around here so titles most of the time are worthless. >> >> By asking what title may impress others is sort of a -1 to start. > > It isn't about impression. > > I'd put 'janitor' on my business card for all I really care. I'm pretty sure Jonny Martin was Chief Internet Janitor in his previous role. He cleaned the tubes so the sewage could flow. -- Nathan Ward From steve at ibctech.ca Tue Mar 30 22:33:01 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 30 Mar 2010 23:33:01 -0400 Subject: Finding content in your job title In-Reply-To: <20100331032213.GA5543@vacation.karoshi.com.> References: <4BB2BE2C.9000901@ibctech.ca> <20100331032213.GA5543@vacation.karoshi.com.> Message-ID: <4BB2C26D.5030601@ibctech.ca> On 2010.03.30 23:22, bmanning at vacation.karoshi.com wrote: > On Tue, Mar 30, 2010 at 11:14:52PM -0400, Steve Bertrand wrote: >> Hi all, >> >> This is perhaps a rather silly question, but one that I'd like to have >> answered. >> >> I'm young in the game, and over the years I've imagined numerous job >> titles that should go on my business card. They went from cool, to >> high-priority, to plain unimaginable. >> >> Now, after 10 years, I reflect back on what I've done, and what I do >> now. To me, if a business is loose-knit with no clear job descriptions >> or titles (ie. too small to have CXO etc), I feel that a business card >> should reflect what one feels is the primary job responsibility, or what >> they do the most (or love the most). >> >> For instance, I like to present myself as a 'network engineer'. I have >> never taken formal education, don't hold any certifications (well, since >> 2001), and can't necessarily prove my worth. >> >> How does the ops community feel about using this designation? Is it >> intrusive or offensive to those who hold real engineering degrees? I'm >> content with 'network manager', given that I still do perform (in my >> sleep) numerous system tasks and have to sometimes deal with front-line >> helpdesk stuff. >> >> Instead of acting like I'm trying to sell myself out, I'll leave out >> what I actually do and ask those who sig themselves with 'network >> engineer' what they do day-to-day to acquire that title, and if they >> feel comfortable with having it. >> >> Steve >> > > well, there are communities which use the term "engineer" > as a term of art adn frown on this group co-opting the > term "network enginer" ... maybe you really don't want to > go there (even if it is what you do). > > I've used memorable terms in the past, gadfly, plumber, chief > bottle-washer, and have seen goddess, evangelist, and more. heh. Plumber is good. Electrician would be better considering I'm about 120 hours away from writing my resi ticket ;) I did not mean to initiate a thread that turns into a joke. I'm quite serious. I guess I'm curious to get an understanding from others who work in a small environment that have no choice but to 'classify' themselves. Steve From jmamodio at gmail.com Tue Mar 30 22:34:58 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 30 Mar 2010 22:34:58 -0500 Subject: Finding content in your job title In-Reply-To: <4BB2C0D9.4020607@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C0D9.4020607@ibctech.ca> Message-ID: Ok, let see. In several countries the use of the "title" engineer applies to people that achieved a certain technical degree, I'm not sure that applies uniformly but in Latin America using the engineer title without having achieved that degree is illegal. In other places such Italy it does not only require that you completed the technical degree, you also must achieve certain level of certifications. Here in the US there are some particular type of "engineers" for which the title is regulated, for example "civil engineer". The IEEE says: "The title, Engineer, and its derivatives should be reserved for those individuals whose education and experience qualify them to practice in a manner that protects public safety. Strict use of the title serves the interest of both the IEEE-USA and the public by providing a recognized designation by which those qualified to practice engineering may be identified. The education and experience needed for the title, Engineer, is evidenced by" - Graduation with an Engineering degree from an ABET/EAC accredited program of engineering (or equivalent*), coupled with sufficient experience in the field in which the term, Engineer, is used; and/or - Licensure by any jurisdiction as a Professional Engineer. - A degree from a foreign institution (or the total education when one person holds a graduate degree in engineering but no accredited B.S. in engineering) can be evaluated through a service offered by ABET." Not sure if there similar regulations that apply in Canada. My .02 Jorge On Tue, Mar 30, 2010 at 10:26 PM, Steve Bertrand wrote: > On 2010.03.30 23:20, Jorge Amodio wrote: >> I'd say that probably around here for those like me that have been in >> operations/engineering management positions we don't give a squat >> about what title your biz card says you have, your actions and >> performance speak by themselves. >> >> There are no kings around here so titles most of the time are worthless. >> >> By asking what title may impress others is sort of a -1 to start. > > It isn't about impression. > > I'd put 'janitor' on my business card for all I really care. > > I know what I love to do, and I know what I am great at. 10 years in the > industry now. The only person who I try to impress is myself... by > staying current on BCP and better ways to do things. > > My curiosity has the best of me, so I am looking for opinions. You have > one ;) > > Those who know me know what I can do, and in reality, that is all I care > about. I'm not out to impress anyone. I just want to be a good netizen > like the rest. > > Impression isn't what I'm after. What I'm curious about is the potential > over-use of the term 'engineer'. > > Cheers, > > Steve > From steve at ibctech.ca Tue Mar 30 22:35:49 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 30 Mar 2010 23:35:49 -0400 Subject: Finding content in your job title In-Reply-To: <4BB2C1DE.1070004@cox.net> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C1DE.1070004@cox.net> Message-ID: <4BB2C315.10105@ibctech.ca> On 2010.03.30 23:30, Larry Sheldon wrote: > On 3/30/2010 22:14, Steve Bertrand wrote: >> Hi all, >> >> This is perhaps a rather silly question, but one that I'd like to have >> answered. >> >> I'm young in the game, and over the years I've imagined numerous job >> titles that should go on my business card. They went from cool, to >> high-priority, to plain unimaginable. >> >> Now, after 10 years, I reflect back on what I've done, and what I do >> now. To me, if a business is loose-knit with no clear job descriptions >> or titles (ie. too small to have CXO etc), I feel that a business card >> should reflect what one feels is the primary job responsibility, or what >> they do the most (or love the most). >> >> For instance, I like to present myself as a 'network engineer'. I have >> never taken formal education, don't hold any certifications (well, since >> 2001), and can't necessarily prove my worth. >> >> How does the ops community feel about using this designation? Is it >> intrusive or offensive to those who hold real engineering degrees? I'm >> content with 'network manager', given that I still do perform (in my >> sleep) numerous system tasks and have to sometimes deal with front-line >> helpdesk stuff. >> >> Instead of acting like I'm trying to sell myself out, I'll leave out >> what I actually do and ask those who sig themselves with 'network >> engineer' what they do day-to-day to acquire that title, and if they >> feel comfortable with having it. > > > When the University I worked for went all touchy-feely and told us to > pick titles for ourselves I wanted to use "Savant". > > They wouldn't let me, so I tried "Jack Of All Trades". > > Vetoed. > > So I just stayed with the cards I had that said Associate Director for > Telecommunications and Computers. > > Which is about as void of meaning then and now as anything I have ever > heard of. heh. The feedback that I've received off-list has led me to believe that I just need to scratch the title, and have my name and number. Who cares what I do. Those who want to call/email me will have a purpose for doing so anyway ;) Steve From steve at ibctech.ca Tue Mar 30 22:37:22 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 30 Mar 2010 23:37:22 -0400 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C0D9.4020607@ibctech.ca> Message-ID: <4BB2C372.1080500@ibctech.ca> On 2010.03.30 23:34, Jorge Amodio wrote: > Ok, let see. In several countries the use of the "title" engineer > applies to people that achieved a certain technical degree, I'm not > sure that applies uniformly but in Latin America using the engineer > title without having achieved that degree is illegal. > > In other places such Italy it does not only require that you completed > the technical degree, you also must achieve certain level of > certifications. > > Here in the US there are some particular type of "engineers" for which > the title is regulated, for example "civil engineer". > > The IEEE says: > > "The title, Engineer, and its derivatives should be reserved for those > individuals whose education and experience qualify them to practice in > a manner that protects public safety. Strict use of the title serves > the interest of both the IEEE-USA and the public by providing a > recognized designation by which those qualified to practice > engineering may be identified. The education and experience needed for > the title, Engineer, is evidenced by" > - Graduation with an Engineering degree from an ABET/EAC accredited > program of engineering (or equivalent*), coupled with sufficient > experience in the field in which the term, Engineer, is used; and/or > - Licensure by any jurisdiction as a Professional Engineer. > - A degree from a foreign institution (or the total education when one > person holds a graduate degree in engineering but no accredited B.S. > in engineering) can be evaluated through a service offered by ABET." > > Not sure if there similar regulations that apply in Canada. Cheers Jorge, This is pretty much what I was after. Thanks for digging it up for me. Steve From tkapela at gmail.com Tue Mar 30 22:41:45 2010 From: tkapela at gmail.com (Anton Kapela) Date: Tue, 30 Mar 2010 23:41:45 -0400 Subject: Finding content in your job title In-Reply-To: <4BB2C26D.5030601@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> <20100331032213.GA5543@vacation.karoshi.com.> <4BB2C26D.5030601@ibctech.ca> Message-ID: <4BD833DF-9733-4865-AED0-4E14065D89AF@gmail.com> On Mar 30, 2010, at 11:33 PM, Steve Bertrand wrote: > I did not mean to initiate a thread that turns into a joke. I'm quite > serious. I guess I'm curious to get an understanding from others who > work in a small environment that have no choice but to 'classify' > themselves. Unless we're talking about converting hydrocarbons to heat/energy or driving trains, the term Engineer is over-applied. To borrow an old phrase, What's in a Title? -Tk From trelane at trelane.net Tue Mar 30 22:42:46 2010 From: trelane at trelane.net (Andrew D Kirch) Date: Tue, 30 Mar 2010 23:42:46 -0400 Subject: Posting from freebie E-mail Accounts Message-ID: <4BB2C4B6.6070809@trelane.net> Is there anyone here who is legitimate using a freebie webmail account? I am proposing that the NANOG administration drop everything originating from commonly used webmail providers, and add further RHS filters as additional providers are identified as problems. Andrew From aj at sneep.net Tue Mar 30 22:44:02 2010 From: aj at sneep.net (Alastair Johnson) Date: Wed, 31 Mar 2010 11:44:02 +0800 Subject: Finding content in your job title In-Reply-To: <4BB2C26D.5030601@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> <20100331032213.GA5543@vacation.karoshi.com.> <4BB2C26D.5030601@ibctech.ca> Message-ID: <4BB2C502.6030905@sneep.net> Steve Bertrand wrote: > I did not mean to initiate a thread that turns into a joke. I'm quite > serious. I guess I'm curious to get an understanding from others who > work in a small environment that have no choice but to 'classify' > themselves. When I was in a similar role and situation to yourself my cards said "network manager". These days, working in an organisation big enough to restructure weekly, I removed the title from my business cards - now I have a blank space where I can write one in if I really *need* it. But mostly I don't. aj From jmamodio at gmail.com Tue Mar 30 22:47:34 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 30 Mar 2010 22:47:34 -0500 Subject: Finding content in your job title In-Reply-To: <4BB2C315.10105@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C1DE.1070004@cox.net> <4BB2C315.10105@ibctech.ca> Message-ID: that's right Steve, as I said before, what you do and how you do it, and in particular what do you contribute to the networking community will speak much better of yourself than any title you can imagine. Do you think that folks like Tim Berners-Lee, Vint Cerf, Jon Postel, etc, etc, need a title ? Focus on the substance not on the appearance. J > The feedback that I've received off-list has led me to believe that I > just need to scratch the title, and have my name and number. > > Who cares what I do. Those who want to call/email me will have a purpose > for doing so anyway ;) > > Steve > > From LarrySheldon at cox.net Tue Mar 30 22:50:26 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 30 Mar 2010 22:50:26 -0500 Subject: Finding content in your job title In-Reply-To: <4BB2C315.10105@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C1DE.1070004@cox.net> <4BB2C315.10105@ibctech.ca> Message-ID: <4BB2C682.6070707@cox.net> On 3/30/2010 22:35, Steve Bertrand wrote: > The feedback that I've received off-list has led me to believe that I > just need to scratch the title, and have my name and number. > > Who cares what I do. Those who want to call/email me will have a purpose > for doing so anyway ;) Post University I identify myself by name, three phone numbers and email address. Ifv I still carried a pager, its number might have been there, although when I last carried a pager, the telephone system we had would page me if somebody left a message. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From tkapela at gmail.com Tue Mar 30 22:50:33 2010 From: tkapela at gmail.com (Anton Kapela) Date: Tue, 30 Mar 2010 23:50:33 -0400 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C0D9.4020607@ibctech.ca> Message-ID: <5BABD94F-5EE4-4375-9BF1-A2116F1C7896@gmail.com> On Mar 30, 2010, at 11:34 PM, Jorge Amodio wrote: > "The title, Engineer, and its derivatives should be reserved for those > individuals whose education and experience qualify them to practice in > a manner that protects public safety. Strict use of the title serves ...fortunately for us (and CCIE's around the globe) running the Internet doesn't involve much public trust. Does it? In a few states in the US, working for the same engineering firm for some number of years (usually 6 or more) counts similarly as passing a state-administered professional engineering exam. It would be with some significant precedent, then, that a job or other professional experience does indeed equate to state-sponsored public trust. So, back to Steve's first question: > How does the ops community feel about using this designation? If you've been doing it for a while, and not been chased out, I would argue there is ample precedent to support don'ing the title. I guess the sticky-bits here include, potentially, a derth of colleges and graduate study calling itself "network engineering." Failing that, perhaps nanog-l could take a vote: Does Steve deserve the title of Network Train Driver, list? -Tk From tkapela at gmail.com Tue Mar 30 22:52:54 2010 From: tkapela at gmail.com (Anton Kapela) Date: Tue, 30 Mar 2010 23:52:54 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB2C4B6.6070809@trelane.net> References: <4BB2C4B6.6070809@trelane.net> Message-ID: On Mar 30, 2010, at 11:42 PM, Andrew D Kirch wrote: > Is there anyone here who is legitimate using a freebie webmail account? I'm implicitly legit; further, gmail auto-threads all of the run-on posts automatically (much unlike mail.app, outlook 2k8, etc). What's the beef? -Tk From LarrySheldon at cox.net Tue Mar 30 22:54:36 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 30 Mar 2010 22:54:36 -0500 Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB2C4B6.6070809@trelane.net> References: <4BB2C4B6.6070809@trelane.net> Message-ID: <4BB2C77C.6020105@cox.net> On 3/30/2010 22:42, Andrew D Kirch wrote: > Is there anyone here who is legitimate using a freebie webmail account? > I am proposing that the NANOG administration drop everything originating > from commonly used webmail providers, and add further RHS filters as > additional providers are identified as problems. I have mixed feelings--I use a gmail account for some things. As a moderator on other lists, I'm more comfortable with taking a quick hammer to miscreants with any debate off line. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Tue Mar 30 22:56:40 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Tue, 30 Mar 2010 22:56:40 -0500 Subject: Finding content in your job title In-Reply-To: <4BB2C502.6030905@sneep.net> References: <4BB2BE2C.9000901@ibctech.ca> <20100331032213.GA5543@vacation.karoshi.com.> <4BB2C26D.5030601@ibctech.ca> <4BB2C502.6030905@sneep.net> Message-ID: <4BB2C7F8.3020407@cox.net> On 3/30/2010 22:44, Alastair Johnson wrote: > Steve Bertrand wrote: >> I did not mean to initiate a thread that turns into a joke. I'm quite >> serious. I guess I'm curious to get an understanding from others who >> work in a small environment that have no choice but to 'classify' >> themselves. > > When I was in a similar role and situation to yourself my cards said > "network manager". > > These days, working in an organisation big enough to restructure weekly, > I removed the title from my business cards - now I have a blank space > where I can write one in if I really *need* it. But mostly I don't. I've done that--the most useful information (IMHO) is connector (telno or email) and reason why they want to contact me. -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From deleskie at gmail.com Tue Mar 30 23:00:32 2010 From: deleskie at gmail.com (jim deleskie) Date: Wed, 31 Mar 2010 01:00:32 -0300 Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB2C4B6.6070809@trelane.net> References: <4BB2C4B6.6070809@trelane.net> Message-ID: I'm betting more then a few of use free mail accts to keep this separate from our work mail. If your really having that much issue, config your mail server to drop it yourself or unsub.... Seriously -jim yes posted from gmail acct. On Wed, Mar 31, 2010 at 12:42 AM, Andrew D Kirch wrote: > Is there anyone here who is legitimate using a freebie webmail account? > I am proposing that the NANOG administration drop everything originating > from commonly used webmail providers, and add further RHS filters as > additional providers are identified as problems. > > Andrew > > From blakjak at blakjak.net Tue Mar 30 23:01:47 2010 From: blakjak at blakjak.net (Mark Foster) Date: Wed, 31 Mar 2010 17:01:47 +1300 (NZDT) Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB2C4B6.6070809@trelane.net> References: <4BB2C4B6.6070809@trelane.net> Message-ID: <49833.119.15.0.26.1270008107.squirrel@webmail.blakjak.net> On Wed, March 31, 2010 4:42 pm, Andrew D Kirch wrote: > Is there anyone here who is legitimate using a freebie webmail account? > I am proposing that the NANOG administration drop everything originating > from commonly used webmail providers, and add further RHS filters as > additional providers are identified as problems. > I've found that most folks administering mailing lists tend to advocate that folks use a personal email address on them, not a professional one, as it tends to free the list from a glut of 'Out of Office' notices, rediculously long disclaimer footers, and other such things; this seems particularly relevant for NANOG. With that in mind and noting a goodly number of folks using gmail, among others, i'm not sure the cost:benefit would be there? There's other ways to moderate content on a mailing list.... From nrauhauser at gmail.com Tue Mar 30 23:07:41 2010 From: nrauhauser at gmail.com (neal rauhauser) Date: Tue, 30 Mar 2010 23:07:41 -0500 Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB2C4B6.6070809@trelane.net> References: <4BB2C4B6.6070809@trelane.net> Message-ID: I keep all of my mailing list stuff in gmail. I suppose I could move it, but this list has so little trouble (unless gmail is doing a fantastic job of shielding me) that I don't see the point. On Tue, Mar 30, 2010 at 10:42 PM, Andrew D Kirch wrote: > Is there anyone here who is legitimate using a freebie webmail account? > I am proposing that the NANOG administration drop everything originating > from commonly used webmail providers, and add further RHS filters as > additional providers are identified as problems. > > Andrew > > -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com GV: 202-642-1717 From steve at ibctech.ca Tue Mar 30 23:11:20 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 31 Mar 2010 00:11:20 -0400 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C1DE.1070004@cox.net> <4BB2C315.10105@ibctech.ca> Message-ID: <4BB2CB68.2090804@ibctech.ca> On 2010.03.30 23:47, Jorge Amodio wrote: > that's right Steve, as I said before, what you do and how you do it, > and in particular what do you contribute to the networking community > will speak much better of yourself than any title you can imagine. > > Do you think that folks like Tim Berners-Lee, Vint Cerf, Jon Postel, > etc, etc, need a title ? > > Focus on the substance not on the appearance. grazie, I capire. My post was two fold... and I received a *lot* of off-list feedback that I'll have to respond to tomorrow. Generally, I know that a title isn't relevant, especially in the small little area that I'm in. I was just very curious, as it came up in discussion today. I like to think that I do everything possible to do my part. To be honest, I have as much or more interest in protecting other ASs than I do our own clients (shhh ;) Thanks very much Jorge. Although this was a fast-paced thread that was very entertaining, you've enlightened me. Cheers, Steve -- new sig - stevieb - senior master of disaster - wrongly null-routing client bgp communities, and allowing x-vlan sniffing since 1998 From fergdawgster at gmail.com Tue Mar 30 23:12:25 2010 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 30 Mar 2010 21:12:25 -0700 Subject: Posting from freebie E-mail Accounts In-Reply-To: References: <4BB2C4B6.6070809@trelane.net> Message-ID: <6cd462c01003302112t3576d94bhcf006c1b9e79af87@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Mar 30, 2010 at 9:00 PM, jim deleskie wrote: > I'm betting more then a few of use free mail accts to keep this > separate from our work mail. If your really having that much issue, > config your mail server to drop it yourself or unsub.... > > Seriously > > -jim yes posted from gmail acct. Ditto. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLssujq1pz9mNUZTMRAjWSAJ4hkP0RWOVcd3I1gKz1yns46oVNIQCg1Mgo vSQUjEXmqmQBfraDy+gfsgw= =W1My -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From steve at ibctech.ca Tue Mar 30 23:15:14 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 31 Mar 2010 00:15:14 -0400 Subject: Finding content in your job title In-Reply-To: <5BABD94F-5EE4-4375-9BF1-A2116F1C7896@gmail.com> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C0D9.4020607@ibctech.ca> <5BABD94F-5EE4-4375-9BF1-A2116F1C7896@gmail.com> Message-ID: <4BB2CC52.2000800@ibctech.ca> On 2010.03.30 23:50, Anton Kapela wrote: > > On Mar 30, 2010, at 11:34 PM, Jorge Amodio wrote: > >> "The title, Engineer, and its derivatives should be reserved for those >> individuals whose education and experience qualify them to practice in >> a manner that protects public safety. Strict use of the title serves > > ...fortunately for us (and CCIE's around the globe) running the Internet doesn't involve much public trust. Does it? > > In a few states in the US, working for the same engineering firm for some number of years (usually 6 or more) counts similarly as passing a state-administered professional engineering exam. It would be with some significant precedent, then, that a job or other professional experience does indeed equate to state-sponsored public trust. > > So, back to Steve's first question: > >> How does the ops community feel about using this designation? > > > If you've been doing it for a while, and not been chased out, I would argue there is ample precedent to support don'ing the title. I guess the sticky-bits here include, potentially, a derth of colleges and graduate study calling itself "network engineering." > > Failing that, perhaps nanog-l could take a vote: > > Does Steve deserve the title of Network Train Driver, list? Not acceptable. I do not want this. I read and review messages and documents from people who have *much* more experience than I do every single day, and whom I respect to the n'th degree. This isn't a vote count. I am _not_ an engineer, and do not need or desire the title. Thanks anyway though ;) Steve From trelane at trelane.net Tue Mar 30 23:15:56 2010 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 31 Mar 2010 00:15:56 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB2C4B6.6070809@trelane.net> References: <4BB2C4B6.6070809@trelane.net> Message-ID: <4BB2CC7C.9070603@trelane.net> Andrew D Kirch wrote: > Is there anyone here who is legitimate using a freebie webmail account? > I am proposing that the NANOG administration drop everything originating > from commonly used webmail providers, and add further RHS filters as > additional providers are identified as problems. > > Andrew > > Ok, point made. Andrew From zeusdadog at gmail.com Tue Mar 30 23:23:26 2010 From: zeusdadog at gmail.com (Jay Nakamura) Date: Wed, 31 Mar 2010 00:23:26 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: References: <4BB2C4B6.6070809@trelane.net> Message-ID: I use gmail for all mailing lists. It's easier for me to organize my work flow and catch up on threads on my BB when I have a spare idle moment. On 3/31/10, neal rauhauser wrote: > I keep all of my mailing list stuff in gmail. I suppose I could move it, > but this list has so little trouble (unless gmail is doing a fantastic job > of shielding me) that I don't see the point. > > > > > On Tue, Mar 30, 2010 at 10:42 PM, Andrew D Kirch wrote: > >> Is there anyone here who is legitimate using a freebie webmail account? >> I am proposing that the NANOG administration drop everything originating >> from commonly used webmail providers, and add further RHS filters as >> additional providers are identified as problems. >> >> Andrew >> >> > > > -- > mailto:Neal at layer3arts.com // > GoogleTalk: nrauhauser at gmail.com > GV: 202-642-1717 > From steve at ibctech.ca Tue Mar 30 23:23:36 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 31 Mar 2010 00:23:36 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB2C4B6.6070809@trelane.net> References: <4BB2C4B6.6070809@trelane.net> Message-ID: <4BB2CE48.1020404@ibctech.ca> On 2010.03.30 23:42, Andrew D Kirch wrote: > I am proposing that the NANOG administration drop everything originating > from commonly used webmail providers, I oppose this proposal. There are very legitimate (and legal) reasons why people may want to post to an operational list, using an address that can not tie them to the location or business that they are posting from. This list does not see much spam (or at least I don't). That said, let the list maintainers decide. Steve From math at sizone.org Tue Mar 30 23:36:08 2010 From: math at sizone.org (Ken Chase) Date: Wed, 31 Mar 2010 00:36:08 -0400 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <20100331043608.GY30528@sizone.org> On Tue, Mar 30, 2010 at 10:20:25PM -0500, Jorge Amodio said: >I'd say that probably around here for those like me that have been in >operations/engineering management positions we don't give a squat >about what title your biz card says you have, your actions and >performance speak by themselves. > >There are no kings around here so titles most of the time are worthless. > >By asking what title may impress others is sort of a -1 to start. But you are wrong. Titles do speak and impress just not how you might expect. Having a 'jokey' title signifies to other equally free-to-operate-within-the-org people that you have the necessary freedom to act outside the standard procedures when required. If you get away with "chief evangelist" (as Mike Shaver had for a while at mozilla), not to mention his other card which was "international incident" (possibly referring to a crypto export situation?), you obviously have some independent (freedom from?) authority and autonomy. I managed to have Grizzled Internet Prospector on my card for a while at my previous firm. It was as accurate as anything else I could put and indicated to my peers that I was actually, well, an owner, eschewing a stuffy "CEO" or "COO" title. (I had other sub companies with stuffy titles on them in case someone outside the clued area needed to be placated.) Another friend had "minister of fear" as his title at a network security firm. At an exodus sponsored event which featured both Sun's XML accelerator platform (?) and Bruce Schneier (the main attraction), he was originally banned due to his joke title. The local industry slapped back through the clued peoples' oldboys-n-girls network, and they backpedalled and he was admitted at the last minute. It bit the exodus event organizer in the ass hard, and had her eating crow for him in front of 30 of his peers at the event, and handing over a free signed copy of Schneier's book. He really gained notoriety and street cred from the situation, as silly as it was. Besting the established order is worth something in most circles, still. (Google anyone?) She obviously didnt understand the new business rules in effect: the jokey title signified that titles didnt matter, reputation and ability did. Being able to have a joke title indicates you dont need a real one. And so they're important in a reverse-psychology kind of way :) /kc (grizzled tube plumber) > >Cheers >Jorge > >On Tue, Mar 30, 2010 at 10:14 PM, Steve Bertrand wrote: >> Hi all, >> >> This is perhaps a rather silly question, but one that I'd like to have >> answered. >> >> I'm young in the game, and over the years I've imagined numerous job >> titles that should go on my business card. They went from cool, to >> high-priority, to plain unimaginable. >> >> Now, after 10 years, I reflect back on what I've done, and what I do >> now. To me, if a business is loose-knit with no clear job descriptions >> or titles (ie. too small to have CXO etc), I feel that a business card >> should reflect what one feels is the primary job responsibility, or what >> they do the most (or love the most). >> >> For instance, I like to present myself as a 'network engineer'. I have >> never taken formal education, don't hold any certifications (well, since >> 2001), and can't necessarily prove my worth. >> >> How does the ops community feel about using this designation? Is it >> intrusive or offensive to those who hold real engineering degrees? I'm >> content with 'network manager', given that I still do perform (in my >> sleep) numerous system tasks and have to sometimes deal with front-line >> helpdesk stuff. >> >> Instead of acting like I'm trying to sell myself out, I'll leave out >> what I actually do and ask those who sig themselves with 'network >> engineer' what they do day-to-day to acquire that title, and if they >> feel comfortable with having it. >> >> Steve -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From tvhawaii at shaka.com Tue Mar 30 23:53:00 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 30 Mar 2010 18:53:00 -1000 Subject: Finding content in your job title References: <4BB2BE2C.9000901@ibctech.ca><4BB2C0D9.4020607@ibctech.ca><5BABD94F-5EE4-4375-9BF1-A2116F1C7896@gmail.com> <4BB2CC52.2000800@ibctech.ca> Message-ID: <71D31ACD83534DC19AA62B0381BA9814@DELL16> Steve Bertrand wrote: > > Not acceptable. I do not want this. > > I read and review messages and documents from people who have *much* > more experience than I do every single day, and whom I respect to the > n'th degree. > > This isn't a vote count. I am _not_ an engineer, and do not need or > desire the title. > > Thanks anyway though ;) > > Steve Back at IBM ('64 to '71) we were officially called "Customer Engineer". When the 'System 360' was released, it was changed to "Field Engineer". --Michael From jbfixurpc at gmail.com Wed Mar 31 00:19:26 2010 From: jbfixurpc at gmail.com (Joe) Date: Wed, 31 Mar 2010 01:19:26 -0400 Subject: Finding content in your job title In-Reply-To: Message-ID: <000001cad091$c17fbd50$4401a8c0@jgbpc> What I find most amusing in the field of networking is the terms and titles various companies place upon them. Titles like "Infrastructure specialist", "Network analyst", and "Senior Specialist" often have me giggling as to the real meaning/position in a job posting. I think the funniest postings I see are the ones where obviously someone in a HR role posts the position and lumps together different aspects of the role trying to be filled, such as "Cisco MS Exchange expert" or "Firewall SQL Expert". Needless to say those are not titles I would be boasting about or would care to advertise. In short the last business card I handed out simply had the title MIS Dept. Its hard enough to explain some of the aspects of network engineering to my wife let alone a description of such on a business card. On one occasion my mother in law asked if I could get a discount on large amounts of food, I asked why she thought I could do such and her reply was "well you work with Sysco, a food services company"..... Needless to say it took a bit of time to explain that sysco was not cisco. Perhaps a brief description on the back of the card? Lol... Regards. -Joe From danny at tcb.net Wed Mar 31 00:20:38 2010 From: danny at tcb.net (Danny McPherson) Date: Tue, 30 Mar 2010 23:20:38 -0600 Subject: BGP Update Report In-Reply-To: References: <201003192200.o2JM01vK037512@wattle.apnic.net> <20100328132943.GB59866@gweep.net> <226B7CBF-ED2E-40A1-A3BC-DD9C43C71C0D@gmail.com> Message-ID: <110276D7-324B-486F-9DAF-6EB3DFEC24E6@tcb.net> On Mar 30, 2010, at 9:30 PM, Randy Bush wrote: > might some of this be that the implementations use router-id to fill in > an unconfigured rr cluster-id? Yep! So intermediate nodes in an iBGP topology with varying cluster IDs per RR with a common client set can certainly result in duplicate eBGP updates (not to mention lots of *useless* adj-RIB-In memory on those RRs for storing routes that are completely useless and would otherwise be discarded). That said, even with common cluster IDs within a client set, and even a single level (or completely flat) iBGP hierarchy, coupled with any jitter, variable propagation delay along a path, asymmetric or not, depending on transport connection dynamics, or variance in update arrival rates, and BGP speaker MRAI interactions with each, all can result in these duplicate updates at egress, and subsequent suppression via flap damping if employed. And, of course, this is compounded by external interconnection denseness on ingress and even non-adjacent downstream ASNs. I.e., there's room for protocol, implementation, and network architecture variables here, and operators should expressly factor systemic effects of each in their operating environment - they can have considerable impact. -danny From swmike at swm.pp.se Wed Mar 31 00:41:18 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 31 Mar 2010 07:41:18 +0200 (CEST) Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB2CE48.1020404@ibctech.ca> References: <4BB2C4B6.6070809@trelane.net> <4BB2CE48.1020404@ibctech.ca> Message-ID: On Wed, 31 Mar 2010, Steve Bertrand wrote: > On 2010.03.30 23:42, Andrew D Kirch wrote: > >> I am proposing that the NANOG administration drop everything originating >> from commonly used webmail providers, > > I oppose this proposal. > > There are very legitimate (and legal) reasons why people may want to > post to an operational list, using an address that can not tie them to > the location or business that they are posting from. > > This list does not see much spam (or at least I don't). That said, let > the list maintainers decide. I would much prefer if EVERYBODY used freebie email accounts as opposed to their corporate ones, as this would make it more likely that they would quote "correctly" and we would get less silly legal disclaimers and out of office messages. I don't use my work account for any mailing lists because it's totally useless for that purpose. I also will participate in these mailing lists regardless of my employer, thus I never understood why someone would want to post from their corporate accounts. -- Mikael Abrahamsson email: swmike at swm.pp.se From sethm at rollernet.us Wed Mar 31 00:50:47 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 30 Mar 2010 22:50:47 -0700 Subject: Posting from freebie E-mail Accounts In-Reply-To: References: <4BB2C4B6.6070809@trelane.net> <4BB2CE48.1020404@ibctech.ca> Message-ID: <4BB2E2B7.3040500@rollernet.us> On 3/30/10 10:41 PM, Mikael Abrahamsson wrote: > > I would much prefer if EVERYBODY used freebie email accounts as opposed > to their corporate ones, as this would make it more likely that they > would quote "correctly" and we would get less silly legal disclaimers > and out of office messages. > > I don't use my work account for any mailing lists because it's totally > useless for that purpose. I also will participate in these mailing lists > regardless of my employer, thus I never understood why someone would > want to post from their corporate accounts. > That's an exact opposite of silly from the OP's request; my "corporate account" works just fine. ~Seth From swmike at swm.pp.se Wed Mar 31 01:00:40 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 31 Mar 2010 08:00:40 +0200 (CEST) Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB2E2B7.3040500@rollernet.us> References: <4BB2C4B6.6070809@trelane.net> <4BB2CE48.1020404@ibctech.ca> <4BB2E2B7.3040500@rollernet.us> Message-ID: On Tue, 30 Mar 2010, Seth Mattinen wrote: > That's an exact opposite of silly from the OP's request; my "corporate > account" works just fine. Well, your corporate account seems to involve less silly (exchange/lotus notes) than most. -- Mikael Abrahamsson email: swmike at swm.pp.se From ulf at Alameda.net Wed Mar 31 01:10:12 2010 From: ulf at Alameda.net (Ulf Zimmermann) Date: Tue, 30 Mar 2010 23:10:12 -0700 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <20100331061012.GW30353@evil.alameda.net> On Tue, Mar 30, 2010 at 11:14:52PM -0400, Steve Bertrand wrote: > Hi all, > > This is perhaps a rather silly question, but one that I'd like to have > answered. > > I'm young in the game, and over the years I've imagined numerous job > titles that should go on my business card. They went from cool, to > high-priority, to plain unimaginable. > > Now, after 10 years, I reflect back on what I've done, and what I do > now. To me, if a business is loose-knit with no clear job descriptions > or titles (ie. too small to have CXO etc), I feel that a business card > should reflect what one feels is the primary job responsibility, or what > they do the most (or love the most). > > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, since > 2001), and can't necessarily prove my worth. > > How does the ops community feel about using this designation? Is it > intrusive or offensive to those who hold real engineering degrees? I'm > content with 'network manager', given that I still do perform (in my > sleep) numerous system tasks and have to sometimes deal with front-line > helpdesk stuff. > > Instead of acting like I'm trying to sell myself out, I'll leave out > what I actually do and ask those who sig themselves with 'network > engineer' what they do day-to-day to acquire that title, and if they > feel comfortable with having it. > > Steve I solve that problem this way: 1 set of Business cards with "Senior System Architect", an arbitary title the company gave me at some point 1 set of Business cards with "Senior Monkey for almost everything" -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From steve at ibctech.ca Wed Mar 31 01:38:07 2010 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 31 Mar 2010 02:38:07 -0400 (EDT) Subject: Posting from freebie E-mail Accounts Message-ID: <4435.69.49.38.10.1270017487.squirrel@webmail.ibctech.ca> > On Wed, 31 Mar 2010, Steve Bertrand wrote: > >> On 2010.03.30 23:42, Andrew D Kirch wrote: >> >>> I am proposing that the NANOG administration drop everything >>> originating >>> from commonly used webmail providers, >> >> I oppose this proposal. >> >> There are very legitimate (and legal) reasons why people may want to >> post to an operational list, using an address that can not tie them to >> the location or business that they are posting from. >> >> This list does not see much spam (or at least I don't). That said, let >> the list maintainers decide. > > I would much prefer if EVERYBODY used freebie email accounts as opposed to > their corporate ones, as this would make it more likely that they would > quote "correctly" and we would get less silly legal disclaimers and out of > office messages. Personally, I don't give a fsck about corporate tags and/or legal notifications. My girl is a Federally certified Health and Safety Officer and works within the Nuclear industry. Each email she sends me that crosses her corporate Domino server contains about eight lines of non-72-width crap which usually translates into twice the length of the actual message. Although she _can_ use my personal (or external, ie. freebie) email services to relay out email from within her company, it likely isn't something that she should be doing (although their internal IT policy doesn't outright prohibit it...yet, or else I'd be the first to scream at her). The disclaimers, although annoying, to me are acceptable. Some enterprise have strict guidelines on email/communication use. I would sooner see the disclaimers as opposed to not have those valuable people not post at all. > I don't use my work account for any mailing lists because it's totally > useless for that purpose. I also will participate in these mailing lists > regardless of my employer, thus I never understood why someone would want > to post from their corporate accounts. I feel that in many cases that there are very good reasons for posting from such. Aside from the fact that some people post to ops/eng/rir/tech etc lists from their corporate email address because of internal policy, in many cases, I'd think that it makes sense that many postings to lists are for work purposes directly. Almost all of mine are. Whether I send from steveb at eagle.ca (my work email addr), steve at ibctech.ca or steve at ipv6canada.com shouldn't matter. I recognize your name Mikael, not your email address. Regardless, disclaimers and legal fluff are easily discarded when replying ;) Steve From regnauld at nsrc.org Wed Mar 31 01:42:45 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 31 Mar 2010 08:42:45 +0200 Subject: Useful URL for network operators In-Reply-To: <005f01cad080$dcbee610$963cb230$@net> References: <4BAE5A3D.4080804@cox.net> <4BB2BC5E.90501@trelane.net> <005f01cad080$dcbee610$963cb230$@net> Message-ID: <20100331064244.GA62147@macbook.catpipe.net> Stefan Fouant (sfouant) writes: > > I second this. I want this guy gone. (The frog, not Larry) > > Hey now, I don't like this guys tactics either, but frog??? ;) Some foregone conclusion about the Gaullic origins of said timewasting individual. Cheers, Philippe Jacques Bernard Regnauld From gbonser at seven.com Wed Mar 31 01:45:04 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 30 Mar 2010 23:45:04 -0700 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE6B33@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Steve Bertrand [mailto:steve at ibctech.ca] > Sent: Tuesday, March 30, 2010 8:15 PM > To: nanog at nanog.org >> nanog list > Subject: Finding content in your job title > How does the ops community feel about using this designation? Is it > intrusive or offensive to those who hold real engineering degrees? I'm > content with 'network manager', given that I still do perform (in my > sleep) numerous system tasks and have to sometimes deal with front-line > helpdesk stuff. I don't think it matters so much what you call yourself, but what job role are you filling in the corporate org chart? You might not be a degreed engineer but if you are serving as the company's "Network Engineer" then that is what you are. I would say that would go as long as the title is on a company business card and not a personal card. I would say that I would use the term "engineer" on a personal card only if I were an engineer in my field of practice by certification or degree. In a company, though, my title is the role I fill within the organization. I tend to prefer the "architect" designation mainly because it describes what I really do. I design the network, specify the equipment, get it all running, and am then happy to turn over the day to day operation to someone else provided there is a someone else to do it. My title within my organization is Senior Network Engineer but I personally see my role as Senior Network Architect and is what I would put on a personal card and is how I "self identify". George From sean at donelan.com Wed Mar 31 02:19:07 2010 From: sean at donelan.com (Sean Donelan) Date: Wed, 31 Mar 2010 03:19:07 -0400 (EDT) Subject: DNSSEC and Firewalls (was Re: IPv4 ANYCAST setup) In-Reply-To: <20100330045956.EB00B1CC31@ptavv.es.net> References: <20100330045956.EB00B1CC31@ptavv.es.net> Message-ID: On Mon, 29 Mar 2010, Kevin Oberman wrote: > Fix your security officers! > > I have talked to multiple security officers (who are generally not > really knowledgeable on networks) who had 53/tcp blocked and none have > yet agreed to change it. The last one told me that blocking 53/tcp is > "standard industry practice" as per his firewall training. Point out > what RFCs said simply bounced off of him. He said that if the protocols > would not handle blocked 53/tcp, the protocols would have to be > changed. Opening the port was simply not open to discussion. > > They don't seen to really care if things are broken and seem to feel > that it is up to "the network" to accommodate their idea of normal > firewall configuration. > > I will say that these were at federal government facilities. I hope the > commercial world is a bit more in touch with reality. If you are with a US Federal agency having problems like this, or any other issues with your DNSSEC deployment, please include them in the DNSSEC survey every US Federal executive agency has been tasked to submit by the Office of Management and Budget. http://iase.disa.mil/stigs/stig/dns_stig_v4r1_20071017.pdf If, for example, an organization placed an authoritative server in its DMZ but limited zone transfers to servers behind the firewall, then it could allow inbound and outbound UDP 53 to and from the DMZ name server to allow queries, but deny TCP 53 in both directions to prohibit zone transfers. This configuration, however, is strongly discouraged because it may prevent legitimate DNS transactions that involve large responses (e.g., a DNSSEC signature). In general, limitations on queries, zone updates and transfers should be implemented in the name server's configuration rather than through configuration of firewalls, routers, or other communications devices. From andy-nanog at bash.sh Wed Mar 31 02:32:25 2010 From: andy-nanog at bash.sh (Andrew Mulholland) Date: Wed, 31 Mar 2010 07:32:25 +0000 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: On Wed, Mar 31, 2010 at 3:14 AM, Steve Bertrand wrote: > Hi all, > > This is perhaps a rather silly question, but one that I'd like to have > answered. > > I'm young in the game, and over the years I've imagined numerous job > titles that should go on my business card. They went from cool, to > high-priority, to plain unimaginable. > My approach is not to put job title on the business cards. There's no need. :) From jcdill.lists at gmail.com Wed Mar 31 03:04:32 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 31 Mar 2010 01:04:32 -0700 Subject: Posting from freebie E-mail Accounts In-Reply-To: <6cd462c01003302112t3576d94bhcf006c1b9e79af87@mail.gmail.com> References: <4BB2C4B6.6070809@trelane.net> <6cd462c01003302112t3576d94bhcf006c1b9e79af87@mail.gmail.com> Message-ID: <4BB30210.30004@gmail.com> Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Mar 30, 2010 at 9:00 PM, jim deleskie wrote: > > >> I'm betting more then a few of use free mail accts to keep this >> separate from our work mail. If your really having that much issue, >> config your mail server to drop it yourself or unsub.... >> >> Seriously >> >> -jim yes posted from gmail acct. >> > > Ditto. > > - - ferg +1 (posting from gmail account) jc From rsk at gsp.org Wed Mar 31 03:23:24 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 31 Mar 2010 04:23:24 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB2C4B6.6070809@trelane.net> References: <4BB2C4B6.6070809@trelane.net> Message-ID: <20100331082324.GA28445@gsp.org> On Tue, Mar 30, 2010 at 11:42:46PM -0400, Andrew D Kirch wrote: > I am proposing that the NANOG administration drop everything originating > from commonly used webmail providers [...] Bad idea. While free webmail providers are prodigious sources of abuse, they're not prodigious sources of abuse that makes it through to this list -- thanks to what I'm presuming is prudent configuration of the MTA and Mailman instance involved in running it. Additionally, some folks find that directing bulk, non-personal traffic like mailing lists to free webmail accounts makes it easier for them to participate. (And as noted by others, it does seem to free us from the meaningless, unenforceable, threatening disclaimers imposed by some of the more clueless companies out there.) If using those accounts facilitates the participation of people who can contribute to the community, then I see no reason at present to put up barriers to that. ---Rsk From hrlinneweh at sbcglobal.net Wed Mar 31 03:32:53 2010 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Wed, 31 Mar 2010 01:32:53 -0700 (PDT) Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB30210.30004@gmail.com> References: <4BB2C4B6.6070809@trelane.net> <6cd462c01003302112t3576d94bhcf006c1b9e79af87@mail.gmail.com> <4BB30210.30004@gmail.com> Message-ID: <851708.17041.qm@web180314.mail.gq1.yahoo.com> Currently there are 3556 post's from nanog in this mailist account, I use this 1, of ten sub-accounts that I have with this provider to focus clearly on Nanog related issues. It is not free. I do however?prefer that the professionals stay away from irc or facebook cutsy pie names, it is also good if you show those names like fergie does his, it is part of the network tradition and in good spirit. -henry ________________________________ From: JC Dill To: "nanog at nanog.org" Sent: Wed, March 31, 2010 12:04:32 AM Subject: Re: Posting from freebie E-mail Accounts Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Mar 30, 2010 at 9:00 PM, jim deleskie wrote: > >? >> I'm betting more then a few of use free mail accts to keep this >> separate from our work mail.? If your really having that much issue, >> config your mail server to drop it yourself or unsub.... >> >> Seriously >> >> -jim? yes posted from gmail acct. >>? ? > > Ditto. > > - - ferg +1? (posting from gmail account) jc From jmamodio at gmail.com Wed Mar 31 03:49:32 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 31 Mar 2010 03:49:32 -0500 Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB30210.30004@gmail.com> References: <4BB2C4B6.6070809@trelane.net> <6cd462c01003302112t3576d94bhcf006c1b9e79af87@mail.gmail.com> <4BB30210.30004@gmail.com> Message-ID: >>> I'm betting more then a few of use free mail accts to keep this >>> separate from our work mail. ?If your really having that much issue, >>> config your mail server to drop it yourself or unsub.... >>> >>> Seriously >>> >>> -jim ? yes posted from gmail acct. >>> >> >> Ditto. >> >> - - ferg > > +1 ?(posting from gmail account) +2 (also from gmail) free anti spam, no need for antivirus, free storage, spam don't go to my "official" address, don't have to make backups, can read from anywhere, mostly used for email lists. The problem is the source not what service he/she uses, trolls will be trolls regardless of what freebie fqdn they use. Jorge From brunner at nic-naa.net Wed Mar 31 04:58:56 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 31 Mar 2010 05:58:56 -0400 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> Message-ID: <4BB31CE0.3000005@nic-naa.net> That's odd. I was invited, by the US, but I'd scheduled CORE's technical meeting in Dortmund the following week, and there is only so much away time I can schedule while my wife is a 1L at Cornell Law, so I sent my regrets. The utility of going, as part of the US ISP delegation, and being excluded from even observing, seems odd. Anyway, the point of my question is how much clue is available when and where policy is made, visibly in the neighborhood of zero through ICANN's (and this is not drcs' fault, far from it) vehicle for ISP participation in policy making. So what is it in the ITU playpen? The value appears to be in the same range. I could be completely mistaken, hence the question. The short form of my contribution to the issues discussion is that iso3166 in the IANA root solved a scaling problem (epoch==Jon Postel), but left stateless peoples waiting for DNS Godot. A CIR model has the same issue for v6 allocation, leaving the same peoples waiting for a single v6 block Godot. Agreement is not mandatory. Eric On 3/30/10 8:15 PM, David Conrad wrote: > Well, actually, ICANN was in Geneva specifically for the meeting, but we weren't allowed into the room. Quite annoying, actually. > > Regards, > -drc > > On Mar 30, 2010, at 2:05 PM, Richard Barnes wrote: >> There were a few representatives of the Internet community at the >> meeting. All five RIRs were represented, as was ISOC. The notable >> absence was ICANN. Of course, this sample is by no means >> representative of the entire community, but it's more than "None." >> >> >> >> On Tue, Mar 30, 2010 at 7:50 PM, Martin Hannigan >> wrote: >>> None. >>> >>> >>> >>> >>> On 3/11/10, Eric Brunner-Williams wrote: >>>> What NANOG contributors, if any, are invited by a government, to join >>>> their national delegation to the initial meeting of the ITU's IPv6 >>>> Group in Geneva next week? >>>> >>>> >>> >>> -- >>> Sent from my mobile device >>> >>> Martin Hannigan martin at theicelandguy.com >>> p: +16178216079 >>> Power, Network, and Costs Consulting for Iceland Datacenters and Occupants >>> >>> >> >> > > > > > From w3yni1 at gmail.com Wed Mar 31 07:53:30 2010 From: w3yni1 at gmail.com (Charles Mills) Date: Wed, 31 Mar 2010 08:53:30 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: References: <4BB2C4B6.6070809@trelane.net> <6cd462c01003302112t3576d94bhcf006c1b9e79af87@mail.gmail.com> <4BB30210.30004@gmail.com> Message-ID: We are not allowed to post from work email accounts to lists such as these as well. The CISO's reasoning (and he may have a point...) is that we might ask the list "Hey...I can't figure out why my Cisco $MODEL router is doing "this" when I upgrade to $VERSION of IOS." Then someone trolling to hack you knows you have one of them in your network running that version of code. It still may be easy enough to extrapolate where you work from your personal email using other publicly available methods but On Wed, Mar 31, 2010 at 4:49 AM, Jorge Amodio wrote: >>>> I'm betting more then a few of use free mail accts to keep this >>>> separate from our work mail. ?If your really having that much issue, >>>> config your mail server to drop it yourself or unsub.... >>>> >>>> Seriously >>>> >>>> -jim ? yes posted from gmail acct. >>>> >>> >>> Ditto. >>> >>> - - ferg >> >> +1 ?(posting from gmail account) > > +2 (also from gmail) > > free anti spam, no need for antivirus, free storage, spam don't go to > my "official" address, don't have to make backups, can read from > anywhere, mostly used for email lists. > > The problem is the source not what service he/she uses, trolls will be > trolls regardless of what freebie fqdn they use. > > Jorge > > From lists at quux.de Wed Mar 31 08:01:18 2010 From: lists at quux.de (Jens Link) Date: Wed, 31 Mar 2010 15:01:18 +0200 Subject: Posting from freebie E-mail Accounts In-Reply-To: (jim deleskie's message of "Wed\, 31 Mar 2010 01\:00\:32 -0300") References: <4BB2C4B6.6070809@trelane.net> Message-ID: <87bpe4prvl.fsf@bowmore.quux.de> jim deleskie writes: Hi, > I'm betting more then a few of use free mail accts to keep this separate > from our work mail. As a positive side effect there are fewer "Out of Office replies" when people use different accounts for "normal" work mail and mailing lists. > If your really having that much issue, config your mail server to drop > it yourself or unsub.... Or use a decent mail client which allows scoring and / or kill files. cheers, Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From jolsen at devry.com Wed Mar 31 09:05:10 2010 From: jolsen at devry.com (Olsen, Jason) Date: Wed, 31 Mar 2010 09:05:10 -0500 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <63AF18E6CB3D3A47A965A11168C9736F021495AA@MAIL3P.dvuadmin.net> > From: Steve Bertrand [mailto:steve at ibctech.ca] > Sent: Tuesday, March 30, 2010 10:15 PM > Subject: Finding content in your job title > > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, > since 2001), and can't necessarily prove my worth. > > How does the ops community feel about using this designation? Is it > intrusive or offensive to those who hold real engineering degrees? I'm > > Instead of acting like I'm trying to sell myself out, I'll leave out > what I actually do and ask those who sig themselves with 'network > engineer' what they do day-to-day to acquire that title, and if they > feel comfortable with having it. I have "Senior Network Engineer" as my title. I have an undergraduate degree in networked communications and management. When working some days or on some projects, like when I'm laying out a whole new datacenter for $EMPLOYER, I feel that I'm filling the role admirably. Other days, when I'm simply pushing paper or "stamping license plates" (small, repetitive tasks of little import) I don't feel that I really deserve the title. But then, if I had my druthers, I'd put "Chief Bit-mover" on my business card (the CIO's secretary put the kabash on when I tried it, citing something about executives not much liking it when non-officers put "Chief" anything on their cards... ;) ) -JFO From darcy at druid.net Wed Mar 31 09:21:54 2010 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Wed, 31 Mar 2010 10:21:54 -0400 Subject: Finding content in your job title In-Reply-To: <000001cad091$c17fbd50$4401a8c0@jgbpc> References: <000001cad091$c17fbd50$4401a8c0@jgbpc> Message-ID: <20100331102154.47834ce2.darcy@druid.net> On Wed, 31 Mar 2010 01:19:26 -0400 "Joe" wrote: > short the last business card I handed out simply had the title MIS Dept. Its Heh. Reminds me of the place I worked where the least knowledgeable, least experienced and least liked person was put in charge of MIS. If anyone had actually liked the guy they would have explained why signing all his emails as "MIS Manager" was a bad idea. Too funny. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From wavetossed at googlemail.com Wed Mar 31 09:46:29 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 31 Mar 2010 14:46:29 +0000 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, since > 2001), and can't necessarily prove my worth. Be careful where you get the examples to model yourself upon. For instance, you are in Canada and I think it is actually illegal to call yourself and engineer unless you are licenced. And as far as I know there is no licencing available for network engineers. Where I work, there is a distinction between the network designers who typically have CCIE certification, and the network operations roles which may or may not have certifications. The hot shot network guys are called 3rd level support. Speaking as someone who has often interviewed people, I think that job titles are pretty much inconsequential. --Michael Dillon Network Consultant From henry at AegisInfoSys.com Wed Mar 31 09:47:43 2010 From: henry at AegisInfoSys.com (Henry Yen) Date: Wed, 31 Mar 2010 10:47:43 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: ; from Mikael Abrahamsson on Wed, Mar 31, 2010 at 07:41:18AM +0200 References: <4BB2C4B6.6070809@trelane.net> <4BB2CE48.1020404@ibctech.ca> Message-ID: <20100331104743.W25919@AegisInfoSys.com> On Wed, Mar 31, 2010 at 07:41:18AM +0200, Mikael Abrahamsson wrote: > I would much prefer if EVERYBODY used freebie email accounts as opposed to > their corporate ones, as this would make it more likely that they would > quote "correctly" and we would get less silly legal disclaimers and out of > office messages. What's your opinion (if any) about free-mail accounts listed for ARIN/APNIC/RIPE/LACNIC/AFRINIC/KRNIC/TWNIC (RIR) contacts? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From richard.barnes at gmail.com Wed Mar 31 09:54:06 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 31 Mar 2010 10:54:06 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: References: <4BB2C4B6.6070809@trelane.net> Message-ID: +1 On Wed, Mar 31, 2010 at 12:00 AM, jim deleskie wrote: > I'm betting more then a few of use free mail accts to keep this > separate from our work mail. ?If your really having that much issue, > config your mail server to drop it yourself or unsub.... > > Seriously > > -jim ? yes posted from gmail acct. > > On Wed, Mar 31, 2010 at 12:42 AM, Andrew D Kirch wrote: >> Is there anyone here who is legitimate using a freebie webmail account? >> I am proposing that the NANOG administration drop everything originating >> from commonly used webmail providers, and add further RHS filters as >> additional providers are identified as problems. >> >> Andrew >> >> > > From laurens at daemon.be Wed Mar 31 10:26:56 2010 From: laurens at daemon.be (Laurens Vets) Date: Wed, 31 Mar 2010 17:26:56 +0200 Subject: Finding content in your job title In-Reply-To: <4BB2C1DE.1070004@cox.net> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C1DE.1070004@cox.net> Message-ID: <4BB369C0.40309@daemon.be> >> This is perhaps a rather silly question, but one that I'd like to have >> answered. >> >> I'm young in the game, and over the years I've imagined numerous job >> titles that should go on my business card. They went from cool, to >> high-priority, to plain unimaginable. >> >> Now, after 10 years, I reflect back on what I've done, and what I do >> now. To me, if a business is loose-knit with no clear job descriptions >> or titles (ie. too small to have CXO etc), I feel that a business card >> should reflect what one feels is the primary job responsibility, or what >> they do the most (or love the most). >> >> For instance, I like to present myself as a 'network engineer'. I have >> never taken formal education, don't hold any certifications (well, since >> 2001), and can't necessarily prove my worth. >> >> How does the ops community feel about using this designation? Is it >> intrusive or offensive to those who hold real engineering degrees? I'm >> content with 'network manager', given that I still do perform (in my >> sleep) numerous system tasks and have to sometimes deal with front-line >> helpdesk stuff. >> >> Instead of acting like I'm trying to sell myself out, I'll leave out >> what I actually do and ask those who sig themselves with 'network >> engineer' what they do day-to-day to acquire that title, and if they >> feel comfortable with having it. > > > When the University I worked for went all touchy-feely and told us to > pick titles for ourselves I wanted to use "Savant". > > They wouldn't let me, so I tried "Jack Of All Trades". > > Vetoed. > > So I just stayed with the cards I had that said Associate Director for > Telecommunications and Computers. > > Which is about as void of meaning then and now as anything I have ever > heard of. I actually held the title "Super Security Engineer" at my previous company according to my business cards. Now that I think of it, I need new business cards, any ideas? :) From dts at senie.com Wed Mar 31 10:46:34 2010 From: dts at senie.com (Daniel Senie) Date: Wed, 31 Mar 2010 11:46:34 -0400 Subject: Time for a lounge mailing list Message-ID: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> It's been clear for a very long time that the NANOG crowd likes to socialize. At NANOGs, social settings are where connections are made, beers consumed, sometimes scuba dives shared or other local attractions explored. It is certainly a good thing, and fosters much useful discussion among peers who become friends. That said, the nanog at nanog.org mailing list often is overrun with non-operational discussion. Certainly there are some good examples today, such as job titles, or arguing about the best way to rid the list of a troll. Creation of a second mailing list to handle non-operational, social traffic for the nanog crowd would be one way to keep the main list on topic. Might even boost productivity, as folks could more easily defer reading and responding to the non-operational stuff until their off-hours. So how about it? lounge at nanog.org? offtopic at nanog.org? From bicknell at ufp.org Wed Mar 31 10:47:52 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 31 Mar 2010 08:47:52 -0700 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <20100331154752.GA49597@ussenterprise.ufp.org> In a message written on Tue, Mar 30, 2010 at 11:14:52PM -0400, Steve Bertrand wrote: > Now, after 10 years, I reflect back on what I've done, and what I do > now. To me, if a business is loose-knit with no clear job descriptions > or titles (ie. too small to have CXO etc), I feel that a business card > should reflect what one feels is the primary job responsibility, or what > they do the most (or love the most). A /business card/ should reflect how you want those outside of your company to classify you. For instance, you may be Head Coder, Operations Manager, and Chief Kitchen Cleaner, but when you go to Nanog you hand out cards that say "Peering Coordinator" because you want people to know to e-mail you for peering. Having them know you are Chief Kitchen Cleaner is of no value. This is also why many people have more than one set of business cards. The NANOG "Peering Coordinator" may be the IETF "Protocol Architect". This is also different from your "offical title", that is what appears on your HR paperwork. That is relevant to your resume/cv, because if someone calls to check and see if you really were "CTO", it's HR who is going to say yes or no. > How does the ops community feel about using this designation? Is it > intrusive or offensive to those who hold real engineering degrees? I'm > content with 'network manager', given that I still do perform (in my > sleep) numerous system tasks and have to sometimes deal with front-line > helpdesk stuff. "Engineer" by it self doesn't imply certification to me. Those with Engineering certifications are typically a "P.E.", which just like M.D. or PhD mean something specific. "Civil Engineer" implies nothing to me, "Bob Smith, P.E." does. Thus I am ok with someone calling themselves a "Network Engineer". You can then also be "Bob Smith, CCIE" or "Bob Smith, JNCIE" if you feel you need to be "certified" in some way. -- 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 lists at internetpolicyagency.com Wed Mar 31 10:49:45 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Wed, 31 Mar 2010 16:49:45 +0100 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: In article , Michael Dillon writes >Be careful where you get the examples to model yourself upon. >For instance, you are in Canada and I think it is actually illegal >to call yourself and engineer unless you are licenced. And as >far as I know there is no licencing available for network engineers. Licenced by the Canadian authorities? Here in the UK we have "Institutes", such as IEEE, where membership can convey some authenticity to the title of 'Chartered Engineer'. But anyone can be a normal engineer (even people like me with a Masters in Engineering, but never bothered to apply to IEEE). -- Roland Perry From mylists at battleop.com Wed Mar 31 10:55:10 2010 From: mylists at battleop.com (Richey) Date: Wed, 31 Mar 2010 11:55:10 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: References: <4BB2C4B6.6070809@trelane.net> <4BB2CE48.1020404@ibctech.ca> <4BB2E2B7.3040500@rollernet.us> Message-ID: <018a01cad0ea$8af5f520$a0e1df60$@battleop.com> My employer has an unwritten policy that says we're free to post what we want where we want as long as we do not make it obvious who our employer is. I.E. don't post from the company email accounts. I use both personal domains and freebie accounts to comply with this request. Richey -----Original Message----- From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] Sent: Wednesday, March 31, 2010 2:01 AM To: Seth Mattinen Cc: nanog at nanog.org Subject: Re: Posting from freebie E-mail Accounts On Tue, 30 Mar 2010, Seth Mattinen wrote: > That's an exact opposite of silly from the OP's request; my "corporate > account" works just fine. Well, your corporate account seems to involve less silly (exchange/lotus notes) than most. -- Mikael Abrahamsson email: swmike at swm.pp.se From Valdis.Kletnieks at vt.edu Wed Mar 31 10:55:31 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 31 Mar 2010 11:55:31 -0400 Subject: Finding content in your job title In-Reply-To: Your message of "Tue, 30 Mar 2010 23:14:52 EDT." <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <7627.1270050931@localhost> On Tue, 30 Mar 2010 23:14:52 EDT, Steve Bertrand said: > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, since > 2001), and can't necessarily prove my worth. Our payroll system was overhauled a few years ago, and it now claims I'm an "IT Spec III", but provides for an alternate "working title". I couldn't get "Utility Infielder" on my business card, so I kept the business cards that still say "Computer Systems Senior Engineer". I don't go through cards very fast. ;) One of my cohorts prefers the term "Mutagen". :) I've had the occasional whinge from pedants that complain that 'Engineer' is a controlled term and the state should take action on my use of it, and I point out to them (a) not in my field, yet, and (b) it was the Commonwealth of Virginia that *gave* me the title so they should feel free to take it up with the guys in Richmond. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From streiner at cluebyfour.org Wed Mar 31 10:57:18 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 31 Mar 2010 11:57:18 -0400 (EDT) Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: On Tue, 30 Mar 2010, Steve Bertrand wrote: > I'm young in the game, and over the years I've imagined numerous job > titles that should go on my business card. They went from cool, to > high-priority, to plain unimaginable. > > Now, after 10 years, I reflect back on what I've done, and what I do > now. To me, if a business is loose-knit with no clear job descriptions > or titles (ie. too small to have CXO etc), I feel that a business card > should reflect what one feels is the primary job responsibility, or what > they do the most (or love the most). Smaller shops might be more willing to let people choose their own titles for their business cards. A friend presented himself as "Lord of the Underworld" when he ran his own company. At my previous job, the title on my business card was either "network engineer" or "senior network engineer", and that was pretty accurate, in the sense that most people here would probably agree that the "network engineer" is a pretty vague title that covers many different responsibilities. Bigger companies often put a framework of job classifications and titles in place to simplify HR/administrative items like salary ranges and reporting structures. I currently work at a larger organization where my business card says "network analyst" even though I work in the network engineering group, and my job classification is "systems programmer IV" even though I don't do any systems programming. I don't consider writing the occasional shell/perl/python script to be systems programming :) > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, since > 2001), and can't necessarily prove my worth. I don't hold any certs at the moment either, but I can prove my worth to an organization through my work experience and business knowledge. The "are certs worth it" horse has been pretty well beaten to death several times here and on other forums. > How does the ops community feel about using this designation? Is it > intrusive or offensive to those who hold real engineering degrees? I'm > content with 'network manager', given that I still do perform (in my > sleep) numerous system tasks and have to sometimes deal with front-line > helpdesk stuff. "Engineering" implies different things to different people. I don't worry about offending a degreed engineer any more than I worry about offending someone who drives a train. I had a boss at a previous job herd all of the systems and network engineers in the conference room and give us the "YOU ARE NOT ENGINEERS BECAUSE YOU DO NOT HAVE AN ENGINEERING DEGREE" browbeating after some sort of an outage. He didn't last very long :) jms From tme at americafree.tv Wed Mar 31 11:06:23 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 31 Mar 2010 12:06:23 -0400 Subject: Time for a lounge mailing list In-Reply-To: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> Message-ID: On Mar 31, 2010, at 11:46 AM, Daniel Senie wrote: > It's been clear for a very long time that the NANOG crowd likes to > socialize. At NANOGs, social settings are where connections are > made, beers consumed, sometimes scuba dives shared or other local > attractions explored. It is certainly a good thing, and fosters much > useful discussion among peers who become friends. > > That said, the nanog at nanog.org mailing list often is overrun with > non-operational discussion. Certainly there are some good examples > today, such as job titles, or arguing about the best way to rid the > list of a troll. > > Creation of a second mailing list to handle non-operational, social > traffic for the nanog crowd would be one way to keep the main list > on topic. Might even boost productivity, as folks could more easily > defer reading and responding to the non-operational stuff until > their off-hours. > > So how about it? lounge at nanog.org? offtopic at nanog.org? > > The IETF has found an "attendees" list useful. Marshall > > From jim at reptiles.org Wed Mar 31 11:12:46 2010 From: jim at reptiles.org (Jim Mercer) Date: Wed, 31 Mar 2010 12:12:46 -0400 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C0D9.4020607@ibctech.ca> Message-ID: <20100331161246.GA31436@reptiles.org> On Tue, Mar 30, 2010 at 10:34:58PM -0500, Jorge Amodio wrote: > Ok, let see. In several countries the use of the "title" engineer > applies to people that achieved a certain technical degree, I'm not > sure that applies uniformly but in Latin America using the engineer > title without having achieved that degree is illegal. when i worked for LSUC, the equivilent of a state bar association, i think, i was asked to dream up a new title for my role, and asked for "Network Architect". it was rejected for the reason that "it bestowes upon you a professional designation for which you are not qualified." i think my title ended up being "Systems and Network Engineering Manager". -- Jim Mercer jim at reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From marla.azinger at frontiercorp.com Wed Mar 31 11:13:39 2010 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 31 Mar 2010 12:13:39 -0400 Subject: Time for a lounge mailing list In-Reply-To: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F10485300C1C1@ROCH-EXCH1.corp.pvt> I'm sending this to the proper request email. This is a decent idea that I support. NANOG Crew please read the below email and consider establishing a separate "socializing" email address so operational topics only exist on the current email list. Cheers Marla Azinger -----Original Message----- From: Daniel Senie [mailto:dts at senie.com] Sent: Wednesday, March 31, 2010 8:47 AM To: NANOG list Subject: Time for a lounge mailing list It's been clear for a very long time that the NANOG crowd likes to socialize. At NANOGs, social settings are where connections are made, beers consumed, sometimes scuba dives shared or other local attractions explored. It is certainly a good thing, and fosters much useful discussion among peers who become friends. That said, the nanog at nanog.org mailing list often is overrun with non-operational discussion. Certainly there are some good examples today, such as job titles, or arguing about the best way to rid the list of a troll. Creation of a second mailing list to handle non-operational, social traffic for the nanog crowd would be one way to keep the main list on topic. Might even boost productivity, as folks could more easily defer reading and responding to the non-operational stuff until their off-hours. So how about it? lounge at nanog.org? offtopic at nanog.org? From Valdis.Kletnieks at vt.edu Wed Mar 31 11:14:14 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 31 Mar 2010 12:14:14 -0400 Subject: Time for a lounge mailing list In-Reply-To: Your message of "Wed, 31 Mar 2010 11:46:34 EDT." <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> Message-ID: <8490.1270052054@localhost> On Wed, 31 Mar 2010 11:46:34 EDT, Daniel Senie said: > So how about it? lounge at nanog.org? offtopic at nanog.org? snark at nanog.org. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From leigh.porter at ukbroadband.com Wed Mar 31 11:14:52 2010 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 31 Mar 2010 17:14:52 +0100 Subject: Posting from freebie E-mail Accounts In-Reply-To: <018a01cad0ea$8af5f520$a0e1df60$@battleop.com> References: <4BB2C4B6.6070809@trelane.net> <4BB2CE48.1020404@ibctech.ca> <4BB2E2B7.3040500@rollernet.us> <018a01cad0ea$8af5f520$a0e1df60$@battleop.com> Message-ID: <4BB374FC.1010100@ukbroadband.com> Until somebody does 'view headers' and sees /X/-/Sender/-/IP / and oh look, it was sent from 'foobarco' ;-) FAIL -- Leigh On 31/03/10 16:55, Richey wrote: > My employer has an unwritten policy that says we're free to post what we > want where we want as long as we do not make it obvious who our employer is. > I.E. don't post from the company email accounts. I use both personal > domains and freebie accounts to comply with this request. > > Richey > > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] > Sent: Wednesday, March 31, 2010 2:01 AM > To: Seth Mattinen > Cc: nanog at nanog.org > Subject: Re: Posting from freebie E-mail Accounts > > On Tue, 30 Mar 2010, Seth Mattinen wrote: > > >> That's an exact opposite of silly from the OP's request; my "corporate >> account" works just fine. >> > Well, your corporate account seems to involve less silly (exchange/lotus > notes) than most. > > From brandon.galbraith at gmail.com Wed Mar 31 11:19:02 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 31 Mar 2010 11:19:02 -0500 Subject: Time for a lounge mailing list In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F10485300C1C1@ROCH-EXCH1.corp.pvt> References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> <2E2FECEBAE57CC4BAACDE67638305F10485300C1C1@ROCH-EXCH1.corp.pvt> Message-ID: nanog-chat at nanog.org? On Wed, Mar 31, 2010 at 11:13 AM, Azinger, Marla < marla.azinger at frontiercorp.com> wrote: > I'm sending this to the proper request email. > > This is a decent idea that I support. > > NANOG Crew please read the below email and consider establishing a separate > "socializing" email address so operational topics only exist on the current > email list. > > Cheers > Marla Azinger > > -----Original Message----- > From: Daniel Senie [mailto:dts at senie.com] > Sent: Wednesday, March 31, 2010 8:47 AM > To: NANOG list > Subject: Time for a lounge mailing list > > It's been clear for a very long time that the NANOG crowd likes to > socialize. At NANOGs, social settings are where connections are made, beers > consumed, sometimes scuba dives shared or other local attractions explored. > It is certainly a good thing, and fosters much useful discussion among peers > who become friends. > > That said, the nanog at nanog.org mailing list often is overrun with > non-operational discussion. Certainly there are some good examples today, > such as job titles, or arguing about the best way to rid the list of a > troll. > > Creation of a second mailing list to handle non-operational, social traffic > for the nanog crowd would be one way to keep the main list on topic. Might > even boost productivity, as folks could more easily defer reading and > responding to the non-operational stuff until their off-hours. > > So how about it? lounge at nanog.org? offtopic at nanog.org? > > > > > -- Brandon Galbraith Voice: 630.492.0464 From darcy at druid.net Wed Mar 31 11:24:16 2010 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Wed, 31 Mar 2010 12:24:16 -0400 Subject: Finding content in your job title In-Reply-To: <20100331161246.GA31436@reptiles.org> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C0D9.4020607@ibctech.ca> <20100331161246.GA31436@reptiles.org> Message-ID: <20100331122416.a239d3c2.darcy@druid.net> On Wed, 31 Mar 2010 12:12:46 -0400 Jim Mercer wrote: > i think my title ended up being "Systems and Network Engineering Manager". So you were the SANE Manager? -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From jack at crepinc.com Wed Mar 31 11:25:13 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Wed, 31 Mar 2010 12:25:13 -0400 Subject: Time for a lounge mailing list In-Reply-To: References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> <2E2FECEBAE57CC4BAACDE67638305F10485300C1C1@ROCH-EXCH1.corp.pvt> Message-ID: lounge is good - off topic seems to say that *no* operational content will be discussed, whereas with "lounge" we can simply move long threads most people don't care about over there (ie: trolling, TDM, etc) -Jack Carrozzo On Wed, Mar 31, 2010 at 12:19 PM, Brandon Galbraith wrote: > nanog-chat at nanog.org? > > On Wed, Mar 31, 2010 at 11:13 AM, Azinger, Marla < > marla.azinger at frontiercorp.com> wrote: > >> I'm sending this to the proper request email. >> >> This is a decent idea that I support. >> >> NANOG Crew please read the below email and consider establishing a separate >> "socializing" email address so operational topics only exist on the current >> email list. >> >> Cheers >> Marla Azinger >> >> -----Original Message----- >> From: Daniel Senie [mailto:dts at senie.com] >> Sent: Wednesday, March 31, 2010 8:47 AM >> To: NANOG list >> Subject: Time for a lounge mailing list >> >> It's been clear for a very long time that the NANOG crowd likes to >> socialize. At NANOGs, social settings are where connections are made, beers >> consumed, sometimes scuba dives shared or other local attractions explored. >> It is certainly a good thing, and fosters much useful discussion among peers >> who become friends. >> >> That said, the nanog at nanog.org mailing list often is overrun with >> non-operational discussion. Certainly there are some good examples today, >> such as job titles, or arguing about the best way to rid the list of a >> troll. >> >> Creation of a second mailing list to handle non-operational, social traffic >> for the nanog crowd would be one way to keep the main list on topic. Might >> even boost productivity, as folks could more easily defer reading and >> responding to the non-operational stuff until their off-hours. >> >> So how about it? lounge at nanog.org? offtopic at nanog.org? >> >> >> >> >> > > > -- > Brandon Galbraith > Voice: 630.492.0464 > From hutton at sdsc.edu Wed Mar 31 11:25:56 2010 From: hutton at sdsc.edu (Tom Hutton) Date: Wed, 31 Mar 2010 09:25:56 -0700 Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB2C4B6.6070809@trelane.net> References: <4BB2C4B6.6070809@trelane.net> Message-ID: I also use a "freebie" webmail account for nanog mail. I would be opposed to this. Tom On Tue, Mar 30, 2010 at 8:42 PM, Andrew D Kirch wrote: > Is there anyone here who is legitimate using a freebie webmail account? > I am proposing that the NANOG administration drop everything originating > from commonly used webmail providers, and add further RHS filters as > additional providers are identified as problems. > > Andrew > > From cmorris at cs.odu.edu Wed Mar 31 11:31:33 2010 From: cmorris at cs.odu.edu (Charles Morris) Date: Wed, 31 Mar 2010 12:31:33 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: References: <4BB2C4B6.6070809@trelane.net> Message-ID: -1 On Wed, Mar 31, 2010 at 10:54 AM, Richard Barnes wrote: > +1 > > > > > On Wed, Mar 31, 2010 at 12:00 AM, jim deleskie wrote: >> I'm betting more then a few of use free mail accts to keep this >> separate from our work mail. ?If your really having that much issue, >> config your mail server to drop it yourself or unsub.... >> >> Seriously >> >> -jim ? yes posted from gmail acct. >> >> On Wed, Mar 31, 2010 at 12:42 AM, Andrew D Kirch wrote: >>> Is there anyone here who is legitimate using a freebie webmail account? >>> I am proposing that the NANOG administration drop everything originating >>> from commonly used webmail providers, and add further RHS filters as >>> additional providers are identified as problems. >>> >>> Andrew >>> >>> >> >> > > From bmanning at vacation.karoshi.com Wed Mar 31 11:42:02 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 31 Mar 2010 16:42:02 +0000 Subject: Posting from freebie E-mail Accounts In-Reply-To: References: <4BB2C4B6.6070809@trelane.net> Message-ID: <20100331164202.GA8573@vacation.karoshi.com.> on the other hand, such a move would trim a huge number of list members, which might refocus the list to "North America". --bill On Wed, Mar 31, 2010 at 09:25:56AM -0700, Tom Hutton wrote: > I also use a "freebie" webmail account for nanog mail. I would be > opposed to this. > > Tom > > > On Tue, Mar 30, 2010 at 8:42 PM, Andrew D Kirch wrote: > > Is there anyone here who is legitimate using a freebie webmail account? > > I am proposing that the NANOG administration drop everything originating > > from commonly used webmail providers, and add further RHS filters as > > additional providers are identified as problems. > > > > Andrew > > > > From DStaal at usa.net Wed Mar 31 11:43:23 2010 From: DStaal at usa.net (Daniel Staal) Date: Wed, 31 Mar 2010 12:43:23 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: <4BB374FC.1010100@ukbroadband.com> References: <4BB2C4B6.6070809@trelane.net> <4BB2CE48.1020404@ibctech.ca> <4BB2E2B7.3040500@rollernet.us> <018a01cad0ea$8af5f520$a0e1df60$@battleop.com> <4BB374FC.1010100@ukbroadband.com> Message-ID: <5d84173d4e8ab274dd0bef75d79a3f7c.squirrel@www.magehandbook.com> On Wed, March 31, 2010 12:14 pm, Leigh Porter wrote: > > Until somebody does 'view headers' and sees > > /X/-/Sender/-/IP > / > and oh look, it was sent from 'foobarco' ;-) That depends on how they are sending it, of course. Webmail usually just has the IP of the host, and I imagine quite a few others around here have their own personal servers that could also be used for this, one way or another. Then of course there are things like Blackberries and iPhones that can send email themselves, and are likely to have IP addresses that are linked to something besides their current location. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From wavetossed at googlemail.com Wed Mar 31 11:44:18 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 31 Mar 2010 16:44:18 +0000 Subject: Time for a lounge mailing list In-Reply-To: References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> <2E2FECEBAE57CC4BAACDE67638305F10485300C1C1@ROCH-EXCH1.corp.pvt> Message-ID: > lounge is good - off topic seems to say that *no* operational content > will be discussed, whereas with "lounge" we can simply move long > threads most people don't care about over there (ie: trolling, TDM, > etc) What is the point of NANOG hosting such a thing. If people want to socialize then let them set up a profile on multiply.com and add NANOG as a friend. http://nanog.multiply.com/ Then we can just remind people to take the non technical discussions to the social networking site. --Michael Dillon From kris.foster at gmail.com Wed Mar 31 11:50:14 2010 From: kris.foster at gmail.com (kris foster) Date: Wed, 31 Mar 2010 09:50:14 -0700 Subject: Time for a lounge mailing list In-Reply-To: References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> <2E2FECEBAE57CC4BAACDE67638305F10485300C1C1@ROCH-EXCH1.corp.pvt> Message-ID: Everyone- this conversation should take place at nanog-futures at nanog.org. That list is for meta-discussions like this. Thanks! Kris On Mar 31, 2010, at 9:25 AM, Jack Carrozzo wrote: > lounge is good - off topic seems to say that *no* operational content > will be discussed, whereas with "lounge" we can simply move long > threads most people don't care about over there (ie: trolling, TDM, > etc) > > -Jack Carrozzo > > On Wed, Mar 31, 2010 at 12:19 PM, Brandon Galbraith > wrote: >> nanog-chat at nanog.org? >> >> On Wed, Mar 31, 2010 at 11:13 AM, Azinger, Marla < >> marla.azinger at frontiercorp.com> wrote: >> >>> I'm sending this to the proper request email. >>> >>> This is a decent idea that I support. >>> >>> NANOG Crew please read the below email and consider establishing a separate >>> "socializing" email address so operational topics only exist on the current >>> email list. >>> >>> Cheers >>> Marla Azinger >>> >>> -----Original Message----- >>> From: Daniel Senie [mailto:dts at senie.com] >>> Sent: Wednesday, March 31, 2010 8:47 AM >>> To: NANOG list >>> Subject: Time for a lounge mailing list >>> >>> It's been clear for a very long time that the NANOG crowd likes to >>> socialize. At NANOGs, social settings are where connections are made, beers >>> consumed, sometimes scuba dives shared or other local attractions explored. >>> It is certainly a good thing, and fosters much useful discussion among peers >>> who become friends. >>> >>> That said, the nanog at nanog.org mailing list often is overrun with >>> non-operational discussion. Certainly there are some good examples today, >>> such as job titles, or arguing about the best way to rid the list of a >>> troll. >>> >>> Creation of a second mailing list to handle non-operational, social traffic >>> for the nanog crowd would be one way to keep the main list on topic. Might >>> even boost productivity, as folks could more easily defer reading and >>> responding to the non-operational stuff until their off-hours. >>> >>> So how about it? lounge at nanog.org? offtopic at nanog.org? >>> >>> >>> >>> >>> >> >> >> -- >> Brandon Galbraith >> Voice: 630.492.0464 >> > From joly at punkcast.com Wed Mar 31 11:52:00 2010 From: joly at punkcast.com (Joly MacFie) Date: Wed, 31 Mar 2010 12:52:00 -0400 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> Message-ID: Why isn't this on YouTube? j On Tue, Mar 30, 2010 at 8:15 PM, David Conrad wrote: > Well, actually, ICANN was in Geneva specifically for the meeting, but we weren't allowed into the room. ?Quite annoying, actually. > > Regards, > -drc -- --------------------------------------------------------------- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From robert at timetraveller.org Wed Mar 31 12:00:30 2010 From: robert at timetraveller.org (Robert Brockway) Date: Wed, 31 Mar 2010 13:00:30 -0400 (EDT) Subject: Time for a lounge mailing list In-Reply-To: References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> <2E2FECEBAE57CC4BAACDE67638305F10485300C1C1@ROCH-EXCH1.corp.pvt> Message-ID: On Wed, 31 Mar 2010, Michael Dillon wrote: > Then we can just remind people to take the non technical > discussions to the social networking site. I find that mailing lists flow much better than the discussions on social networking sites. The tools available to manage messages on forums and social networking sites are typically very primitive. There's a reason that the lions's share of technical discussions occur on mailing lists and over IRC (esp in the OSS world). nanog-chat or nanog-lounge lists sound great to me. Cheers, Rob -- Email: robert at timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com Open Source: The revolution that silently changed the world From nanog at armorfirewall.com Wed Mar 31 12:32:47 2010 From: nanog at armorfirewall.com (George Imburgia) Date: Wed, 31 Mar 2010 12:32:47 -0500 (EST) Subject: Finding content in your job title In-Reply-To: <7627.1270050931@localhost> References: <4BB2BE2C.9000901@ibctech.ca> <7627.1270050931@localhost> Message-ID: On Wed, 31 Mar 2010, Valdis.Kletnieks at vt.edu wrote: > I've had the occasional whinge from pedants that complain that 'Engineer' is a > controlled term and the state should take action on my use of it, and I point > out to them (a) not in my field, yet, and (b) it was the Commonwealth of > Virginia that *gave* me the title so they should feel free to take it up > with the guys in Richmond. Good point. A title assigned by a government agency is probably most appropriate. Cheers, George Person of Interest From LarrySheldon at cox.net Wed Mar 31 12:03:28 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 31 Mar 2010 12:03:28 -0500 Subject: Time for a lounge mailing list In-Reply-To: References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> <2E2FECEBAE57CC4BAACDE67638305F10485300C1C1@ROCH-EXCH1.corp.pvt> Message-ID: <4BB38060.6030400@cox.net> On 3/31/2010 11:50, kris foster wrote: > Everyone- this conversation should take place at > nanog-futures at nanog.org. That list is for meta-discussions like > this. The irony is overwhelming. From jmamodio at gmail.com Wed Mar 31 12:10:38 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 31 Mar 2010 12:10:38 -0500 Subject: Time for a lounge mailing list In-Reply-To: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> Message-ID: Interesting idea. Then we'll start posting at nanog that there must be some operational problem because nobody is posting on the other list. Jorge From jmamodio at gmail.com Wed Mar 31 12:18:09 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 31 Mar 2010 12:18:09 -0500 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> <7627.1270050931@localhost> Message-ID: Perhaps the appropriate approach if the title is internet related is to call for a BoF at IETF, setup a WG to work on a standards titles draft, get it published as an RFC, vest the authority on IANA and start a PDP at ICANN to determine who can obtain and ware the title and how much has to pay for it. Now thinking it through, this may be something we can ask the ITU to do instead of trying to get into the internet standards and non-governance of the internet, I'm sure they will probably after a couple of years will come out with the pink book of titles recommendations that will be uniformly accepted and implemented around the world including developing countries. Need a beer Jorge On Wed, Mar 31, 2010 at 12:32 PM, George Imburgia wrote: > > On Wed, 31 Mar 2010, Valdis.Kletnieks at vt.edu wrote: > >> I've had the occasional whinge from pedants that complain that 'Engineer' >> is a >> controlled term and the state should take action on my use of it, and I >> point >> out to them (a) not in my field, yet, and (b) it was the Commonwealth of >> Virginia that *gave* me the title so they should feel free to take it up >> with the guys in Richmond. > > Good point. A title assigned by a government agency is probably most > appropriate. > > Cheers, > George > Person of Interest From patrick at ianai.net Wed Mar 31 13:04:40 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 31 Mar 2010 14:04:40 -0400 Subject: Posting from freebie E-mail Accounts In-Reply-To: <5d84173d4e8ab274dd0bef75d79a3f7c.squirrel@www.magehandbook.com> References: <4BB2C4B6.6070809@trelane.net> <4BB2CE48.1020404@ibctech.ca> <4BB2E2B7.3040500@rollernet.us> <018a01cad0ea$8af5f520$a0e1df60$@battleop.com> <4BB374FC.1010100@ukbroadband.com> <5d84173d4e8ab274dd0bef75d79a3f7c.squirrel@www.magehandbook.com> Message-ID: <2696CAA5-CFF7-47F6-A512-2F5B0D0C46F1@ianai.net> On Mar 31, 2010, at 12:43 PM, Daniel Staal wrote: > On Wed, March 31, 2010 12:14 pm, Leigh Porter wrote: >> >> Until somebody does 'view headers' and sees >> >> /X/-/Sender/-/IP >> / >> and oh look, it was sent from 'foobarco' ;-) > > That depends on how they are sending it, of course. Webmail usually just > has the IP of the host, and I imagine quite a few others around here have > their own personal servers that could also be used for this, one way or > another. GMail doesn't even add that header, so you don't have to worry where you are browsing from. < cue thread about Google's arrogance that they know better how to stop spam than anyone else; cue thread about Google's complete inability to stop spam even close to as well as many others; cue thread about Google's hypocrisy about adding X-Sender-IP on IMAP injected mail, but not through web mail; cue thread about people talking about e-mail / spam on NANOG; cue thread about moving the whole thing to nanog-futures; cue thread about .... > -- TTFN, patrick > Then of course there are things like Blackberries and iPhones that can > send email themselves, and are likely to have IP addresses that are linked > to something besides their current location. > > Daniel T. Staal > > --------------------------------------------------------------- > This email copyright the author. Unless otherwise noted, you > are expressly allowed to retransmit, quote, or otherwise use > the contents for non-commercial purposes. This copyright will > expire 5 years after the author's death, or in 30 years, > whichever is longer, unless such a period is in excess of > local copyright law. > --------------------------------------------------------------- > > From robert at timetraveller.org Wed Mar 31 13:11:30 2010 From: robert at timetraveller.org (Robert Brockway) Date: Wed, 31 Mar 2010 14:11:30 -0400 (EDT) Subject: Time for a lounge mailing list In-Reply-To: References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> Message-ID: On Wed, 31 Mar 2010, Jorge Amodio wrote: > Interesting idea. Then we'll start posting at nanog that there must be > some operational problem because nobody is posting on the other list. -lounge and -chat lists are common in many technical organisations I'm a member of. They are generally used the way they are intended to be used. Tech types tend to be a lot better than an average person at following list rules, in my experience. Cheers, Rob -- Email: robert at timetraveller.org IRC: Solver Web: http://www.practicalsysadmin.com Open Source: The revolution that silently changed the world From pbosworth at gmail.com Wed Mar 31 13:36:35 2010 From: pbosworth at gmail.com (Paul Bosworth) Date: Wed, 31 Mar 2010 13:36:35 -0500 Subject: Time for a lounge mailing list In-Reply-To: References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> Message-ID: I support the creation of a "lounge" list as well. Often times people posit ideas or concepts on the NANOG list that may not directly fall under the requirements of the list. A "lounge" type list would be a great catch-all and could take some of the perceived off-topic discussion to another list. In that case, if you don't like the volume of "non NANOG" business you can just unsubscribe. It cleans up this list and I feel it would probably strengthen this community as bit as well. > > Just my $.02 -- Paul H Bosworth GCFW, CCNP, CCIP, CCDP From mvh at hosteurope.de Wed Mar 31 13:59:26 2010 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Wed, 31 Mar 2010 20:59:26 +0200 Subject: Time for a lounge mailing list In-Reply-To: <8490.1270052054@localhost> References: <69EB4F4C-0736-4A09-AEFF-71E527595F8D@senie.com> <8490.1270052054@localhost> Message-ID: <4BB39B8E.4020502@hosteurope.de> Am 31.03.10 18:14 schrieb Valdis.Kletnieks at vt.edu: > On Wed, 31 Mar 2010 11:46:34 EDT, Daniel Senie said: > >> So how about it? lounge at nanog.org? offtopic at nanog.org? > > snark at nanog.org. ;) nanog-sec at nanog.org - sec like in "secret", and then make it "mediocre operators only". Seriously, +1 - keep^W let this one become operational again. SCNR, .m -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From jmamodio at gmail.com Wed Mar 31 14:00:53 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 31 Mar 2010 14:00:53 -0500 Subject: New Linksys CPE, IPv6 ? Message-ID: http://newsroom.cisco.com/dlls/2010/prod_033110.html Does anybody know what are the plans for IPv6 support ? Regards Jorge From drc at virtualized.org Wed Mar 31 14:18:00 2010 From: drc at virtualized.org (David Conrad) Date: Wed, 31 Mar 2010 09:18:00 -1000 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> Message-ID: On Mar 31, 2010, at 6:52 AM, Joly MacFie wrote: > On Tue, Mar 30, 2010 at 8:15 PM, David Conrad wrote: >> Well, actually, ICANN was in Geneva specifically for the meeting, but we weren't allowed into the room. Quite annoying, actually. > Why isn't this on YouTube? You'd have to ask the ITU secretariat. I'd note that they do audiocast meetings such as this, however you have to have a "TIES" account to gain access to it. Not sure how one would go about getting a TIES account. Regards, -drc From joly at punkcast.com Wed Mar 31 14:33:57 2010 From: joly at punkcast.com (Joly MacFie) Date: Wed, 31 Mar 2010 15:33:57 -0400 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> Message-ID: I'm talking the ITU refusing ICANN entrance at the door.. On Wed, Mar 31, 2010 at 3:18 PM, David Conrad wrote: > On Mar 31, 2010, at 6:52 AM, Joly MacFie wrote: >> On Tue, Mar 30, 2010 at 8:15 PM, David Conrad wrote: >>> Well, actually, ICANN was in Geneva specifically for the meeting, but we weren't allowed into the room. ?Quite annoying, actually. > >> Why isn't this on YouTube? > > You'd have to ask the ITU secretariat. ?I'd note that they do audiocast meetings such as this, however you have to have a "TIES" account to gain access to it. ?Not sure how one would go about getting a TIES account. > > Regards, > -drc > > -- --------------------------------------------------------------- Joly MacFie 917 442 8665 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From joelja at bogus.com Wed Mar 31 15:07:50 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 31 Mar 2010 13:07:50 -0700 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: Message-ID: <4BB3AB96.8050409@bogus.com> On 03/31/2010 12:00 PM, Jorge Amodio wrote: > http://newsroom.cisco.com/dlls/2010/prod_033110.html > > Does anybody know what are the plans for IPv6 support ? the current wrt610n supports ipv6 I failed to see why a slightly updated and rebranded one would not as well. > Regards > Jorge > From frnkblk at iname.com Wed Mar 31 15:15:02 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Wed, 31 Mar 2010 15:15:02 -0500 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: Message-ID: I reached out to the inside sales of Linksys just as recently as last week, and they wrote me back: We did a little further research to see how we were currently roadmapping RFC3633 and it looks like we have no current router models that will be coming out over the next couple quarters that support it on the consumer side of the house. and later: We will keep tabs with the BU on support and will let you know if we hear anything coming up on the roadmap. Frank -----Original Message----- From: Jorge Amodio [mailto:jmamodio at gmail.com] Sent: Wednesday, March 31, 2010 2:01 PM To: NANOG Subject: New Linksys CPE, IPv6 ? http://newsroom.cisco.com/dlls/2010/prod_033110.html Does anybody know what are the plans for IPv6 support ? Regards Jorge From nick at foobar.org Wed Mar 31 15:16:26 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 31 Mar 2010 21:16:26 +0100 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <4BB3AB96.8050409@bogus.com> References: <4BB3AB96.8050409@bogus.com> Message-ID: <4BB3AD9A.1000603@foobar.org> On 31/03/2010 21:07, Joel Jaeggli wrote: > the current wrt610n supports ipv6 I failed to see why a slightly > updated and rebranded one would not as well. because for low-end CPE devices like this, a tiny change in the model number (e.g. v1->v2) might mean a completely different internal system, with different host CPU, different ethernet controller, etc. You're not in any way guaranteed the same sort of software compatibility when moving from one device version to another, particularly for less well supported features like ipv6. Nick From frnkblk at iname.com Wed Mar 31 15:26:31 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Wed, 31 Mar 2010 15:26:31 -0500 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <4BB3AD9A.1000603@foobar.org> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> Message-ID: I checked the documentation for two models (Linux model and highest-end non-Linux model), and there's no mention of IPv6. Frank -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Wednesday, March 31, 2010 3:16 PM To: Joel Jaeggli Cc: NANOG Subject: Re: New Linksys CPE, IPv6 ? On 31/03/2010 21:07, Joel Jaeggli wrote: > the current wrt610n supports ipv6 I failed to see why a slightly > updated and rebranded one would not as well. because for low-end CPE devices like this, a tiny change in the model number (e.g. v1->v2) might mean a completely different internal system, with different host CPU, different ethernet controller, etc. You're not in any way guaranteed the same sort of software compatibility when moving from one device version to another, particularly for less well supported features like ipv6. Nick From randy at psg.com Wed Mar 31 15:45:03 2010 From: randy at psg.com (Randy Bush) Date: Thu, 01 Apr 2010 05:45:03 +0900 Subject: Posting from freebie E-mail Accounts In-Reply-To: <20100331164202.GA8573@vacation.karoshi.com.> References: <4BB2C4B6.6070809@trelane.net> Message-ID: > on the other hand, such a move would trim a huge number of list > members, which might refocus the list to "North America". From randy at psg.com Wed Mar 31 15:49:00 2010 From: randy at psg.com (Randy Bush) Date: Thu, 01 Apr 2010 05:49:00 +0900 Subject: Finding content in your job title In-Reply-To: <63AF18E6CB3D3A47A965A11168C9736F021495AA@MAIL3P.dvuadmin.net> References: <4BB2BE2C.9000901@ibctech.ca> <63AF18E6CB3D3A47A965A11168C9736F021495AA@MAIL3P.dvuadmin.net> Message-ID: if it was not so long, and if jp biz processes were not so confusing to clueless gaijin, i would ask for "just another bozo on this bus" randy From brunner at nic-naa.net Wed Mar 31 15:51:37 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 31 Mar 2010 16:51:37 -0400 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> Message-ID: <4BB3B5D9.1000304@nic-naa.net> Joly, It is just another 501(c)(3) incorporated in California. Just as the ITU is just another treaty organization. The basis for cooperation has to be mutual interest, not mere assertion of presence, and getting to maybe after a long, and not very cooperative history, isn't necessarily YouTube material. FWIW, CORE was formed at the ITU, and nominally our relationship with the ITU is slightly less awful than ... any other lobbyist or actor in the room when Asst. Sec. Gomez was introduced to the community last Winter. At least, I said so and no one bothered to point out that I was either wrong or an idiot. Both those things could yet happen. Eric From michael.holstein at csuohio.edu Wed Mar 31 15:53:37 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 31 Mar 2010 16:53:37 -0400 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> Message-ID: <4BB3B651.1020607@csuohio.edu> > I checked the documentation for two models (Linux model and highest-end non-Linux model), and there's no mention of IPv6. > If this is a strictly "hardware" discussion, v6 "works" on a variety of models, albeit not with stock firmware. To wit : http://www.dd-wrt.com/wiki/index.php/IPv6 This suggests that Cisco (et.al.) can release an "official" firmware image to support v6 on existing devices whenever they're sufficiently motivated to do so. I'd wager the only reason it hasn't been made GA is to limit the number of "pass-the-buck" support calls that start at $isp and get bounced back saying "we don't support that yet, call whoever makes your router". My $0.02. Cheers, Michael Holstein Cleveland State University From lists at quux.de Wed Mar 31 15:56:13 2010 From: lists at quux.de (Jens Link) Date: Wed, 31 Mar 2010 22:56:13 +0200 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> (Steve Bertrand's message of "Tue\, 30 Mar 2010 23\:14\:52 -0400") References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <87fx3ggqhe.fsf@bowmore.quux.de> Steve Bertrand writes: > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, since > 2001), and can't necessarily prove my worth. Hey, network engineer is good. Some time back someone gave me the title "senior executioner security engineer". They even send a document to a customer with this title. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From joelja at bogus.com Wed Mar 31 16:30:03 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 31 Mar 2010 14:30:03 -0700 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> Message-ID: <4BB3BEDB.2040806@bogus.com> It's not in the wrt610n docs either yet the code was unambiguously in the box, complete with 6to4 that your couldn't shut off. On 03/31/2010 01:26 PM, Frank Bulk - iName.com wrote: > I checked the documentation for two models (Linux model and highest-end non-Linux model), and there's no mention of IPv6. > > Frank > > -----Original Message----- > From: Nick Hilliard [mailto:nick at foobar.org] > Sent: Wednesday, March 31, 2010 3:16 PM > To: Joel Jaeggli > Cc: NANOG > Subject: Re: New Linksys CPE, IPv6 ? > > On 31/03/2010 21:07, Joel Jaeggli wrote: >> the current wrt610n supports ipv6 I failed to see why a slightly >> updated and rebranded one would not as well. > > because for low-end CPE devices like this, a tiny change in the model > number (e.g. v1->v2) might mean a completely different internal system, > with different host CPU, different ethernet controller, etc. You're not in > any way guaranteed the same sort of software compatibility when moving from > one device version to another, particularly for less well supported > features like ipv6. > > Nick > > From frnkblk at iname.com Wed Mar 31 16:51:59 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Wed, 31 Mar 2010 16:51:59 -0500 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <4BB3BEDB.2040806@bogus.com> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3BEDB.2040806@bogus.com> Message-ID: I confirmed with Linksys' PR person that there is no IPv6 -- if someone sees different, please let us know. Frank -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Wednesday, March 31, 2010 4:30 PM To: frnkblk at iname.com Cc: 'Nick Hilliard'; NANOG Subject: Re: New Linksys CPE, IPv6 ? It's not in the wrt610n docs either yet the code was unambiguously in the box, complete with 6to4 that your couldn't shut off. On 03/31/2010 01:26 PM, Frank Bulk - iName.com wrote: > I checked the documentation for two models (Linux model and highest-end non-Linux model), and there's no mention of IPv6. > > Frank > > -----Original Message----- > From: Nick Hilliard [mailto:nick at foobar.org] > Sent: Wednesday, March 31, 2010 3:16 PM > To: Joel Jaeggli > Cc: NANOG > Subject: Re: New Linksys CPE, IPv6 ? > > On 31/03/2010 21:07, Joel Jaeggli wrote: >> the current wrt610n supports ipv6 I failed to see why a slightly >> updated and rebranded one would not as well. > > because for low-end CPE devices like this, a tiny change in the model > number (e.g. v1->v2) might mean a completely different internal system, > with different host CPU, different ethernet controller, etc. You're not in > any way guaranteed the same sort of software compatibility when moving from > one device version to another, particularly for less well supported > features like ipv6. > > Nick > > From oliver.gorwits at oucs.ox.ac.uk Wed Mar 31 17:01:45 2010 From: oliver.gorwits at oucs.ox.ac.uk (Oliver Gorwits) Date: Wed, 31 Mar 2010 23:01:45 +0100 Subject: Finding content in your job title In-Reply-To: References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <4BB3C649.1030908@oucs.ox.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/03/2010 08:32, Andrew Mulholland wrote: > On Wed, Mar 31, 2010 at 3:14 AM, Steve Bertrand wrote: >> I'm young in the game, and over the years I've imagined numerous job >> titles that should go on my business card. They went from cool, to >> high-priority, to plain unimaginable. >> > > My approach is not to put job title on the business cards. Totally agree. After my employer started changing their mind over whether we are programmers, analysts, officers, etc, I just dropped the title from the card. By the time I'm handing the card out, the recipient already knows my status. - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuzxkkACgkQ2NPq7pwWBt4DkACfW5XU4l/bS1wfE/CmoZoL1We2 YgoAoLLPKvYjxfLMYNU2vICzDxef6Emp =7fL+ -----END PGP SIGNATURE----- From jimb at jsbc.cc Wed Mar 31 17:01:47 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Wed, 31 Mar 2010 15:01:47 -0700 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3BEDB.2040806@bogus.com> Message-ID: <4BB3C64B.6060709@jsbc.cc> FWIW, I see no IPv6 options on my WRT610N HW Version 2. I thought maybe there was a new firmware version which added IPv6 capability, but I'm still running the latest. There's no IPv6 options on any menu, including 6to4 options that I can see. May be available under DD-WRT or something similar, although last time I looked this model only had alpha stage support for DD-WRT. - Jim On 3/31/2010 14:51, Frank Bulk - iName.com wrote: > I confirmed with Linksys' PR person that there is no IPv6 -- if someone sees different, please let us know. > > Frank > > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Wednesday, March 31, 2010 4:30 PM > To: frnkblk at iname.com > Cc: 'Nick Hilliard'; NANOG > Subject: Re: New Linksys CPE, IPv6 ? > > It's not in the wrt610n docs either yet the code was unambiguously in > the box, complete with 6to4 that your couldn't shut off. > > On 03/31/2010 01:26 PM, Frank Bulk - iName.com wrote: > >> I checked the documentation for two models (Linux model and highest-end non-Linux model), and there's no mention of IPv6. >> >> Frank >> >> -----Original Message----- >> From: Nick Hilliard [mailto:nick at foobar.org] >> Sent: Wednesday, March 31, 2010 3:16 PM >> To: Joel Jaeggli >> Cc: NANOG >> Subject: Re: New Linksys CPE, IPv6 ? >> >> On 31/03/2010 21:07, Joel Jaeggli wrote: >> >>> the current wrt610n supports ipv6 I failed to see why a slightly >>> updated and rebranded one would not as well. >>> >> because for low-end CPE devices like this, a tiny change in the model >> number (e.g. v1->v2) might mean a completely different internal system, >> with different host CPU, different ethernet controller, etc. You're not in >> any way guaranteed the same sort of software compatibility when moving from >> one device version to another, particularly for less well supported >> features like ipv6. >> >> Nick >> >> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5570 bytes Desc: S/MIME Cryptographic Signature URL: From nick at foobar.org Wed Mar 31 17:03:16 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 31 Mar 2010 23:03:16 +0100 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <4BB3BEDB.2040806@bogus.com> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3BEDB.2040806@bogus.com> Message-ID: <4BB3C6A4.2080803@foobar.org> On 31/03/2010 22:30, Joel Jaeggli wrote: > It's not in the wrt610n docs either yet the code was unambiguously in > the box, complete with 6to4 that your couldn't shut off. I have heard that if you visit the hidden "/system.asp" web page on those devices and unclick the "Vista Premium" button, that this shuts down 6to4. Don't have one of the boxes myself, so I can't test it. I don't know whether to congratulate or feel sorry for Remco van Mook for discovering this. On 31/03/2010 22:51, Frank Bulk - iName.com wrote: > I confirmed with Linksys' PR person that there is no IPv6 -- if someone > sees different, please let us know. Wouldn't be the first time that a PR person's opinion did not intersect with reality - although it may well be the first time in recorded history that a PR person undersold a product. http://www.google.com/search?q=wrt610n+ipv6+%2Bsite%3A.linksys.com Nick From dhc2 at dcrocker.net Wed Mar 31 17:06:54 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Wed, 31 Mar 2010 15:06:54 -0700 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> References: <4BB2BE2C.9000901@ibctech.ca> Message-ID: <4BB3C77E.7040206@dcrocker.net> On 3/30/2010 8:14 PM, Steve Bertrand wrote: > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, since > 2001), and can't necessarily prove my worth. We exchange business cards to help the other person know some things about you that are relevant. The string of text that we call title can tell them something of your responsibilities, knowledge, skills, accomplishments, or the like. It's a short string, so you have to choose carefully. As noted, some words in a title are formal terms of art, with restrictions on their application. "Therapist" requires a license in most states; etc. So you have to balance between benefit to the reader, corporate culture and rules, and legal/formal restrictions. Sometimes, your official company title isn't very helpful for this purpose and sometimes it is. Some companies allow or encourage whimsy; personally I find those usually to tell me that the company is silly, but sometimes it communicates a sense of fresh corporate culture. If you get to choose the text, decide what is most important for others to know about you from that card. Consider it from their perspective, not yours. Assume the card has been passed to a third person who hasn't met you and doesn't get information from the intermediary. Or that the person who got it looks at it 6 months later. Does reading the text for title tell them something that they will find helpful to know? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jfbeam at gmail.com Wed Mar 31 17:07:57 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 31 Mar 2010 18:07:57 -0400 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <4BB3B651.1020607@csuohio.edu> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> Message-ID: On Wed, 31 Mar 2010 16:53:37 -0400, Michael Holstein wrote: > If this is a strictly "hardware" discussion, v6 "works" on a variety of > models, albeit not with stock firmware. ... > This suggests that Cisco (et.al.) can release an "official" firmware > image to support v6 on existing devices whenever they're sufficiently > motivated to do so. Yes and no. Many of the uber-cheap models simply don't have the processing power or memory to do IPv6 well. (Some would say they don't do IPv4 well. I'm one of them.) Pure here's-a-packet-here's-where-it-goes switching can be done in almost any model as long as the v6 stack doesn't make the image too large to fit in the 4K rom. Doing anything remotely complicated, like tunneling and stateful firewalling, makes the image much too large and eats way too much ram. (This is also way many of the cheap models do not run linux and generally cannot run a usable linux image.) On the more expensive, higher end models, yes, they can run rather complex IPv4/6 stacks quite well. However, the bottom is that there is simply little to no consumer demand for IPv6 support -- esp. in North America (read: US) where most of these things are sold. --Ricky From ncnet at sbcglobal.net Wed Mar 31 17:22:07 2010 From: ncnet at sbcglobal.net (Larry Stites) Date: Wed, 31 Mar 2010 15:22:07 -0700 Subject: Finding content in your job title In-Reply-To: <4BB2BE2C.9000901@ibctech.ca> Message-ID: Finding content in my job title... hmm maybe I can change mine to 'Gopher'. (Go-pher, Go Fer, as in Going For, to get, fetch...) Speak to me in 'engineer-ese' : (functionality) : I interpret and 'go for' the hardware that fills the requirement. Come to think of it maybe that's a good name for a corporation; Gopher IT. (Ducks back down hole avoiding various projectiles) ~.~ Best regards, Larry E. Stites Critical Asset Manager Northern California Networks, Inc. (Gopher IT, Inc?) .............................. on 3/30/10 8:14 PM, Steve Bertrand wrote: > Hi all, > > This is perhaps a rather silly question, but one that I'd like to have > answered. > > I'm young in the game, and over the years I've imagined numerous job > titles that should go on my business card. They went from cool, to > high-priority, to plain unimaginable. > > Now, after 10 years, I reflect back on what I've done, and what I do > now. To me, if a business is loose-knit with no clear job descriptions > or titles (ie. too small to have CXO etc), I feel that a business card > should reflect what one feels is the primary job responsibility, or what > they do the most (or love the most). > > For instance, I like to present myself as a 'network engineer'. I have > never taken formal education, don't hold any certifications (well, since > 2001), and can't necessarily prove my worth. > > How does the ops community feel about using this designation? Is it > intrusive or offensive to those who hold real engineering degrees? I'm > content with 'network manager', given that I still do perform (in my > sleep) numerous system tasks and have to sometimes deal with front-line > helpdesk stuff. > > Instead of acting like I'm trying to sell myself out, I'll leave out > what I actually do and ask those who sig themselves with 'network > engineer' what they do day-to-day to acquire that title, and if they > feel comfortable with having it. > > Steve > > > > > > ~.~ Best regards, Larry E. Stites Acquisitions and Sales Northern California Networks, Inc. CA LIC#04 SR KH 100-484111 Nevada City, Calif. 95959 cell 530 320 4194 ~ land 530 265 2588 From mike at mtcc.com Wed Mar 31 17:25:30 2010 From: mike at mtcc.com (Michael Thomas) Date: Wed, 31 Mar 2010 15:25:30 -0700 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> Message-ID: <4BB3CBDA.9070006@mtcc.com> On 03/31/2010 03:07 PM, Ricky Beam wrote: > Yes and no. Many of the uber-cheap models simply don't have the > processing power or memory to do IPv6 well. (Some would say they don't > do IPv4 well. I'm one of them.) Pure > here's-a-packet-here's-where-it-goes switching can be done in almost any > model as long as the v6 stack doesn't make the image too large to fit in > the 4K rom. Doing anything remotely complicated, like tunneling and > stateful firewalling, makes the image much too large and eats way too > much ram. (This is also way many of the cheap models do not run linux > and generally cannot run a usable linux image.) On the more expensive, > higher end models, yes, they can run rather complex IPv4/6 stacks quite > well. I *seriously* doubt that in this day and age. The basic problem is with Linksys' business model which is to farm out the engineering to whomever can produce it cheapest. They provide the spec and if it ain't in the specs, it ain't in the product. You can expect *no* continuity between one product and the next; there ain't an IOS or even codebase. > However, the bottom is that there is simply little to no consumer > demand for IPv6 support -- esp. in North America (read: US) where most > of these things are sold. Yes, of course, except for that making a self-fulfilling prophecy. Mike, who's been bitten one too many times From charles at knownelement.com Wed Mar 31 17:55:59 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 31 Mar 2010 15:55:59 -0700 Subject: Home CPE choice Message-ID: <4BB3D2FF.7030608@knownelement.com> Hopefully this e-mail is considered operational content :) The recent thread on the new linkys kit and ipv6 support got me thinking about CPE choice. What good off the shelf solutions are out there? Should one buy the high end d-link/linksys/netgear products? I've had bad experiences with those (netgear in particular). Should one get a "real" cisco router? The 877 or something? Maybe an ASA or the new small business targeted ISR (can't recall the model number off hand right now). There is mikrotik but I'm not so sure about the operating system. Is there a market for a new breed of CPE running OpenWRT or pfsense on hardware with enough CPU/RAM to not fall over? Granted that won't cost $79.00 at best buy. However it seems to me that decent CPE is going to run a couple hundred dollars in order to have sufficient ram/cpu. My current home router is a cisco 1841. I keep my 6mbps DSL line pretty much saturated all the time. Often times my wife will be watching Hulu in the living room, I'll be streaming music and running torrents (granted I have tuned my Azures client fairly well) all at the same time and it's a good experience. Running that kind of traffic load through my linksys would cause it to need a reboot once or more a day. What are folks here running in SOHO environments that doesn't require too frequent oil changes :) From jack at crepinc.com Wed Mar 31 18:03:08 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Wed, 31 Mar 2010 19:03:08 -0400 Subject: Home CPE choice In-Reply-To: <4BB3D2FF.7030608@knownelement.com> References: <4BB3D2FF.7030608@knownelement.com> Message-ID: Given a marked lack of $significant funding for home routing, I rock BSD boxen all over. At one point we had several doing OSPF in my apartment (because we could) but I moved and am now behind a single Sun Netra ($30) with BSD, natd, and iptables. Works beautifully. If you're only interested in real routing hardware, I'd probably go with the low-end cisco SOHO stuff, or if you still have a 2600 sitting around and only roll DSL, that will work nicely. -Jack Carrozzo On Wed, Mar 31, 2010 at 6:55 PM, Charles N Wyble wrote: > > Hopefully this e-mail is considered operational content :) > > > The recent thread on the new linkys kit and ipv6 support got me thinking > about CPE choice. > > What good off the shelf solutions are out there? Should one buy the high end > d-link/linksys/netgear products? I've had bad experiences with those > (netgear in particular). > > Should one get a "real" cisco router? The 877 or something? Maybe an ASA or > the new small business targeted ISR (can't recall the model number off hand > right now). There is mikrotik but I'm not so sure about the operating > system. > > Is there a market for a new breed of CPE running OpenWRT or pfsense on > hardware with enough CPU/RAM to not fall over? > > Granted that won't cost $79.00 at best buy. However it seems to me that > decent CPE is going to run a couple hundred dollars in order to have > sufficient ram/cpu. > > My current home router is a cisco 1841. I keep my 6mbps DSL line pretty much > saturated all the time. Often times my wife will be watching Hulu in the > living room, I'll be streaming music and running torrents (granted I have > tuned my Azures client fairly well) all at the same time and it's a good > experience. ?Running that kind of traffic load through my linksys would > cause it to need a reboot once or more a day. > > What are folks here running in SOHO environments that doesn't require too > frequent oil changes :) > > > From joe at riversidecg.com Wed Mar 31 18:03:58 2010 From: joe at riversidecg.com (Joe Johnson) Date: Wed, 31 Mar 2010 18:03:58 -0500 Subject: Home CPE choice In-Reply-To: <4BB3D2FF.7030608@knownelement.com> References: <4BB3D2FF.7030608@knownelement.com> Message-ID: <154EDE9026B3D54F883B20F2BBDCF879512206B7@exbe01.windows.riversidecg.com> I have a small HP dummy terminal I installed a CFIDE card in with m0n0wall that has run beautifully for the past 3 years. Barely has any power draw and cost me a whopping $100 after shipping. I keep a few of the dummy terminals around in case this one dies (it's about 6 years old and came from a heavy-use banking application). Joe From hescominsoon at emmanuelcomputerconsulting.com Wed Mar 31 18:07:42 2010 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Wed, 31 Mar 2010 19:07:42 -0400 Subject: Home CPE choice In-Reply-To: <4BB3D2FF.7030608@knownelement.com> References: <4BB3D2FF.7030608@knownelement.com> Message-ID: <4BB3D5BE.9000808@emmanuelcomputerconsulting.com> On 3/31/2010 6:55 PM, Charles N Wyble wrote: > > Hopefully this e-mail is considered operational content :) > > > The recent thread on the new linkys kit and ipv6 support got me > thinking about CPE choice. > > What good off the shelf solutions are out there? Should one buy the > high end d-link/linksys/netgear products? I've had bad experiences > with those (netgear in particular). > > Should one get a "real" cisco router? The 877 or something? Maybe an > ASA or the new small business targeted ISR (can't recall the model > number off hand right now). There is mikrotik but I'm not so sure > about the operating system. > > Is there a market for a new breed of CPE running OpenWRT or pfsense on > hardware with enough CPU/RAM to not fall over? > > Granted that won't cost $79.00 at best buy. However it seems to me > that decent CPE is going to run a couple hundred dollars in order to > have sufficient ram/cpu. > > My current home router is a cisco 1841. I keep my 6mbps DSL line > pretty much saturated all the time. Often times my wife will be > watching Hulu in the living room, I'll be streaming music and running > torrents (granted I have tuned my Azures client fairly well) all at > the same time and it's a good experience. Running that kind of > traffic load through my linksys would cause it to need a reboot once > or more a day. > > What are folks here running in SOHO environments that doesn't require > too frequent oil changes :) > > I run Astaro on a p-4 celey i had lying around. Get far more than any little router you'll see..can't beat the price. From marty.anstey at sunwave.net Wed Mar 31 18:18:48 2010 From: marty.anstey at sunwave.net (Marty Anstey) Date: Wed, 31 Mar 2010 16:18:48 -0700 Subject: Home CPE choice In-Reply-To: <4BB3D2FF.7030608@knownelement.com> References: <4BB3D2FF.7030608@knownelement.com> Message-ID: <4BB3D858.1010806@sunwave.net> > > Hopefully this e-mail is considered operational content :) > > > The recent thread on the new linkys kit and ipv6 support got me > thinking about CPE choice. > > What good off the shelf solutions are out there? Should one buy the > high end d-link/linksys/netgear products? I've had bad experiences > with those (netgear in particular). > > Should one get a "real" cisco router? The 877 or something? Maybe an > ASA or the new small business targeted ISR (can't recall the model > number off hand right now). There is mikrotik but I'm not so sure > about the operating system. > > Is there a market for a new breed of CPE running OpenWRT or pfsense on > hardware with enough CPU/RAM to not fall over? > > Granted that won't cost $79.00 at best buy. However it seems to me > that decent CPE is going to run a couple hundred dollars in order to > have sufficient ram/cpu. > > My current home router is a cisco 1841. I keep my 6mbps DSL line > pretty much saturated all the time. Often times my wife will be > watching Hulu in the living room, I'll be streaming music and running > torrents (granted I have tuned my Azures client fairly well) all at > the same time and it's a good experience. Running that kind of > traffic load through my linksys would cause it to need a reboot once > or more a day. > > What are folks here running in SOHO environments that doesn't require > too frequent oil changes :) > > I run FreeBSD on a PIII; I can easily saturate my 15mbit cable connection without it breaking a sweat. I also have a couple Cisco 2610's, one of which is my ipv6 tunnel endpoint. -M From iain.t.morris at gmail.com Wed Mar 31 18:23:50 2010 From: iain.t.morris at gmail.com (Iain Morris) Date: Wed, 31 Mar 2010 16:23:50 -0700 Subject: Home CPE choice In-Reply-To: <4BB3D858.1010806@sunwave.net> References: <4BB3D2FF.7030608@knownelement.com> <4BB3D858.1010806@sunwave.net> Message-ID: Juniper's SSG5 and SRX100 are nice options for home. I've enjoyed an SSG5 for awhile now. SRX100 for junos. SSG5's pop up on ebay occasionally for a few $100. -Iain On Wed, Mar 31, 2010 at 4:18 PM, Marty Anstey wrote: > > > > > Hopefully this e-mail is considered operational content :) > > > > > > The recent thread on the new linkys kit and ipv6 support got me > > thinking about CPE choice. > > > > What good off the shelf solutions are out there? Should one buy the > > high end d-link/linksys/netgear products? I've had bad experiences > > with those (netgear in particular). > > > > Should one get a "real" cisco router? The 877 or something? Maybe an > > ASA or the new small business targeted ISR (can't recall the model > > number off hand right now). There is mikrotik but I'm not so sure > > about the operating system. > > > > Is there a market for a new breed of CPE running OpenWRT or pfsense on > > hardware with enough CPU/RAM to not fall over? > > > > Granted that won't cost $79.00 at best buy. However it seems to me > > that decent CPE is going to run a couple hundred dollars in order to > > have sufficient ram/cpu. > > > > My current home router is a cisco 1841. I keep my 6mbps DSL line > > pretty much saturated all the time. Often times my wife will be > > watching Hulu in the living room, I'll be streaming music and running > > torrents (granted I have tuned my Azures client fairly well) all at > > the same time and it's a good experience. Running that kind of > > traffic load through my linksys would cause it to need a reboot once > > or more a day. > > > > What are folks here running in SOHO environments that doesn't require > > too frequent oil changes :) > > > > > I run FreeBSD on a PIII; I can easily saturate my 15mbit cable > connection without it breaking a sweat. I also have a couple Cisco > 2610's, one of which is my ipv6 tunnel endpoint. > > -M > > > > > -- -- - Iain Morris iain.t.morris at gmail.com From leen at consolejunkie.net Wed Mar 31 18:33:45 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Thu, 01 Apr 2010 01:33:45 +0200 Subject: Home CPE choice In-Reply-To: <4BB3D2FF.7030608@knownelement.com> References: <4BB3D2FF.7030608@knownelement.com> Message-ID: <4BB3DBD9.3080906@consolejunkie.net> On 04/01/2010 12:55 AM, Charles N Wyble wrote: > > Hopefully this e-mail is considered operational content :) > > > The recent thread on the new linkys kit and ipv6 support got me > thinking about CPE choice. > > What good off the shelf solutions are out there? Should one buy the > high end d-link/linksys/netgear products? I've had bad experiences > with those (netgear in particular). > > Should one get a "real" cisco router? The 877 or something? Maybe an > ASA or the new small business targeted ISR (can't recall the model > number off hand right now). There is mikrotik but I'm not so sure > about the operating system. > > Is there a market for a new breed of CPE running OpenWRT or pfsense on > hardware with enough CPU/RAM to not fall over? > > Granted that won't cost $79.00 at best buy. However it seems to me > that decent CPE is going to run a couple hundred dollars in order to > have sufficient ram/cpu. > My cable provider provides me with a modem which is just a bridge, so all I need is a router box for firewall / nat, etc. I have a Soekris-box, Soekris isn't really cheap though. But I recently noticed this device, it is $69.95 and has IPv6 out of the box I think (no DSL/WAN though !): http://routerboard.com/pricelist.php?showProduct=90 http://wiki.mikrotik.com/wiki/IPv6/Overview_and_examples Haven't tried it yet, I think someone might have mentioned Mikrotik on this list though. Also it's little brother will soon be available: $39.95, 'available on end of March 2010' http://routerboard.com/pricelist.php?showProduct=56 Would that be the right price-range ? > My current home router is a cisco 1841. I keep my 6mbps DSL line > pretty much saturated all the time. Often times my wife will be > watching Hulu in the living room, I'll be streaming music and running > torrents (granted I have tuned my Azures client fairly well) all at > the same time and it's a good experience. Running that kind of > traffic load through my linksys would cause it to need a reboot once > or more a day. > > What are folks here running in SOHO environments that doesn't require > too frequent oil changes :) > > > From bpfankuch at cpgreeley.com Wed Mar 31 18:34:38 2010 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Wed, 31 Mar 2010 17:34:38 -0600 Subject: Home CPE choice In-Reply-To: <4BB3D2FF.7030608@knownelement.com> References: <4BB3D2FF.7030608@knownelement.com> Message-ID: <01759D50DC387C45A018FE1817CE27D75791AFFBAE@CPExchange1.cpgreeley.com> I'm running IPcop on a mini ITX machine (old processor out of my laptop T5500), a cheapo stick of memory and a sata to CF adaptor with a 4gb CF card. All in all cost me about $350. Been running IPcop's for about 6 years now on various hardware going back to a dual p3 500 with 256mb of ram and no complaints aside from ipv6 support which is slated for the 2.x branch. I have a 50/10 cable line which I have kept saturated for multiple days at a time, 5 public IP's about 60 firewall rules and 3 network interfaces (LAN, WAN and guest wireless). I migrated from a PPPOE dsl provider to cable about a year and a half ago. Also physically moved about that time and never powered off the device, or had any issues whatsoever. The UI is a bit weird, but once you set it up you never touch it. 17:16:19 up 568 days, 19:36, 0 users, load average: 0.00, 0.00, 0.00 -----Original Message----- From: Charles N Wyble [mailto:charles at knownelement.com] Sent: Wednesday, March 31, 2010 4:56 PM To: nanog at nanog.org Subject: Home CPE choice Hopefully this e-mail is considered operational content :) The recent thread on the new linkys kit and ipv6 support got me thinking about CPE choice. What good off the shelf solutions are out there? Should one buy the high end d-link/linksys/netgear products? I've had bad experiences with those (netgear in particular). Should one get a "real" cisco router? The 877 or something? Maybe an ASA or the new small business targeted ISR (can't recall the model number off hand right now). There is mikrotik but I'm not so sure about the operating system. Is there a market for a new breed of CPE running OpenWRT or pfsense on hardware with enough CPU/RAM to not fall over? Granted that won't cost $79.00 at best buy. However it seems to me that decent CPE is going to run a couple hundred dollars in order to have sufficient ram/cpu. My current home router is a cisco 1841. I keep my 6mbps DSL line pretty much saturated all the time. Often times my wife will be watching Hulu in the living room, I'll be streaming music and running torrents (granted I have tuned my Azures client fairly well) all at the same time and it's a good experience. Running that kind of traffic load through my linksys would cause it to need a reboot once or more a day. What are folks here running in SOHO environments that doesn't require too frequent oil changes :) From wavetossed at googlemail.com Wed Mar 31 18:40:10 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 31 Mar 2010 23:40:10 +0000 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> Message-ID: > Yes and no. ?Many of the uber-cheap models simply don't have the processing > power or memory to do IPv6 well. (Some would say they don't do IPv4 well. > ?I'm one of them.) ?Pure here's-a-packet-here's-where-it-goes switching can > be done in almost any model as long as the v6 stack doesn't make the image > too large to fit in the 4K rom. Flashback to 1989... In 2003, Dallas Semiconductor tried to implement IPv6 on an 8051 microcontroller. They started with an IPv4 stack and modified as needed but soon discovered that it was easiest to just implement a dual stack that handled all the addresses internally as 128 bit quantities regardless of whether or not they were v6 or v4. It worked and they did it in 64k of ROM. This was written up at the time, and no doubt influenced many other implementors of v6 in non-UNIX embedded systems. By the way, the 8051 was introduced by Intel back in 1980. It was loosely related on the 8080 which powered many CP/M based computers in the 80's that typically had 64K of RAM > On the more expensive, > higher end models, yes, they can run rather complex IPv4/6 stacks quite > well. These so-called expensive models are the majority of the cable modem and DSL market in the USA, often running Linux which has supported IPv6 for a decade. > However, the bottom is that there is simply little to no consumer > demand for IPv6 support -- esp. in North America (read: US) where most of > these things are sold. In fact, consumer demand for IPv6 is close to 100%. Consumers just want their Internet access to work trouble free and are not interested in hearing excuses like "ARIN ran out of IP addresses" or, "We can't add any more connections to our network because it is full". IPv6 lets you keep on offering full Internet access and keep on growing the network so that when a customer moves across town, you can connect them up in their new home. --Michael Dillon From wavetossed at googlemail.com Wed Mar 31 19:01:15 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 1 Apr 2010 00:01:15 +0000 Subject: Home CPE choice In-Reply-To: <4BB3D2FF.7030608@knownelement.com> References: <4BB3D2FF.7030608@knownelement.com> Message-ID: What good off the shelf solutions are out there? Should one buy the high end > d-link/linksys/netgear products? I've had bad experiences with those > (netgear in particular). > > Should one get a "real" cisco router? IMHO, you should look to Japan, Korea and China for suppliers. Even if you are small, you may be pleasantly surprised at the response from a Chinese manufacturer. If you specify a box with Linux-based firmware, then the manufacturer has low design costs, and can ammortise them across many customers because that Linux build can be used again and again. The easiest way to spec it is to find an existing DSL CPE that is based around Linux and ask them how much to make noname boxes for you so that you can put your own sticker on. Better yet, form a buying club with folks that you meet at the next NANOG BOF and you are certain to get decent responses. > Is there a market for a new breed of CPE running OpenWRT or pfsense on > hardware with enough CPU/RAM to not fall over? Such CPE has been available for years which is why OpenWRT was created in the first place. I believe OpenWRT has limited DSL drivers? > Granted that won't cost $79.00 at best buy. However it seems to me that > decent CPE is going to run a couple hundred dollars in order to have > sufficient ram/cpu. Ignore BestBuy prices. You don't know their margin and it WILL vary product to product. With a bit of web searching I found a 5 yr old device, Netcomm NB5 ADSL modem/router that runs Linux and retails for $99 Australian. > What are folks here running in SOHO environments that doesn't require too > frequent oil changes :) Ignore what people tell you. Go talk to Chinese manufacturers and explain what you need. You are doing them a favor by providing free market data to them so that they begin to understand that there is an ISP market that wants DSL routers that are Linux based, flexible, support IPv6, and can be branded by the ISP. Fact is, that all those name brand boxes at BestBuy also come from Chinese manufacturers anyway. The brand name companies are middlemen that provide specs, some design work, and checking manufacturing quality. The only tricky part of the equation is manufacturing quality, but why not copy the ISP pioneers of the 1990s. They did not do extensive trials and evaluations of routers and switches. Instead, they found out what the early entrants were using and bought the same stuff. So do some digging to find out what Chinese factories are building kit for Billionton, Netgear and all the rest. --Michael Dillon From nick at foobar.org Wed Mar 31 19:04:29 2010 From: nick at foobar.org (Nick Hilliard) Date: Thu, 01 Apr 2010 01:04:29 +0100 Subject: Home CPE choice In-Reply-To: <4BB3D2FF.7030608@knownelement.com> References: <4BB3D2FF.7030608@knownelement.com> Message-ID: <4BB3E30D.6070604@foobar.org> On 31/03/2010 23:55, Charles N Wyble wrote: > What good off the shelf solutions are out there? Should one buy the high > end d-link/linksys/netgear products? I've had bad experiences with those > (netgear in particular). Some people have said that the Fritz!box is quite good. No idea if it's approved for use in the US. Nick From nick at foobar.org Wed Mar 31 19:05:55 2010 From: nick at foobar.org (Nick Hilliard) Date: Thu, 01 Apr 2010 01:05:55 +0100 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> Message-ID: <4BB3E363.6000708@foobar.org> On 01/04/2010 00:40, Michael Dillon wrote: > In fact, consumer demand for IPv6 is close to 100%. Michael, I think you fat-fingered "0%". Just to be clear, I'm talking about the real world here. Nick From owen at delong.com Wed Mar 31 17:13:57 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 31 Mar 2010 15:13:57 -0700 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <4BB3AB96.8050409@bogus.com> References: <4BB3AB96.8050409@bogus.com> Message-ID: <7AC1DF84-6DB1-4DE4-8D76-FA1EC69E989A@delong.com> Linksys Live Chat claims neither the new Valet, nor the new E-Series supports IPv6. I do not have high confidence in the accuracy of the answer. Owen On Mar 31, 2010, at 1:07 PM, Joel Jaeggli wrote: > > > On 03/31/2010 12:00 PM, Jorge Amodio wrote: >> http://newsroom.cisco.com/dlls/2010/prod_033110.html >> >> Does anybody know what are the plans for IPv6 support ? > > the current wrt610n supports ipv6 I failed to see why a slightly > updated and rebranded one would not as well. > >> Regards >> Jorge >> From owen at delong.com Wed Mar 31 17:15:36 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 31 Mar 2010 15:15:36 -0700 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> Message-ID: <35A182B8-DC1E-45FB-9911-D9986EDB8E49@delong.com> On Mar 31, 2010, at 12:18 PM, David Conrad wrote: > On Mar 31, 2010, at 6:52 AM, Joly MacFie wrote: >> On Tue, Mar 30, 2010 at 8:15 PM, David Conrad wrote: >>> Well, actually, ICANN was in Geneva specifically for the meeting, but we weren't allowed into the room. Quite annoying, actually. > >> Why isn't this on YouTube? > > You'd have to ask the ITU secretariat. I'd note that they do audiocast meetings such as this, however you have to have a "TIES" account to gain access to it. Not sure how one would go about getting a TIES account. > > Regards, > -drc > $20,000/year to the ITU secretariat to become a sector member. Owen From charles at knownelement.com Wed Mar 31 19:14:59 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 31 Mar 2010 17:14:59 -0700 Subject: Home CPE choice In-Reply-To: <4BB3E30D.6070604@foobar.org> References: <4BB3D2FF.7030608@knownelement.com> <4BB3E30D.6070604@foobar.org> Message-ID: <4BB3E583.1050509@knownelement.com> On 03/31/2010 05:04 PM, Nick Hilliard wrote: > On 31/03/2010 23:55, Charles N Wyble wrote: > > Some people have said that the Fritz!box is quite good. No idea if > it's approved for use in the US. Nick, Thanks for posting this. I wasn't aware of this product. It looks pretty cool. From wavetossed at googlemail.com Wed Mar 31 19:16:03 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 1 Apr 2010 00:16:03 +0000 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <4BB3E363.6000708@foobar.org> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> Message-ID: On 1 April 2010 00:05, Nick Hilliard wrote: > On 01/04/2010 00:40, Michael Dillon wrote: >> >> In fact, consumer demand for IPv6 is close to 100%. > > Michael, ?I think you fat-fingered "0%". > > Just to be clear, I'm talking about the real world here. I did not fat finger anything. In the real world, nearly 100% of consumers demand IPv6 from their ISP. But consumers are not techies so they don't talk that way with acronyms and technical gobbledygook version numbers. In plain English they tell us that they want the Internet access service to just plain work. They want it to work all the time, including tomorrow and if they move across town, or to another city, they want to order a move from the ISP, and have it done in a few days. ISPs who don't have IPv6 will soon be unable to provide access to all Internet sites, as content providers begin to bring IPv6 sites onstream. And ISPs without IPv6 will not be able to continue growing their networks, even for something as trivial as an existing customer who moves to a different PoP. The approaching time is going to be a crisis for the ISP industry, and the press will tar some ISPs in a very bad light if they can't smoothly introduce IPv6. There will be bargain basement sellouts and happy M&A departments at ISPs with foresight who got their IPv6 capability ready early. It's now like the calm before the storm. We know that a battle is coming and we know roughly where and when it will be fought. Reports from the field indicate that all is quiet, but that is normal just before the battle commences. The wise general will not be put off by these reports of peace and quiet, but will prepare his forces and keep an eye on the preparations of his adversaries. --Michael Dillon From jeroen at mompl.net Wed Mar 31 19:36:47 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 31 Mar 2010 17:36:47 -0700 Subject: Finding content in your job title In-Reply-To: <4BB2C1DE.1070004@cox.net> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C1DE.1070004@cox.net> Message-ID: <4BB3EA9F.4030302@mompl.net> Larry Sheldon wrote: > So I just stayed with the cards I had that said Associate Director for > Telecommunications and Computers. That's nice, so you can call yourself a Director ;-) What's up with the overuse of the term "President" in job titles, Vice President of Engineering, Product Management... often these people appear to not have any real corporate presidential powers... Maybe it's because receptionists and secretaries are now called office managers and so the managers feel their title has become inflated. I agree with the misuse of the term "Engineer" in IT. I think it should only be used for the "official" protected title of civil engineer. Which I believe is a very respectable job. Sad but true, in IT too many people have some form of engineer in their job title but are almost totally clueless. > Which is about as void of meaning then and now as anything I have ever > heard of. What happened to titles such as programmer (or code monkey if your prefer, maybe a PC issue?), network administrator, systems administrator, systems analyst, information analyst? Greetings, Jeroen From charles at knownelement.com Wed Mar 31 19:39:36 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 31 Mar 2010 17:39:36 -0700 Subject: Home CPE choice In-Reply-To: References: <4BB3D2FF.7030608@knownelement.com> Message-ID: <4BB3EB48.6010900@knownelement.com> On 03/31/2010 04:03 PM, Jack Carrozzo wrote: > Given a marked lack of $significant funding for home routing, I rock > BSD boxen all over. Cool. I'm looking at pfsense to replace my cisco. I want to move the router to my lab for CCIE studies. Have you tried pfsense, or do you find the built in functionality/configuration system to be sufficient? I've only used bsd in an end user setting. The more I read, the more it seems that for software routing BSD is a better packet pusher. > At one point we had several doing OSPF in my > apartment (because we could) Oh yeah. I hear that. :) > but I moved and am now behind a single > Sun Netra ($30) with BSD, natd, and iptables. Works beautifully. > Iptables on bsd? Not pf? Interesting. I'm pretty familiar with Iptables myself and have been wanting to pickup pf. Can you dive into why you went with iptables instead of pf? Was it familiarity or functionality or...? > If you're only interested in real routing hardware, I'd probably go > with the low-end cisco SOHO stuff, or if you still have a 2600 sitting > around and only roll DSL, that will work nicely. > Right. I have a 2600 in my lab. From charles at knownelement.com Wed Mar 31 19:40:35 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 31 Mar 2010 17:40:35 -0700 Subject: Home CPE choice In-Reply-To: <154EDE9026B3D54F883B20F2BBDCF879512206B7@exbe01.windows.riversidecg.com> References: <4BB3D2FF.7030608@knownelement.com> <154EDE9026B3D54F883B20F2BBDCF879512206B7@exbe01.windows.riversidecg.com> Message-ID: <4BB3EB83.1050308@knownelement.com> On 03/31/2010 04:03 PM, Joe Johnson wrote: > I have a small HP dummy terminal I installed a CFIDE card in with m0n0wall that has run beautifully for the past 3 years. No moving parts I take it? I think I've played with m0n0wall in the past. > Barely has any power draw and cost me a whopping $100 after shipping. Very nice. > I keep a few of the dummy terminals around in case this one dies (it's about 6 years old and came from a heavy-use banking application). > There you go. From richard.barnes at gmail.com Wed Mar 31 19:43:02 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 31 Mar 2010 20:43:02 -0400 Subject: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group] In-Reply-To: <35A182B8-DC1E-45FB-9911-D9986EDB8E49@delong.com> References: <20100227040406.GH13373@macbook.catpipe.net> <20100227062038.38AD01CC0E@ptavv.es.net> <4B98C6E4.6020203@nic-naa.net> <88ac5c711003301705i4a985d1ey3915b0bcdf091279@mail.gmail.com> <35A182B8-DC1E-45FB-9911-D9986EDB8E49@delong.com> Message-ID: Actually, it's 31,800 CHF == 30,170 USD. Plus, you have to get the approval of your local government even to submit an application. On Wed, Mar 31, 2010 at 6:15 PM, Owen DeLong wrote: > > On Mar 31, 2010, at 12:18 PM, David Conrad wrote: > >> On Mar 31, 2010, at 6:52 AM, Joly MacFie wrote: >>> On Tue, Mar 30, 2010 at 8:15 PM, David Conrad wrote: >>>> Well, actually, ICANN was in Geneva specifically for the meeting, but we weren't allowed into the room. ?Quite annoying, actually. >> >>> Why isn't this on YouTube? >> >> You'd have to ask the ITU secretariat. ?I'd note that they do audiocast meetings such as this, however you have to have a "TIES" account to gain access to it. ?Not sure how one would go about getting a TIES account. >> >> Regards, >> -drc >> > > $20,000/year to the ITU secretariat to become a sector member. > > Owen > > > From charles at knownelement.com Wed Mar 31 19:45:45 2010 From: charles at knownelement.com (Charles N Wyble) Date: Wed, 31 Mar 2010 17:45:45 -0700 Subject: Home CPE choice In-Reply-To: <4BB3D5BE.9000808@emmanuelcomputerconsulting.com> References: <4BB3D2FF.7030608@knownelement.com> <4BB3D5BE.9000808@emmanuelcomputerconsulting.com> Message-ID: <4BB3ECB9.6050209@knownelement.com> On 03/31/2010 04:07 PM, William Warren wrote: > I run Astaro on a p-4 celey i had lying around. Get far more than any > little router you'll see..can't beat the price. Astaro looks cool. I hadn't heard of it before. Thanks for sharing. From jfbeam at gmail.com Wed Mar 31 20:05:49 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Wed, 31 Mar 2010 21:05:49 -0400 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> Message-ID: On Wed, Mar 31, 2010 at 8:16 PM, Michael Dillon wrote: > I did not fat finger anything. In the real world, nearly 100% of consumers > demand IPv6 from their ISP. ... Hah. No. No they don't. They want, as you point out, "access to the internet", which they are currently getting JUST FINE. And this will continue to be the case for a LONG TIME. > ISPs who don't have IPv6 will soon be unable to provide access to all > Internet sites, as content providers begin to bring IPv6 sites onstream. I've been hearing this BS for over a decade, and yet I've not heard a single complaint or run into a single site I could not access for lack of IPv6. Yes, there are IPv6 only sites, but I don't use them, nor do any of the people I know. What little IPv6 I have used I have had to go out of my way to *intentionally* use IPv6 over v4. Until there are common sites that are only accessible via IPv6 -- thus unavailable to "unevolved" ISP customers, ISP won't be investing anything in IPv6 deployment. That's not to say ISPs aren't experimenting with it -- some are, simply that they are not putting any heavy engineering resources behind it. > The approaching time... Right now, that snail is on the other side of the world -- almost literally. Unless someone glues a rocket to it's shell, it won't even be on the horizon for years. If it were up to me, you, or the rest of the list, we'd rather simply get the mess over and switch everything tomorrow. *heh* But that ain't gonna happen. (I still have gear in use that only does IPX. thankfully, I've escaped Appletalk, but IPX is still clinging to life.) --Ricky From deleskie at gmail.com Wed Mar 31 20:14:28 2010 From: deleskie at gmail.com (jim deleskie) Date: Wed, 31 Mar 2010 22:14:28 -0300 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> Message-ID: I'm a real life user, I know the difference and I could careless about v6. most anything I want I is on v4 and will still be there long after ( when ever it is) we run out of v4 addresses. If I'm on a content provider and I'm putting something new online I want everyone to see, they will find away for all of us with v4 and credit cards to see it, and not be so worried about developing countries or the sub 5% of people in developed countries for now. I'm sure @ some point v6 will see the business need, but while I'm expect to have to deploy it for marketing reasons, I hope its someone else's problem but its a must have for real business. On Wed, Mar 31, 2010 at 10:05 PM, Ricky Beam wrote: > On Wed, Mar 31, 2010 at 8:16 PM, Michael Dillon > wrote: >> I did not fat finger anything. In the real world, nearly 100% of consumers >> demand IPv6 from their ISP. ... > > Hah. ?No. ?No they don't. ?They want, as you point out, "access to the > internet", which they are currently getting JUST FINE. ?And this will > continue to be the case for a LONG TIME. > >> ISPs who don't have IPv6 will soon be unable to provide access to all >> Internet sites, as content providers begin to bring IPv6 sites onstream. > > I've been hearing this BS for over a decade, and yet I've not heard a > single complaint or run into a single site I could not access for lack > of IPv6. ?Yes, there are IPv6 only sites, but I don't use them, nor do > any of the people I know. ?What little IPv6 I have used I have had to > go out of my way to *intentionally* use IPv6 over v4. > > Until there are common sites that are only accessible via IPv6 -- thus > unavailable to "unevolved" ISP customers, ISP won't be investing > anything in IPv6 deployment. ?That's not to say ISPs aren't > experimenting with it -- some are, simply that they are not putting > any heavy engineering resources behind it. > >> The approaching time... > > Right now, that snail is on the other side of the world -- almost > literally. ?Unless someone glues a rocket to it's shell, it won't even > be on the horizon for years. ?If it were up to me, you, or the rest of > the list, we'd rather simply get the mess over and switch everything > tomorrow. ?*heh* But that ain't gonna happen. (I still have gear in > use that only does IPX. ?thankfully, I've escaped Appletalk, but IPX > is still clinging to life.) > > --Ricky > > From jmamodio at gmail.com Wed Mar 31 20:14:45 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 31 Mar 2010 20:14:45 -0500 Subject: Finding content in your job title In-Reply-To: <4BB3EA9F.4030302@mompl.net> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C1DE.1070004@cox.net> <4BB3EA9F.4030302@mompl.net> Message-ID: > I agree with the misuse of the term "Engineer" in IT. I think it should only > be used for the "official" protected title of civil engineer. Which I > believe is a very respectable job. Sad but true, in IT too many people have > some form of engineer in their job title but are almost totally clueless. [ X-Operational_Content = 0 ] Can't resist. When I read your message it brought back to my memory a nice guy that used to work for me eons ago, very clever, smart and hands-on, he had a Bachelor's Degree in Psychology. One day, we had some sort of outage and I found him in the "computer room" sitting in front of one of the racks with some routing gear, I still have that image in my memory he looked like he was doing some sort of group therapy with the routers, I couldn't resist and told him "Hey Joey, Freud won't help you, get your butt off of the chair and follow the default procedure, power cycle the damn beast". There were also several folks with various degrees in Physics, experts on blowing up stuff. Again, IMHO, in this field a title may help or may provide others a relative idea where you fit in a large organization, or help the HR folks know how much to put on your paycheck or what kind of benefits/perks go associated with that level, but I still believe that substance is more important. Regards Jorge COOK Chief Old Operations Knucklehead From dga at cs.cmu.edu Wed Mar 31 20:19:06 2010 From: dga at cs.cmu.edu (David Andersen) Date: Wed, 31 Mar 2010 21:19:06 -0400 Subject: Home CPE choice In-Reply-To: <4BB3D2FF.7030608@knownelement.com> References: <4BB3D2FF.7030608@knownelement.com> Message-ID: On Mar 31, 2010, at 6:55 PM, Charles N Wyble wrote: > > Is there a market for a new breed of CPE running OpenWRT or pfsense on hardware with enough CPU/RAM to not fall over? Hi, Charles -- as a few hardware points to consider: Both the Soekris and Alix hardware is still very solid. We've been using them in a few research projects for a couple of years now and haven't had a single failure. Both can push ~20Mbit/sec with in-kernel packet forwarding and NAT. Alix2d2: 500Mhz Geode, 256MB DDR, 2x100Mbit ethernet, USB, CF, 2x miniPCI, $110 + enclosure ($10) /power ($6) Soekris net5501: 500Mhz Geode, 512MB DDR, 4x 100Mbit ethernet, USB, CF, miniPCI, PCI, $300 + power If you want to move a step up, there's a really nice new option on the market in the form of Intel "Pineview" atom-based systems, but the selection of embedded/router boards is more limited than it is with the Geodes. Advantech just released a single or dual core, 1.6Ghz, fanless atom-based system that draws about 15W that can easily handle 100Mbps: http://www.advantech.com.tw/products/AIMB-212/mod_1-DCLYTN.aspx (2x gigabit ethernet ports onboard) The drawback is that it's kinda spendy - about $220, IIRC, plus about $40 for 2GB DRAM and another $10 for a power supply - but it's a great little box. Takes 12V in so you can use a small power supply with it, not a big ITX beast (or an expensive inline ITX). And if you find yourself needing 5x RS232 ports, well, now you have 'em. :) (You're paying for an embedded controller...) We just got 20 of them and are able to handle a few hundred MB/sec of reading off of an SSD, etc. I haven't yet tried forwarding full gigabit through it, but it's probably ... around the limit. Don't go with the old Atom-based systems you might find on ebay. The "pineview" based ones are the first ones out that are fanless -- and the I/O controller is a *lot* better on these systems. If you go with an Atom system off of, say, Newegg, be careful with the chipset selection. -Dave From jjohnstone at diamondtech.ca Wed Mar 31 20:30:55 2010 From: jjohnstone at diamondtech.ca (Jeff Johnstone) Date: Wed, 31 Mar 2010 18:30:55 -0700 Subject: Home CPE choice In-Reply-To: <01759D50DC387C45A018FE1817CE27D75791AFFBAE@CPExchange1.cpgreeley.com> References: <4BB3D2FF.7030608@knownelement.com> <01759D50DC387C45A018FE1817CE27D75791AFFBAE@CPExchange1.cpgreeley.com> Message-ID: On Wed, Mar 31, 2010 at 4:34 PM, Blake Pfankuch wrote: > I'm running IPcop on a mini ITX machine (old processor out of my laptop > T5500), a cheapo stick of memory and a sata to CF adaptor with a 4gb CF > card. All in all cost me about $350. Been running IPcop's for about 6 > years now on various hardware going back to a dual p3 500 with 256mb of ram > and no complaints aside from ipv6 support which is slated for the 2.x > branch. I have a 50/10 cable line which I have kept saturated for multiple > days at a time, 5 public IP's about 60 firewall rules and 3 network > interfaces (LAN, WAN and guest wireless). I migrated from a PPPOE dsl > provider to cable about a year and a half ago. Also physically moved about > that time and never powered off the device, or had any issues whatsoever. > > The UI is a bit weird, but once you set it up you never touch it. > > 17:16:19 up 568 days, 19:36, 0 users, load average: 0.00, 0.00, 0.00 > > Running IPcop on a circa 1995 PIII, 128 Mb Ram, I believe its 5Gb disk 3 of 5 I originally setup about 10 years ago when I decided on this platform (2 have died so far), total cost $0 using repurposed systems. It runs a DHCP LAN/Wan with a small dmz off it and other than security based upgrades hasn't been touched since it was installed. I just checked, its been up 496 days without a hiccup this time, probably since our last power outage which was longer than the 10 minutes my little ups will manage :) Had a problem the other day and my provider "unamed", "Largest BC/Canada/DSL provider" finally got it fixed. One of the things they said was broken is the 12 year old DSL modem they provided and so they sent me a free replacement to get things up to speed. But wait, this is where things get interesting, they sent me an IP4 based NAT router. I called back and said, "That won't work I need at leat a couple of Internet Reachable addresses to use.". Long story short, they are no longer providing addresses anymore, only Nat (was a battle but I managed to get them to send me a replacement modem/bridge instead), thus said Company will be recovering thousands of addresses over the next little while from all their residential customers to use somewhere else and lowering the functionality for the customer. On a side note, IPV6 was not available, was not in their plans, and there was no beta list, volunteer list, interest list, etc for people to express interest with. In the 1990's this Company was praised for its forward thinking :) cheers From LarrySheldon at cox.net Wed Mar 31 20:36:50 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Wed, 31 Mar 2010 20:36:50 -0500 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <4BB3E363.6000708@foobar.org> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> Message-ID: <4BB3F8B2.50203@cox.net> On 3/31/2010 19:05, Nick Hilliard wrote: > On 01/04/2010 00:40, Michael Dillon wrote: >> In fact, consumer demand for IPv6 is close to 100%. > > Michael, I think you fat-fingered "0%". > > Just to be clear, I'm talking about the real world here. I wondered about that. I would have guess that nearly all "consumers" (where that is the most savvy label available for them) would reply "huh?". The next layer up would say, "Yeah, sure...I've got my firewalls set to stop it along wit the other evil stuff like "ping". -- Democracy: Three wolves and a sheep voting on the dinner menu. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jeroen at mompl.net Wed Mar 31 20:36:58 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 31 Mar 2010 18:36:58 -0700 Subject: Finding content in your job title In-Reply-To: References: Message-ID: <4BB3F8BA.7040103@mompl.net> Larry Stites wrote: > Come to think of it maybe that's a good name for a corporation; Gopher IT. That would unnecessarily confuse us 1 and a half human who still use gopher. :-( From patrick at zill.net Wed Mar 31 20:50:23 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Wed, 31 Mar 2010 21:50:23 -0400 Subject: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> Message-ID: <4BB3FBDF.8070700@zill.net> Michael Dillon wrote: > > ISPs who don't have IPv6 will soon be unable to provide access to all > Internet sites, as content providers begin to bring IPv6 sites onstream. > And ISPs without IPv6 will not be able to continue growing their networks, > even for something as trivial as an existing customer who moves to a > different PoP. It is April Fool's Day somewhere on Earth already (9:49PM Eastern here as I write this). What is the local time where you are Michael? --Patrick From nhale at softlayer.com Wed Mar 31 21:06:17 2010 From: nhale at softlayer.com (Nick Hale) Date: Wed, 31 Mar 2010 21:06:17 -0500 Subject: Charter North Texas - IP Services Contact Message-ID: <98E72206041B1B408D3F92E91E80BF180BF06618@slmail101.softlayer.local> Can I get an off-list reply from a Charter Cable admin for the North Texas area? (This is for IP services and/or residental cable services) Thank you! ___________________________________ Regards, Nick Hale Abuse Administrator nhale at softlayer.com 866.398.7638 toll-free 214.442.0601 fax 6400 International Parkway, Suite 2000 Plano, TX 75093 http://www.softlayer.com -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 4422 bytes Desc: image001.jpg URL: From jonesnco at gmail.com Wed Mar 31 21:39:31 2010 From: jonesnco at gmail.com (jonesnco at gmail.com) Date: Thu, 01 Apr 2010 02:39:31 +0000 Subject: Home CPE choice Message-ID: <0016e6541f9eb90c65048323c5a6@google.com> Netscreen 5GTs will also do IPv6 with some ScreenOS 5.4 code revs (5.4.0r10.0 for sure). Those pop up on Ebay for $60ish and make respectable home CPE devices. Not quite the horsepower of the SSG5 but they seem to hold up reasonably well. Dan Jones > Juniper's SSG5 and SRX100 are nice options for home. I've enjoyed an SSG5 > for awhile now. SRX100 for junos. SSG5's pop up on ebay occasionally for a > few $100. > -Iain > On Wed, Mar 31, 2010 at 4:18 PM, Marty Anstey > wrote: > > > > Hopefully this e-mail is considered operational content :) > > > > > > The recent thread on the new linkys kit and ipv6 support got me > > thinking about CPE choice. > > > > What good off the shelf solutions are out there? Should one buy the > > high end d-link/linksys/netgear products? I've had bad experiences > > with those (netgear in particular). > > > > Should one get a "real" cisco router? The 877 or something? Maybe an > > ASA or the new small business targeted ISR (can't recall the model > > number off hand right now). There is mikrotik but I'm not so sure > > about the operating system. > > > > Is there a market for a new breed of CPE running OpenWRT or pfsense on > > hardware with enough CPU/RAM to not fall over? > > > > Granted that won't cost $79.00 at best buy. However it seems to me > > that decent CPE is going to run a couple hundred dollars in order to > > have sufficient ram/cpu. > > > > My current home router is a cisco 1841. I keep my 6mbps DSL line > > pretty much saturated all the time. Often times my wife will be > > watching Hulu in the living room, I'll be streaming music and running > > torrents (granted I have tuned my Azures client fairly well) all at > > the same time and it's a good experience. Running that kind of > > traffic load through my linksys would cause it to need a reboot once > > or more a day. > > > > What are folks here running in SOHO environments that doesn't require > > too frequent oil changes :) > > > > > I run FreeBSD on a PIII; I can easily saturate my 15mbit cable > connection without it breaking a sweat. I also have a couple Cisco > 2610's, one of which is my ipv6 tunnel endpoint. > -M -- -- - Iain Morris iain.t.morris at gmail.com From streiner at cluebyfour.org Wed Mar 31 22:00:19 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 31 Mar 2010 23:00:19 -0400 (EDT) Subject: Finding content in your job title In-Reply-To: <4BB3EA9F.4030302@mompl.net> References: <4BB2BE2C.9000901@ibctech.ca> <4BB2C1DE.1070004@cox.net> <4BB3EA9F.4030302@mompl.net> Message-ID: On Wed, 31 Mar 2010, Jeroen van Aart wrote: > What happened to titles such as programmer (or code monkey if your prefer, > maybe a PC issue?), network administrator, systems administrator, systems > analyst, information analyst? Those titles still exist, but after you read enough job postings for "network administrator", "network manager", or "network engineer" you might not remember what they meant to you originally because HR people are generally not tech-savvy, or jobs have to be posted in classification buckets that don't fit very well. I've seen more job postings than I care to count that asked for a "network engineer", but the closest duty the job actually called for was someone who knows how to manage Exchange and Active Directory. jms From dwhite at olp.net Wed Mar 31 22:12:53 2010 From: dwhite at olp.net (Dan White) Date: Wed, 31 Mar 2010 22:12:53 -0500 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> Message-ID: <20100401031253.GA5032@dan.olp.net> On 31/03/10?22:14?-0300, jim deleskie wrote: >I'm a real life user, I know the difference and I could careless about >v6. most anything I want I is on v4 and will still be there long >after ( when ever it is) we run out of v4 addresses. If I'm on a From a content perspective, you may be right. Those with a quickly dwindling supply of v4 addresses will most likely use what they have left for business customers, and for content. However, there will be a time when a significant number of customers will not be able to access your content. >content provider and I'm putting something new online I want everyone >to see, they will find away for all of us with v4 and credit cards to >see it, and not be so worried about developing countries or the sub 5% >of people in developed countries for now. I'm sure @ some point v6 What percentage of sales are you willing to eat? >will see the business need, but while I'm expect to have to deploy it >for marketing reasons, I hope its someone else's problem but its a >must have for real business. Are you willing to gamble your business on your expectations? Business models will develop that will take advantage of global addressing to end devices. The Next Big (Nth) Thing will. Do you feel that you have a perfect Crystal Ball, or do you want to start hedging your bets now? -- Dan White From patrick at zill.net Wed Mar 31 22:18:54 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Wed, 31 Mar 2010 23:18:54 -0400 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <20100401031253.GA5032@dan.olp.net> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> Message-ID: <4BB4109E.90006@zill.net> Dan White wrote: > On 31/03/10 22:14 -0300, jim deleskie wrote: >> I'm a real life user, I know the difference and I could careless about >> v6. most anything I want I is on v4 and will still be there long >> after ( when ever it is) we run out of v4 addresses. If I'm on a > > From a content perspective, you may be right. Those with a quickly > dwindling supply of v4 addresses will most likely use what they have left > for business customers, and for content. > > However, there will be a time when a significant number of > customers will not be able to access your content. ^^ Uncertainty . > What percentage of sales are you willing to eat? ^^ Fear . > >> will see the business need, but while I'm expect to have to deploy it >> for marketing reasons, I hope its someone else's problem but its a >> must have for real business. > > Are you willing to gamble your business on your expectations? Business > models will develop that will take advantage of global addressing to end > devices. The Next Big (Nth) Thing will. Do you feel that you have a perfect > Crystal Ball, or do you want to start hedging your bets now? ^^ Doubt. --Patrick From dwhite at olp.net Wed Mar 31 22:22:32 2010 From: dwhite at olp.net (Dan White) Date: Wed, 31 Mar 2010 22:22:32 -0500 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <4BB4109E.90006@zill.net> References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> Message-ID: <20100401032232.GB5032@dan.olp.net> On 31/03/10?23:18?-0400, Patrick Giagnocavo wrote: >Dan White wrote: >> From a content perspective, you may be right. Those with a quickly >> dwindling supply of v4 addresses will most likely use what they have left >> for business customers, and for content. >> >> However, there will be a time when a significant number of >> customers will not be able to access your content. > >^^ Uncertainty . > >> What percentage of sales are you willing to eat? > >^^ Fear . > >> >> Are you willing to gamble your business on your expectations? Business >> models will develop that will take advantage of global addressing to end >> devices. The Next Big (Nth) Thing will. Do you feel that you have a perfect >> Crystal Ball, or do you want to start hedging your bets now? > >^^ Doubt. http://www.iana.org/assignments/ipv4-address-space/ -- Dan White From patrick at zill.net Wed Mar 31 22:52:17 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Wed, 31 Mar 2010 23:52:17 -0400 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <20100401032232.GB5032@dan.olp.net> References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> Message-ID: <4BB41871.8050608@zill.net> Dan White wrote: >>> Are you willing to gamble your business on your expectations? Business >>> models will develop that will take advantage of global addressing to end >>> devices. The Next Big (Nth) Thing will. Do you feel that you have a >>> perfect >>> Crystal Ball, or do you want to start hedging your bets now? >> >> ^^ Doubt. > > http://www.iana.org/assignments/ipv4-address-space/ > We have just (anecdotally, empirically) established earlier in this thread, that anything smaller than a mid-sized business, can't even *GET* IPv6 easily (at least in the USA); much less care about it. Talking about a "crystal ball", in my view, is just a lot of hand-waving that means "I don't have a real-world example to point to". Talking about "the Next Big Thing" means that somehow, the NBT will be present without any residential or small business broadband users partaking in it. Sounds like a pretty small piece of the pie for the NBT... For the record, I have no dog in this fight; I just think that the rhetoric / fanboi-ism / advocacy level is just a little too high - emotion rather than reason is taking over in the course of debate, which for me at least, is unwelcome. Cordially Patrick From dwhite at olp.net Wed Mar 31 23:07:57 2010 From: dwhite at olp.net (Dan White) Date: Wed, 31 Mar 2010 23:07:57 -0500 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <4BB41871.8050608@zill.net> References: <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> <4BB41871.8050608@zill.net> Message-ID: <20100401040757.GD5032@dan.olp.net> On 31/03/10?23:52?-0400, Patrick Giagnocavo wrote: >We have just (anecdotally, empirically) established earlier in this >thread, that anything smaller than a mid-sized business, can't even >*GET* IPv6 easily (at least in the USA); much less care about it. > >Talking about a "crystal ball", in my view, is just a lot of hand-waving >that means "I don't have a real-world example to point to". > >Talking about "the Next Big Thing" means that somehow, the NBT will be >present without any residential or small business broadband users >partaking in it. Sounds like a pretty small piece of the pie for the NBT... > >For the record, I have no dog in this fight; I just think that the >rhetoric / fanboi-ism / advocacy level is just a little too high - >emotion rather than reason is taking over in the course of debate, which >for me at least, is unwelcome. As a (small) service provider with very stiff competition from much larger providers where I work, we have to have a perfect Crystal Ball, or hedge our bets. Customer needs are constantly changing, and are a constantly moving target. Historically we have a good understanding of what they want. We were the first broadband provider in our footprint for several years, but we have lost customers to competition as well. Technology is most notable when it is disruptive, and is probably most devastating to a company like our's when it is. We will only survive if we are prepared, and that's the same advice I would offer anyone who has a penny to lose in this game. -- Dan White From joelja at bogus.com Wed Mar 31 23:13:36 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 31 Mar 2010 21:13:36 -0700 Subject: 100% want IPv6 - Was: New Linksys CPE, IPv6 ? In-Reply-To: <4BB41871.8050608@zill.net> References: <4BB3B651.1020607@csuohio.edu> <4BB3E363.6000708@foobar.org> <20100401031253.GA5032@dan.olp.net> <4BB4109E.90006@zill.net> <20100401032232.GB5032@dan.olp.net> <4BB41871.8050608@zill.net> Message-ID: <4BB41D70.7000409@bogus.com> On 03/31/2010 08:52 PM, Patrick Giagnocavo wrote: > We have just (anecdotally, empirically) established earlier in this > thread, that anything smaller than a mid-sized business, can't even > *GET* IPv6 easily (at least in the USA); much less care about it. fwiw, that last time I was at a company that needed a prefix, we wrote up an addressing plan, applied, received an assignment, payed our money and were done. if a pool of public addresses are a resource you need to run your business you can secure it, and it's simpler and dealing with for example health insurance. > Talking about a "crystal ball", in my view, is just a lot of hand-waving > that means "I don't have a real-world example to point to". > > Talking about "the Next Big Thing" means that somehow, the NBT will be > present without any residential or small business broadband users > partaking in it. Sounds like a pretty small piece of the pie for the NBT... > > For the record, I have no dog in this fight; I just think that the > rhetoric / fanboi-ism / advocacy level is just a little too high - > emotion rather than reason is taking over in the course of debate, which > for me at least, is unwelcome. > > Cordially > > Patrick > From owen at delong.com Wed Mar 31 18:08:00 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 31 Mar 2010 16:08:00 -0700 Subject: New Linksys CPE, IPv6 ? In-Reply-To: <4BB3B651.1020607@csuohio.edu> References: <4BB3AB96.8050409@bogus.com> <4BB3AD9A.1000603@foobar.org> <4BB3B651.1020607@csuohio.edu> Message-ID: <2EC8CCE1-ADF3-4F67-AEFA-8CBFC8068111@delong.com> On Mar 31, 2010, at 1:53 PM, Michael Holstein wrote: > >> I checked the documentation for two models (Linux model and highest-end non-Linux model), and there's no mention of IPv6. >> > > If this is a strictly "hardware" discussion, v6 "works" on a variety of > models, albeit not with stock firmware. > To wit : http://www.dd-wrt.com/wiki/index.php/IPv6 > > This suggests that Cisco (et.al.) can release an "official" firmware > image to support v6 on existing devices whenever they're sufficiently > motivated to do so. I'd wager the only reason it hasn't been made GA is > to limit the number of "pass-the-buck" support calls that start at $isp > and get bounced back saying "we don't support that yet, call whoever > makes your router". > Not necessarily. dd-wrt lacks the memory expense of the silly web interface that Linksys is oh so fond of implementing in their consumer grade boxen. I suspect that adding features to the Linksys code may be a bit tighter on image and data space than dd-wrt's "stripped down" efficiency. Owen From mike at mtcc.com Mon Mar 29 19:33:23 2010 From: mike at mtcc.com (Michael Thomas) Date: Mon, 29 Mar 2010 17:33:23 -0700 Subject: legacy /8 In-Reply-To: <4BB697EE.4000301@cox.net> References: <4BB65B39.8010902@mompl.net> <2F7E01EC-C405-427F-B9C1-0A5DDB589EF6@consultant.com> <4BB66ED2.6080304@mompl.net> <4BB697EE.4000301@cox.net> Message-ID: <4BB146D3.60104@mtcc.com> Larry Sheldon wrote: > On 4/2/2010 19:25, Randy Bush wrote: > >>> IPv6 as effectively reindroduced classful addressing. >>> >> but it's not gonna be a problem this time, right? after all, >> 32^h^h128^h^h^h64 bits is more than we will ever need, right? >> > > Just like last time. > Oh brother. "Last time" everybody thought it was a geek science experiment at best. With IPv6, IP at least had conquered the known universe. Mike