December 2011 - Test - lists.nanog.org

Colos in Melbourne, FL.
by graham＠g-rock.net 13 Dec '11

13 Dec '11

For those with Colo space in Melbourne FL. Please reply to me offlist; looking to deploy a POP there. Thanks. Sent from my HTC on the Now Network from Sprint!

1 0

128.0.0.0/16 as seen from RIPE Atlas
by Mirjam Kuehne 13 Dec '11

13 Dec '11

Dear colleagues, As a follow-up to the recent article "The Curious Case of 128.0/16", we now looked at 128.0/16 as seen from RIPE Atlas: https://labs.ripe.net/Members/dfk/128.0-16-seen-by-atlas Kind regards, Mirjam Kuehne RIPE NCC

1 0

RE: Verizon[AS 19262] connectivity issues to AS7393
by cody＠killsudo.info 12 Dec '11

12 Dec '11

The client just contacted us again to say that their issue has been resolved. We are still waiting on a updated trace-route to see what has changed. Regards Cody > Not from Verizon, but Verizon's been having routing problems all weekend, > getting much worse yesterday. The nexus may be in the Verizon / Level 3 > handoff, but it may be changing as Verizon routes around the issues. > > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > >> -----Original Message----- >> From: cody(a)killsudo.info [mailto:cody@killsudo.info] >> Sent: Monday, December 12, 2011 1:08 PM >> To: nanog(a)nanog.org >> Subject: Verizon[AS 19262] connectivity issues to AS7393 >> >> We have a client that is complaining of connectivity issues and his >> trace-routes are stopping inside Verizon's network. >> >> 1 <1 ms <1 ms <1 ms Wireless_Broadband_Router.home [192.168.1.1] >> 2 5 ms 4 ms 4 ms L100.NYCMNY-VFTTP-151.verizon-gni.net [98.116.13 4.1] >> 3 8 ms 7 ms 7 ms G11-0-0-1251.NYCMNY-LCR-12.verizon-gni.net [130. >> 81.139.32] >> 4 * * * Request timed out. >> 5 * * * Request timed out. >> >> We have no issues reaching 98.116.134.1 from any of our providers. I >> asked the client to contact Verizon and Verizon tech's are responding >> that the issue is not Verizon. >> >> Any chance someone from Verizon could contact me so we can find the >> real problem? >> >> Thanks >> >> Cody >> > >

1 0

Verizon[AS 19262] connectivity issues to AS7393
by cody＠killsudo.info 12 Dec '11

12 Dec '11

We have a client that is complaining of connectivity issues and his trace-routes are stopping inside Verizon's network. 1 <1 ms <1 ms <1 ms Wireless_Broadband_Router.home [192.168.1.1] 2 5 ms 4 ms 4 ms L100.NYCMNY-VFTTP-151.verizon-gni.net [98.116.13 4.1] 3 8 ms 7 ms 7 ms G11-0-0-1251.NYCMNY-LCR-12.verizon-gni.net [130. 81.139.32] 4 * * * Request timed out. 5 * * * Request timed out. We have no issues reaching 98.116.134.1 from any of our providers. I asked the client to contact Verizon and Verizon tech's are responding that the issue is not Verizon. Any chance someone from Verizon could contact me so we can find the real problem? Thanks Cody

1 0

Verizon 3G/4G Mobile Internet Sales Contact?
by chris 12 Dec '11

12 Dec '11

Hello, If anyone has any contact info for the correct department within Verizon which handles getting a mobile internet service via 3G/4G, that would be a huge help. I am trying to avoid the usual Verizon runaround of being transferred from dept to dept because no one has any idea what I'm talking about. I also would preferably like a static IP if possible. Tried contacting Verizon Wireless and they are trying to sell me a MiFi and have no idea what a static IP is :) Thanks, chris

5 7

Inaccessible network from Verizon, accessible elsewhere.
by NetSecGuy 12 Dec '11

12 Dec '11

I have a Linode VPS in Japan that I can't access from Verizon FIOS, but can access from other locations. I'm not sure who to blame. The host, 106.187.34.33, is behind the gateway 106.187.34.1: >From FIOS to 106.187.34.1 (this works). traceroute to 106.187.34.1 (106.187.34.1), 64 hops max, 52 byte packets 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 9.960 ms 9.957 ms 6.666 ms 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) 12.298 ms 13.463 ms 13.706 ms 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 14.571 ms 14.372 ms 14.003 ms 7 204.255.169.218 (204.255.169.218) 14.692 ms 14.759 ms 13.670 ms 8 sl-crs1-dc-0-1-0-0.sprintlink.net (144.232.19.229) 13.077 ms 12.577 ms 14.954 ms 9 sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.443 ms sl-crs1-dc-0-5-3-0.sprintlink.net (144.232.24.37) 33.005 ms sl-crs1-nsh-0-5-5-0.sprintlink.net (144.232.18.200) 31.507 ms 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 57.610 ms 58.322 ms 59.098 ms 11 otejbb204.kddnet.ad.jp (203.181.100.45) 196.063 ms otejbb203.kddnet.ad.jp (203.181.100.13) 188.846 ms otejbb204.kddnet.ad.jp (203.181.100.21) 195.277 ms 12 cm-fcu203.kddnet.ad.jp (124.215.194.180) 214.760 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 198.925 ms cm-fcu203.kddnet.ad.jp (124.215.194.180) 200.583 ms 13 124.215.199.122 (124.215.199.122) 193.086 ms * 194.967 ms This does not work from FIOS: traceroute to 106.187.34.33 (106.187.34.33), 64 hops max, 52 byte packets 4 so-6-1-0-0.phil-bb-rtr2.verizon-gni.net (130.81.199.4) 34.229 ms 8.743 ms 8.878 ms 5 so-8-0-0-0.lcc1-res-bb-rtr1-re1.verizon-gni.net (130.81.17.3) 15.402 ms 13.008 ms 14.932 ms 6 0.ae2.br1.iad8.alter.net (152.63.32.158) 13.325 ms 13.245 ms 13.802 ms 7 204.255.169.218 (204.255.169.218) 14.820 ms 14.232 ms 13.491 ms 8 lap-brdr-03.inet.qwest.net (67.14.22.78) 90.170 ms 92.273 ms 145.887 ms 9 63.146.26.70 (63.146.26.70) 92.482 ms 92.287 ms 94.000 ms 10 sl-crs1-kc-0-0-0-2.sprintlink.net (144.232.18.112) 58.135 ms 58.520 ms 58.055 ms 11 otejbb203.kddnet.ad.jp (203.181.100.17) 205.844 ms otejbb204.kddnet.ad.jp (203.181.100.25) 189.929 ms otejbb203.kddnet.ad.jp (203.181.100.17) 204.846 ms 12 sl-crs1-oro-0-1-5-0.sprintlink.net (144.232.25.77) 87.229 ms sl-crs1-oro-0-3-3-0.sprintlink.net (144.232.25.207) 88.796 ms 88.717 ms 13 124.215.199.122 (124.215.199.122) 193.584 ms 202.208 ms 192.989 ms 14 * * * Same IP from different network: traceroute to 106.187.34.33 (106.187.34.33), 30 hops max, 60 byte packets 6 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) 2.230 ms 1.847 ms 1.938 ms 7 ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) 2.010 ms 1.985 ms ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 1.942 ms 8 ae-94-94.ebr4.Washington1.Level3.net (4.69.134.189) 12.515 ms ae-74-74.ebr4.Washington1.Level3.net (4.69.134.181) 12.519 ms 12.507 ms 9 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 65.957 ms 65.958 ms 66.056 ms 10 ae-83-83.csw3.LosAngeles1.Level3.net (4.69.137.42) 66.063 ms ae-93-93.csw4.LosAngeles1.Level3.net (4.69.137.46) 65.985 ms ae-63-63.csw1.LosAngeles1.Level3.net (4.69.137.34) 66.026 ms 11 ae-3-80.edge2.LosAngeles9.Level3.net (4.69.144.143) 66.162 ms 66.160 ms 66.238 ms 12 KDDI-AMERIC.edge2.LosAngeles9.Level3.net (4.53.228.14) 193.317 ms 193.447 ms 193.305 ms 13 lajbb001.kddnet.ad.jp (59.128.2.101) 101.544 ms 101.543 ms lajbb002.kddnet.ad.jp (59.128.2.185) 66.563 ms 14 otejbb203.kddnet.ad.jp (203.181.100.13) 164.217 ms 164.221 ms 164.330 ms 15 cm-fcu203.kddnet.ad.jp (124.215.194.164) 180.350 ms cm-fcu203.kddnet.ad.jp (124.215.194.180) 172.779 ms cm-fcu203.kddnet.ad.jp (124.215.194.164) 185.824 ms 16 124.215.199.122 (124.215.199.122) 175.703 ms 175.700 ms 168.268 ms 17 li377-33.members.linode.com (106.187.34.33) 174.381 ms 174.383 ms 174.368 ms The last hop is KDDI, but things work from via Level3 and not sprint. Linode blames Verizon, but I'm not seeing how it's them. Any ideas?

14 22

Re: Sad IPv4 story?
by Keegan Holley 10 Dec '11

10 Dec '11

2011/12/10 <bmanning(a)vacation.karoshi.com> > On Sat, Dec 10, 2011 at 03:15:01AM -0500, Keegan Holley wrote: > > > > > > Sent from my iPhone > > > > On Dec 10, 2011, at 2:58 AM, Randy Bush <randy(a)psg.com> wrote: > > > > >> I just had a personal email from a brand new ISP in the Asia-Pacific > > >> area desperately looking for enough IPv4 to be able to run their > > >> business the way they would likeb & > > > > > > and we are supposed to be surprised or feel sorry? you're kidding, > > > right? they're lucky to be in a/p. at least they can get a /22. > > > > > > i especially like the "the way they would like" part. the way i would > > > like to run my business is to go into the office every friday and scoop > > > up the cash that fell from the sky all week. > > > > > > reality is such a pain in the ass. > > > > > > randy > > > > > +1 aren't we way past all of the predicted exhaustion dates. There are > slot of as's that have ignored this. > > > > > > > predictions are ... predictions! guesses. swag. nothing > more/less. > > i will say this however. after fifteen years, I am exhausted > listening to > > ipv6 v. ipv4 bickering. (and after five years of running native > ipv6-only > > networks - i've re-introduced ipv4 to the mix... go figure) > > /bill > > I see your point. The world was supposed to end dozens of times as well. Sorry to hear you had to reintroduce v4. I suppose if dinosaurs were still around we'd have to capitulate to them too. The people who see a T-rex and say "hey I thought they were extinct?!" would just get eaten. but I digress. I'm not sure I'd open a new ISP at this point and expect to get any respectable amount of IP space from the RIR right now.

2 1

Local Loop at Singapore
by Olivier CALVANO 10 Dec '11

10 Dec '11

Hi anyone have a contact of a local telco for buy a link in metro of the Singapore City ? We want connect a customer based at singapore to our rack of Equinix or * I-Advantage Thanks for your help best regards Olivier *

1 0

best DHCPv6 server?
by Tom Ammon 10 Dec '11

10 Dec '11

Hi All, I'm wondering, what would you say is the best DHCPv6 server for a large enterprise? We've played with dibbler and the ISC server, and have had some interesting (and annoying) results with the ISC server. At first blush, dibbler appears to work better. Thoughts? Tom ----------------------------------------------------------------------------- Tom Ammon Network Engineer M: (801)674-9273 tom.ammon(a)utah.edu Center for High Performance Computing University of Utah http://www.chpc.utah.edu -----------------------------------------------------------------------------

2 1

Writable SNMP
by Keegan Holley 10 Dec '11

10 Dec '11

For a few years now I been wondering why more networks do not use writable SNMP. Most automation solutions actually script a login to the various equipment. This comes with extra code for different vendors, different prompts and any quirk that the developer is aware of and constant patches as new ones come up. Writable SNMP seems like an easier way to deal with scripted configuration changes as well as information gathering. Admittedly, you will have to deal with proprietary mibs and reformat the data once it's returned. Most people consider it insecure, but in reality it's no worse than any other management protocol. Yes I know netconf is better, but in most circles I'd have problems explaining what netconf is, why it's better and that I'm not making it up. So I'll take what I can get.

14 28