nyc glass
anyone have reccos for fiber from 60 hudson to 454 broadway thanks randy
Re: nyc glass
Surely 32 Ave of the Americas would be closer? j On Fri, May 14, 2010 at 3:59 AM, Randy Bush ra...@psg.com wrote: anyone have reccos for fiber from 60 hudson to 454 broadway thanks randy -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org ---
Re: BGP and convergence time
Apologies, kindly ignore my earlier responce. Rgrds, Shake On Fri, May 14, 2010 at 3:46 PM, shake righa ssri...@gmail.com wrote: Believe have narrowed down problem to layer 2. A ping to address 224.0.0.5 shows no reply. Believe problme to do with blocking of multicast Regards, Shake On Fri, May 14, 2010 at 5:28 AM, Frank Bulk frnk...@iname.com wrote: What about IP SLA with some EEM? This link may give you some ideas: http://blog.ioshints.info/2008/01/ospf-default-route-based-on-ip-sla.html Frank -Original Message- From: Jay Nakamura [mailto:zeusda...@gmail.com] Sent: Tuesday, May 11, 2010 1:35 PM To: NANOG Subject: BGP and convergence time So, we have two upstreams, both coming in on Ethernet. One of our switch crashed and rebooted itself. Although we have other paths to egress out the network, because the router's Ethernet interface didn't go down, our router's BGP didn't realize the neighbor was down until default BGP timeout was reached. Our upstream connectivity was out for couple minutes. I am looking for ways to detect neighbor being down faster so traffic can be re-routed faster. I can do BFD internally but the issue is how the upstream is going to detect the outage and stop routing our traffic to that downed link. I have asked both of my upstreams and one said they don't do anything like that, second upstream I am still waiting on the answer. My question is, do other carriers do BFD or any other means to detect the neighbor being down faster than normal BGP will allow? (Both upstreams are major telcos [ATT and Qwest], so I think they are less flexible than some others.) Or, has anyone succeeded in getting something done with those two carriers? Thanks!
Re: nyc glass
On 2010-05-14-03:59:33, Randy Bush ra...@psg.com wrote: anyone have reccos for fiber from 60 hudson to 454 broadway From a cursory look at POP and GIS data not covered by NDA, I'm not finding any vendors currently built into 454 Broadway. The usual suspects for dark in the area include AboveNet, Lightower, and Lexent (Hugh O'Kane), all amenable to build jobs for the right opportunity... HTH, -a
Illinois Tollway dark fiber
Has anyone had any experience working with the Illinois Tollway for dark fiber? Looking for good or bad experiences offline. Thanks! -brandon -- Brandon Galbraith Voice: 630.492.0464
Re: POE switches and lightning
On Thursday 13 May 2010 11:36:35 am Caleb Tennis wrote: I was just curious if anyone had seen anything similar to this before? Our incoming electrical power has surge suppression, and the power to the switches is all through double conversion UPS, so I'm not quite sure why any of them would have been impacted at all. I'm guessing that the strike had some impact on the electrical ground, but I don't know what we can do to prevent future strikes from causing the same issues. Thoughts? Inductively coupled EMP onto the CAT5. I've seen ethernet port chips vaporized on switches. I've even seen holes blown in port interface chips, and the switch continue working (have a DC powered Catalyst 2900XL switch with the center 8 ports in a nonworking state due to EMP from a close strike; the 2900XL is still running fine, just can't use those center eight ports anymore). The building it is installed in is on solar power, and at the time was off- grid. A Siteplayer Telnet was blown, and the eight ports were fried (one of which was connected to the Siteplayer Telnet that got blown) on the switch, but that was the extent of the damage. I'm from a broadcast engineering background, and have seen lightning's effects in many many devices, including vaporized PC traces, etc. Virtually all damage I've seen has been due to either EMP or improperly bonded grounding systems. In particular, if your telecom ground isn't bonded to the electrical NEC safety ground, you will get a voltage difference between the grounds, depending upon the voltage gradient in the ground. Whole books have been written on this subject; I've got one by Polyphaser about nuclear EMP (same concept, larger scale) protection for radio stations. Imagine the lightning bolt's ionization conduction channel as the primary side of many transformers, with every single conductor within many meters being potential secondaries. The closer the secondary, the more coupling. It's a 1:1 turns ratio, too, and so a 100% coupled secondary would give an equal amperage through the secondary. Air-core transformers are loosely coupled at best, but even a tenth of one percent coupling of a 100kiloampere lightning stroke is 100 amps in magnitude. Loosely coupled current transformers, like this, tend to generate large open circuit voltages, too. The most graphic evidence I've seen of the power of lightning-created EMP was made during a strike I saw in June of 1998 at a radio station's studios. The studios were in an old, 1950's vintage school building, built to 1950's civil defense standards for EMP resistance (rebar in a Faraday cage arrangement, metal roof, lightning rods on the roof). There is a 100 foot studio- transmitter link (STL) tower at one end of the building. The STL tower took a direct hit. The Faraday cage rebar verticals embedded in the walls became coupled secondaries, and large currents flowed. Every single CRT monitor in the entire 300 foot long building was left with a rainbow effect on the screen due to the residual magnetism from the EMP. Even monitors that weren't plugged in were rainbowed. Many PC's died that day, but I resurrected several hard drives where I could find identical control boards; no hard drive was unreadable due to magnetic issues, but only electrical (no bad heads or erased sections on the platters; every one I found a compatible replacement control board for was recovered). Made some good money degaussing CRT's that week. (used a bulk tape eraser; turned on the eraser, brought it close to the CRT, worked it over all surfaces, then slowing drew the eraser away from the CRT, and turned it off). The EMP was strong enough that there were a couple of pieces of spare equipment, located in a room less than 30 feet from the tower, that had lightning damage even though they weren't plugged in or connected to anything. One 250MCM ground wire from the tower was vaporized; there were three, and the other two survived, but with noticeable heat-induced discoloration (they were replaced, and the glassed-up ground rods were as well). Engineering estimates of the stroke current were that it was somewhat greater than 200kiloamperes. One of the STL transmitters was damaged, but on the audio side. Neither of the two STL transmitters sustained any RF output damage thanks to the sacrifice of the two daisy-chained Polyphaser arrestors (the arrestors acted as fuses, and had to be replaced, but they're a lot cheaper than a 950MHz Marti STL-10!). One of the two four foot Marti STL dishes had a melted feed, but the other one, which was lower on the tower (about 85 feet up) was undamaged. Fortunately, neither of the two half-inch heliax runs from the dishes were damaged. The 10base-2 LAN took extensive damage, but not every NIC. The most interesting damage was to the RG-58 cable itself, which had holes blown in it every 30 feet or so. Made a good argument to upgrade to 10Base-T
SNMP Monitoring of a Transfer Switch relay
I'm presently doing some research into a SNMP-enabled device to monitor a set of aux contacts on our transfer switch in order to be able to monitor it's status (on generator or on commercial) from our monitoring platform. I've seen a few interesting devices out there that can accomplish this, however I thought I'd query the list to see if anyone has thoughts about a particular unit they've worked with. Thanks in advance, Tom
Weekly Routing Table Report
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-st...@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith p...@cisco.com. Routing Table Report 04:00 +10GMT Sat 15 May, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary BGP routing table entries examined: 321353 Prefixes after maximum aggregation: 148341 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 156858 Total ASes present in the Internet Routing Table: 34007 Prefixes per ASN: 9.45 Origin-only ASes present in the Internet Routing Table: 29525 Origin ASes announcing only one prefix: 14346 Transit ASes present in the Internet Routing Table:4482 Transit-only ASes present in the Internet Routing Table:100 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (36992) 22 Prefixes from unregistered ASNs in the Routing Table: 341 Unregistered ASNs in the Routing Table: 120 Number of 32-bit ASNs allocated by the RIRs:564 Prefixes from 32-bit ASNs in the Routing Table: 636 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:189 Number of addresses announced to Internet: 2216648704 Equivalent to 132 /8s, 31 /16s and 96 /24s Percentage of available address space announced: 59.8 Percentage of allocated address space announced: 65.1 Percentage of available address space allocated: 91.9 Percentage of address space in use by end-sites: 82.7 Total number of prefixes smaller than registry allocations: 154160 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:76802 Total APNIC prefixes after maximum aggregation: 26762 APNIC Deaggregation factor:2.87 Prefixes being announced from the APNIC address blocks: 73469 Unique aggregates announced from the APNIC address blocks:32216 APNIC Region origin ASes present in the Internet Routing Table:4033 APNIC Prefixes per ASN: 18.22 APNIC Region origin ASes announcing only one prefix: 1100 APNIC Region transit ASes present in the Internet Routing Table:622 Average APNIC Region AS path length visible:3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 516278592 Equivalent to 30 /8s, 197 /16s and 201 /24s Percentage of available APNIC address space announced: 76.9 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:133879 Total ARIN prefixes after maximum aggregation:69162 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 106795 Unique aggregates announced from the ARIN address blocks: 41618 ARIN Region origin ASes present in the Internet Routing Table:13695 ARIN Prefixes per ASN: 7.80 ARIN Region origin ASes announcing only one prefix:5278 ARIN Region transit ASes present in the Internet Routing Table:1351 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 730749728 Equivalent to 43 /8s, 142 /16s and 91 /24s Percentage of available ARIN address
Re: ipv6 transit over tunneled connection
- Original Message - From: Christopher Morrow morrowc.li...@gmail.com To: Michael Ulitskiy mulits...@acedsl.com Cc: nanog@nanog.org Sent: Thursday, 13 May, 2010 6:39:28 PM Subject: Re: ipv6 transit over tunneled connection On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy mulits...@acedsl.com wrote: Hello, We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial? 1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't tunnels are bad, always. -chris I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 states the use of tunnels). If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in IPv6 tunnels, how will we work with jumbo packets?
RE: SNMP Monitoring of a Transfer Switch relay
I've had good luck with devices from DPS; http://www.dpstele.com/ -Keith -Original Message- From: Tom Beecher [mailto:tbeec...@localnet.com] Sent: Friday, May 14, 2010 2:00 PM To: nanog@nanog.org Subject: SNMP Monitoring of a Transfer Switch relay I'm presently doing some research into a SNMP-enabled device to monitor a set of aux contacts on our transfer switch in order to be able to monitor it's status (on generator or on commercial) from our monitoring platform. I've seen a few interesting devices out there that can accomplish this, however I thought I'd query the list to see if anyone has thoughts about a particular unit they've worked with. Thanks in advance, Tom
Re: ipv6 transit over tunneled connection
I agree - if you can get native v6 transit then more power to you. But tunnels are sure better than no IPv6 connectivity in my mind. Aside from slight performance/efficiency issues, I've never had an issue. -Jack Carrozzo On Fri, May 14, 2010 at 2:29 PM, Franck Martin fra...@genius.com wrote: - Original Message - From: Christopher Morrow morrowc.li...@gmail.com To: Michael Ulitskiy mulits...@acedsl.com Cc: nanog@nanog.org Sent: Thursday, 13 May, 2010 6:39:28 PM Subject: Re: ipv6 transit over tunneled connection On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy mulits...@acedsl.com wrote: Hello, We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial? 1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't tunnels are bad, always. -chris I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 states the use of tunnels). If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in IPv6 tunnels, how will we work with jumbo packets?
Re: ipv6 transit over tunneled connection
I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. What parts of the big I Internet are not enabled or ready? - Jared On May 14, 2010, at 2:43 PM, Jack Carrozzo wrote: I agree - if you can get native v6 transit then more power to you. But tunnels are sure better than no IPv6 connectivity in my mind. Aside from slight performance/efficiency issues, I've never had an issue. -Jack Carrozzo
Re: SNMP Monitoring of a Transfer Switch relay
On 5/14/2010 10:59, Tom Beecher wrote: I'm presently doing some research into a SNMP-enabled device to monitor a set of aux contacts on our transfer switch in order to be able to monitor it's status (on generator or on commercial) from our monitoring platform. I've seen a few interesting devices out there that can accomplish this, however I thought I'd query the list to see if anyone has thoughts about a particular unit they've worked with. I went a different way with my electrical gear and used modbus. For me, the benefits are multiple devices on the 485 bus, monitoring lots of parameters and I can execute remote commands. I paid something like $300 for the xfer switch modbus card, which was cheaper than any SNMP contact closure device I could find at the time. I talk to it using Perl Modbus::Client with my monitoring server as the modbus master. It ended up being less of a hassle and much more flexible in the long run. You may or may not have your mind set on dry contact monitoring, but it's something to think about. ~Seth
Re: ipv6 transit over tunneled connection
On Fri, May 14, 2010 at 2:29 PM, Franck Martin fra...@genius.com wrote: I said somewhere in here... wierd quoting happened. On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy mulits...@acedsl.com wrote: Hello, We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial? 1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't tunnels are bad, always. -chris I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 states the use of tunnels). Tunnels promote poor paths, they bring along LOTS of issues wrt PMTUD, asymmetry of paths, improper/inefficient paths (see example paths from several ripe preso's by jereon/others), longer latency. If the tunnel exits your border you can't control what happens and you can't affect that tunnels performance characteristics. it's 2010, get native v6. If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in IPv6 tunnels, how will we work with jumbo packets? a non-negligible part of the ipv6 internet doesn't work at all with 1280 mtu... due to tunnels and some other hackery :( jumbo packets are a fiction, everyone should stop 10 years ago believing they will ever work end-to-end between random sites. -Chris
Re: ipv6 transit over tunneled connection
On 5/14/2010 11:49, Jared Mauch wrote: I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. What parts of the big I Internet are not enabled or ready? Verizon has POPs that aren't IPv6 enabled making it a pain in the ass if you're closer to one of those (currently on month 11 of waiting, I'm just letting it go because I'm curious how long it'll take), Sprint isn't doing native IPv6 with their GSR's yet, Cogent's IPv6 visibility is poor, Level3 isn't accepting new IPv6 beta connections, and ATT simply told me not available yet. Tunnels are still a necessity. ~Seth
Re: ipv6 transit over tunneled connection
On Fri, May 14, 2010 at 3:00 PM, Seth Mattinen se...@rollernet.us wrote: On 5/14/2010 11:49, Jared Mauch wrote: I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. What parts of the big I Internet are not enabled or ready? Verizon has POPs that aren't IPv6 enabled making it a pain in the ass if you're closer to one of those (currently on month 11 of waiting, I'm just letting it go because I'm curious how long it'll take), Sprint isn't doing native IPv6 with their GSR's yet, Cogent's IPv6 visibility is poor, Level3 isn't accepting new IPv6 beta connections, and ATT simply told me not available yet. Tunnels are still a necessity. twt, ntt, gblx, telia all have presence in the US, and all do v6 to customer links. vote with wallet.
Re: ipv6 transit over tunneled connection
(Sent from my Blackberry, please avoid the flames as I can't do inline quoting) Native IPv6 is a crapshoot. About the only people in the US that I've seen that are no-bullshit IPv6 native ready is Hurricane Electric. NTT is supposedly as well but I can't speak as to where they have connectivity. Being that there's issues that leave us unable to get native connectivity, we have a BGP tunnel thanks to HE (with a 20ms latency from Seattle to Freemont). Tunnels suck if not done correctly. We sometimes have faster and more reliable connections through IPv6, so ymmv. Brielle --Original Message-- From: Jared Mauch To: Jack Carrozzo Cc: nanog@nanog.org Subject: Re: ipv6 transit over tunneled connection Sent: May 14, 2010 12:49 PM I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. What parts of the big I Internet are not enabled or ready? - Jared On May 14, 2010, at 2:43 PM, Jack Carrozzo wrote: I agree - if you can get native v6 transit then more power to you. But tunnels are sure better than no IPv6 connectivity in my mind. Aside from slight performance/efficiency issues, I've never had an issue. -Jack Carrozzo -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org
IPv6 eyeballs?
Hi all, This seems like the proper time to ask, seeing how many people are there asking for IPv6 transit - does anyone have any kind of stats how many eyeballs are there that have IPv6, and are there any of them that have a better service over v6 that over v4 (my guess here is universities or other academical institutions that have really big v6 pipes)? The reason for this question is that s few weeks ago I wrote an initial list of what we (as a medium-sized content provider) need to do to be able to push traffic over v6, and with careful testing and everything it should fit in six months. What's not known is it worth to start implementing it. We pretty much accept as given that no carrier will limit its own users to v6 only in the near (1-2-3 year) future, but with stuff like CGN/LSN degradation could be expected to show up in the v4 service. -- Regards, Vasil Kolev signature.asc Description: Това е цифрово подписана част от писмото
Re: SNMP Monitoring of a Transfer Switch relay
I have used the APC Environmental Manager (EMU) to do this. In our case we ran a 4-pair line from the generator to the EMU. One pair was connected to the EMU so that we could monitor and alert on the run-cycles of the generator. Our transfer switch did not have these capabilities, but you could apply the same configuration we used for out generator. The EMU has built-in alerting as well as the ability to send SNMP traps. - Chris On Fri, May 14, 2010 at 1:59 PM, Tom Beecher tbeec...@localnet.com wrote: I'm presently doing some research into a SNMP-enabled device to monitor a set of aux contacts on our transfer switch in order to be able to monitor it's status (on generator or on commercial) from our monitoring platform. I've seen a few interesting devices out there that can accomplish this, however I thought I'd query the list to see if anyone has thoughts about a particular unit they've worked with. Thanks in advance, Tom
Re: SNMP Monitoring of a Transfer Switch relay
On Fri, May 14, 2010 at 10:59 AM, Tom Beecher tbeec...@localnet.com wrote: I'm presently doing some research into a SNMP-enabled device to monitor a set of aux contacts on our transfer switch in order to be able to monitor it's status (on generator or on commercial) from our monitoring platform. I've seen a few interesting devices out there that can accomplish this, however I thought I'd query the list to see if anyone has thoughts about a particular unit they've worked with. I've found the Weathergoose II to be a good general-purpose SNMP monitoring device. They also have something called the Relaygoose which can accommodate more inputs and trigger relays as well. http://www.itwatchdogs.com/p_product_detail.php?pnum=1 -Nick
Re: nyc glass
anyone have reccos for fiber from 60 hudson to 454 broadway From a cursory look at POP and GIS data not covered by NDA, I'm not finding any vendors currently built into 454 Broadway. later word from the customer is s/454/434/. g. randy
Re: SNMP Monitoring of a Transfer Switch relay
Once upon a time, Tom Beecher tbeec...@localnet.com said: I'm presently doing some research into a SNMP-enabled device to monitor a set of aux contacts on our transfer switch in order to be able to monitor it's status (on generator or on commercial) from our monitoring platform. I've seen a few interesting devices out there that can accomplish this, however I thought I'd query the list to see if anyone has thoughts about a particular unit they've worked with. We have some old NetBotz (now part of APC) in our NOC, and ours have dry contact ports, so we hooked one up to our transfer switch. Works like a champ. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: ipv6 transit over tunneled connection
3) don't tunnel beyond your borders, really just don't tunnels are bad, always. you are understaing your case. randy
Re: ipv6 transit over tunneled connection
GBLX was great with native IPv6 setup. VZB was nearly impossible to get them to set it up, and I'm tunneled to a router halfway across the country. The router I was going to had serious PMTU issues that they recently cleared up, so now it's working satisfactorily. -Paul Brielle Bruns wrote: (Sent from my Blackberry, please avoid the flames as I can't do inline quoting) Native IPv6 is a crapshoot. About the only people in the US that I've seen that are no-bullshit IPv6 native ready is Hurricane Electric. NTT is supposedly as well but I can't speak as to where they have connectivity. Being that there's issues that leave us unable to get native connectivity, we have a BGP tunnel thanks to HE (with a 20ms latency from Seattle to Freemont). Tunnels suck if not done correctly. We sometimes have faster and more reliable connections through IPv6, so ymmv. Brielle --Original Message-- From: Jared Mauch To: Jack Carrozzo Cc: nanog@nanog.org Subject: Re: ipv6 transit over tunneled connection Sent: May 14, 2010 12:49 PM I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. What parts of the big I Internet are not enabled or ready? - Jared On May 14, 2010, at 2:43 PM, Jack Carrozzo wrote: I agree - if you can get native v6 transit then more power to you. But tunnels are sure better than no IPv6 connectivity in my mind. Aside from slight performance/efficiency issues, I've never had an issue. -Jack Carrozzo
BGP Update Report
BGP Update Report Interval: 06-May-10 -to- 13-May-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS982914118 1.5% 38.0 -- BSNL-NIB National Internet Backbone 2 - AS453811556 1.2% 148.2 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS10113 10587 1.1% 179.4 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 4 - AS28477 10116 1.1%1124.0 -- Universidad Autonoma del Esstado de Morelos 5 - AS359319430 1.0%3143.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - AS5800 9259 1.0% 41.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 7 - AS8452 9054 0.9% 8.8 -- TEDATA TEDATA 8 - AS417868901 0.9% 423.9 -- ERTH-YOLA-AS CJSC Company ER-Telecom Yoshkar-Ola 9 - AS6389 7069 0.7% 6.5 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 10 - AS4847 6616 0.7% 82.7 -- CNIX-AP China Networks Inter-Exchange 11 - AS3549 6452 0.7% 96.3 -- GBLX Global Crossing Ltd. 12 - AS5976 5937 0.6% 52.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS8386 5868 0.6% 70.7 -- KOCNET KOCNET-AS 14 - AS8151 5820 0.6% 12.2 -- Uninet S.A. de C.V. 15 - AS308905705 0.6% 13.0 -- EVOLVA Evolva Telecom s.r.l. 16 - AS179745430 0.6% 13.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 17 - AS145225075 0.5% 16.1 -- Satnet 18 - AS369924866 0.5% 13.3 -- ETISALAT-MISR 19 - AS114924655 0.5% 10.9 -- CABLEONE - CABLE ONE, INC. 20 - AS256204578 0.5% 29.3 -- COTAS LTDA. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS359319430 1.0%3143.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS487542686 0.3%2686.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 3 - AS296612401 0.2%2401.0 -- INTI-AS INTI Autonomous System 4 - AS456702285 0.2%2285.0 -- SOFTCRYLICNET1-IN #160,North Usman Road, Third Floor 5 - AS130041695 0.2%1695.0 -- SOX Serbian Open Exchange 6 - AS28477 10116 1.1%1124.0 -- Universidad Autonoma del Esstado de Morelos 7 - AS31557 939 0.1% 939.0 -- IGT-MOLD-NET-AS IGT Communications AS 8 - AS3397 896 0.1% 896.0 -- DAVINCI - Davinci Broadband Inc. 9 - AS11613 806 0.1% 806.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 10 - AS282852939 0.3% 734.8 -- World Line Ltda 11 - AS4387 2863 0.3% 715.8 -- Secretaria de Ciencia y Tecnologia - Red Cientific 12 - AS530651849 0.2% 462.2 -- 13 - AS183991835 0.2% 458.8 -- BAGAN-TRANSIT-AS Bagan Cybertech IDC Teleport International Transit 14 - AS303411307 0.1% 435.7 -- SCTA-ASN - South Central Telephone Association 15 - AS417868901 0.9% 423.9 -- ERTH-YOLA-AS CJSC Company ER-Telecom Yoshkar-Ola 16 - AS8038 403 0.0% 403.0 -- 6CONNECT - 6connect, Inc. 17 - AS27560 796 0.1% 398.0 -- ULTCO - Universal Leaf Tobacco Company Inc. 18 - AS104452368 0.2% 394.7 -- HTG - Huntleigh Telcom 19 - AS28052 380 0.0% 380.0 -- Arte Radiotelevisivo Argentino 20 - AS43914 341 0.0% 341.0 -- ECCO-AS Ecco Holiday Sp. z o.o. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 58.207.96.0/1910719 1.0% AS4538 -- ERX-CERNET-BKB China Education and Research Network Center 2 - 200.13.36.0/2410092 1.0% AS28477 -- Universidad Autonoma del Esstado de Morelos 3 - 188.187.184.0/24 8639 0.8% AS41786 -- ERTH-YOLA-AS CJSC Company ER-Telecom Yoshkar-Ola 4 - 64.76.40.0/24 6024 0.6% AS3549 -- GBLX Global Crossing Ltd. 5 - 198.140.43.0/245710 0.6% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 205.91.160.0/204083 0.4% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 7 - 63.211.68.0/22 3711 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 206.184.16.0/242938 0.3% AS174 -- COGENT Cogent/PSI 9 - 91.212.23.0/24 2686 0.3% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 10 - 143.138.107.0/24 2443 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 11 - 202.92.235.0/242419 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 12 - 193.16.43.0/24 2401 0.2% AS29661 -- INTI-AS INTI Autonomous System 13 - 202.89.118.0/242285 0.2% AS45670 -- SOFTCRYLICNET1-IN #160,North Usman Road, Third Floor 14 - 193.16.111.0/242153 0.2% AS15836 -- AXAUTSYS ARAX I.S.P. AS31557 -- IGT-MOLD-NET-AS
Re: ipv6 transit over tunneled connection
On May 14, 2010, at 1:36 PM, Jared Mauch wrote: On May 14, 2010, at 3:43 PM, Brielle Bruns wrote: (Sent from my Blackberry, please avoid the flames as I can't do inline quoting) Native IPv6 is a crapshoot. About the only people in the US that I've seen that are no-bullshit IPv6 native ready is Hurricane Electric. NTT is supposedly as well but I can't speak as to where they have connectivity. I can say that we (NTT) have been IPv6 enabled or ready at all customer ports since ~2003. Anyone else who has not gotten there in the intervening years may have problems supporting you for your IPv4 as well :) I had native eBGP with NTT in Dec 2005..this is when I was working with Connection By Boeing in Seattle. Worked like a charm. And yes, since I now live in Seattle, I have heard of some others doing native although haven't validated. Being that there's issues that leave us unable to get native connectivity, we have a BGP tunnel thanks to HE (with a 20ms latency from Seattle to Freemont). You should be able to get native IPv6 in Seattle from a variety of providers. If you're not finding it, you're not really looking (IMHO). I'd 2nd that Tunnels suck if not done correctly. We sometimes have faster and more reliable connections through IPv6, so ymmv. The tunneled part of the IPv6 internet fell to the wayside a long time ago, there are stragglers and I have even seen people try to peer over tunnels in 2010, but anyone still adding that level of overlay (v6-over-v4) may find themselves in a world of hurt soon enough. - Jared (Curious about what incumbent carrier plans are for end- user - eg qwest, att, vz resi)
Re: ipv6 transit over tunneled connection
On Fri, 2010-05-14 at 14:57 -0400, Christopher Morrow wrote: Tunnels promote poor paths promote? Tunnel topology does not (necessarily) match the underlying topology, especially if you choose (or are forced to accept) a distant broker. But promote? , they bring along LOTS of issues wrt PMTUD, PMTUD that doesn't work on v6 probably doesn't work on v4. I agree that a bad PMTU can wreak more havoc on v6 than v4, but most of the issues are workaroundable. asymmetry of paths, improper/inefficient paths (see example paths from several ripe preso's by jereon/others), longer latency. All relating to the above. I suspect you really mean paths in the underlying topology, which is a by definition issue. None of these are necessary features of tunnels. Given the relatively low number of tunnel terminating services, and the fairly low level of choice available to people who want tunnels, these are bigger problems than they need to be. More demand will see these problems (as with so many transitional issues) lessen substantially. If the tunnel exits your border you can't control what happens and you can't affect that tunnels performance characteristics. Whereas with IPv4 you have complete control over everything that happens once packets exit your border? This is no different with IPv6 than with IPv4, except that you have fewer choices at present, so must make more drastic compromises. it's 2010, get native v6. Easily said :-( If you can't get native IPv6, then using a tunnel lets you get started; it lets you begin educating, testing and even delivering IPv6-based services. If, on the other hand, you wait until everything is perfect, you will be wy behind the eight-ball. Oh - and tunnels are usually way cheaper than native connectivity, so it's easier to get the idea of going v6 past the bean-counters. So: Yep, native IPv6 if you can get it. Otherwise, take tunnels. But whichever you do, do it now. Regards, K. -- ~~~ Karl Auer (ka...@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 signature.asc Description: This is a digitally signed message part
Re: ipv6 transit over tunneled connection
On 5/14/2010 12:44, Christopher Morrow wrote: On Fri, May 14, 2010 at 3:00 PM, Seth Mattinen se...@rollernet.us wrote: On 5/14/2010 11:49, Jared Mauch wrote: I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. What parts of the big I Internet are not enabled or ready? Verizon has POPs that aren't IPv6 enabled making it a pain in the ass if you're closer to one of those (currently on month 11 of waiting, I'm just letting it go because I'm curious how long it'll take), Sprint isn't doing native IPv6 with their GSR's yet, Cogent's IPv6 visibility is poor, Level3 isn't accepting new IPv6 beta connections, and ATT simply told me not available yet. Tunnels are still a necessity. twt, ntt, gblx, telia all have presence in the US, and all do v6 to customer links. vote with wallet. Yeah I hear that a lot, but out of those four the only one that will serve my area is global crossing. ~Seth
Re: POE switches and lightning
On May 13, 2010, at 2:26 PM, Mark Mayfield wrote: About a month ago, we had a lightning strike near our main campus. We lost one POE Cisco 3560 completely (apparently blown power supply), and in a separate but nearby building, another 3560 lost the ability to deliver POE, but continued to operate as a switch. Both had to be replaced. Both were on wiring closet type UPS'es with surge suppression, and those were unaffected. Mark -Original Message- From: Caleb Tennis [mailto:caleb.ten...@gmail.com] Sent: Thursday, May 13, 2010 10:37 AM To: North American Network Operators Group Subject: POE switches and lightning We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. What's interesting is that various POE switches throughout the entire building seemed to be affected in that some of their ports they just shut down/off. Rebooting these switches brought everything back to life. It didn't impact anything non-POE, and even then, only impacted some devices. But it was spread across the whole building, across multiple switches. I was just curious if anyone had seen anything similar to this before? Our incoming electrical power has surge suppression, and the power to the switches is all through double conversion UPS, so I'm not quite sure why any of them would have been impacted at all. I'm guessing that the strike had some impact on the electrical ground, but I don't know what we can do to prevent future strikes from causing the same issues. Thoughts? It is not clear to me from the above if there are copper circuits coming into the building, but lightning can certainly zap those as well. In very high impact areas (such as mountaintops or Miami) it is a good idea to mandate that all incoming / outgoing circuits are on fiber, without exception. Marshall Confidentiality Statement: The documents accompanying this transmission contain confidential information that is legally privileged. This information is intended only for the use of the individuals or entities listed above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or action taken in reliance on the contents of these documents is strictly prohibited. If you have received this information in error, please notify the sender immediately and arrange for the return or destruction of these documents.
Re: ipv6 transit over tunneled connection
On May 14, 2010, at 11:57 AM, Christopher Morrow wrote: On Fri, May 14, 2010 at 2:29 PM, Franck Martin fra...@genius.com wrote: I said somewhere in here... wierd quoting happened. On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy mulits...@acedsl.com wrote: Hello, We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial? 1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't tunnels are bad, always. -chris I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 states the use of tunnels). Tunnels promote poor paths, they bring along LOTS of issues wrt PMTUD, asymmetry of paths, improper/inefficient paths (see example paths from several ripe preso's by jereon/others), longer latency. If the tunnel exits your border you can't control what happens and you can't affect that tunnels performance characteristics. it's 2010, get native v6. I will point out that most of these issues apply to 6to4 and Teredo auto- tunnels and not as much to GRE or 6in4 statically configured tunnels. There is a juniper bug which makes PMTU-D a problem if your tunnel is Juniper-Juniper. If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in IPv6 tunnels, how will we work with jumbo packets? a non-negligible part of the ipv6 internet doesn't work at all with 1280 mtu... due to tunnels and some other hackery :( jumbo packets are a fiction, everyone should stop 10 years ago believing they will ever work end-to-end between random sites. Jumbo packets do work end to end in some random cases and PMTU-D works in most others. All of the tunnels I am using have at least a 1280 MTU, so, I'm not sure why you would think a tunnel wouldn't support 1280. Owen
Re: ipv6 transit over tunneled connection
On May 14, 2010, at 1:36 PM, Jared Mauch wrote: On May 14, 2010, at 3:43 PM, Brielle Bruns wrote: (Sent from my Blackberry, please avoid the flames as I can't do inline quoting) Native IPv6 is a crapshoot. About the only people in the US that I've seen that are no-bullshit IPv6 native ready is Hurricane Electric. NTT is supposedly as well but I can't speak as to where they have connectivity. I can say that we (NTT) have been IPv6 enabled or ready at all customer ports since ~2003. Anyone else who has not gotten there in the intervening years may have problems supporting you for your IPv4 as well :) True. Being that there's issues that leave us unable to get native connectivity, we have a BGP tunnel thanks to HE (with a 20ms latency from Seattle to Freemont). You should be able to get native IPv6 in Seattle from a variety of providers. If you're not finding it, you're not really looking (IMHO). Depends. If he's in the Westin or some other colo, sure. If not, he may have last-mile expenses that exceed sanity for his situation leading to a tunneled solution. Tunnels suck if not done correctly. We sometimes have faster and more reliable connections through IPv6, so ymmv. The tunneled part of the IPv6 internet fell to the wayside a long time ago, there are stragglers and I have even seen people try to peer over tunnels in 2010, but anyone still adding that level of overlay (v6-over-v4) may find themselves in a world of hurt soon enough. I have to disagree with you here. Given the proportion of the IPv6 internet that is still connected via tunnels, your statement simply doesn't really hold. I will readily agree that where possible, native connections beat tunnels. However, tunnels can be a cost effective alternative where native connectivity is not yet readily available and they still work quite well if properly configured and structured. Owen
Re: POE switches and lightning
We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. Perhaps there was a move of the earth-level relative to the neutral line. I have no idea how neutral-line to earth potential is handled in us, but here in austria we use a so called nullung. That means that the earth-ground potential line of the building (which includes also the lightning conductor) is connected to the neutral power line where it enters the building, keeping this potential-difference low. Theres also a potential between earth ground and the neutral-phase of the online-ups. The ethernet-cables; utp or stp? pannels correctly earthed? Perhaps a electrician should check the earthing. Also all copper lines that enter the building should be protected by lightning protectors. Kind regards, Ingo Flaschberger
Contacts re email deliverability problem to tmomail.net?
Hi, folks, A client of mine is having trouble delivering (legitimate) email to tmomail.net, and I'm having trouble finding the right contact. (e.g. postmaster bounced). I've verified the legitimate nature of the email (only user-initiated, and nothing more), the valid SPF, A, PTR, and MX records, etc. We're also having no trouble sending the equivalent messages to the email-to-SMS gateways at ATT Wireless, Verizon Wireless, Sprint, etc. Any suggestions for the best points of contact at T-Mobile USA (tmomail.net)? thanks! Graham Freeman graham.free...@cernio.com (Email/Jabber/SIP) +1 415 462 2991 (office)
Re: POE switches and lightning
On 5/14/2010 16:42, Ingo Flaschberger wrote: We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. Perhaps there was a move of the earth-level relative to the neutral line. I have no idea how neutral-line to earth potential is handled in us, but here in austria we use a so called nullung. That means that the earth-ground potential line of the building (which includes also the lightning conductor) is connected to the neutral power line where it enters the building, keeping this potential-difference low. In the US neutral and earth ground are supposed to be bonded only once at the service entrance. A separate ground from the neutral conductor is carried to sub-panels where is it not bonded. Additional bonding can cause weirdness and will turn the ground into a current carrying conductor. However, an older building I used to be in (built 1978) only gave me a neutral with bonded subs, so you'll run into all kinds of stuff depending on the age of the building. Working at a university was particularly interesting with of the vast range of building ages. ~Seth
Re: POE switches and lightning
On 5/14/2010 19:00, Seth Mattinen wrote: On 5/14/2010 16:42, Ingo Flaschberger wrote: We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. Perhaps there was a move of the earth-level relative to the neutral line. I have no idea how neutral-line to earth potential is handled in us, but here in austria we use a so called nullung. That means that the earth-ground potential line of the building (which includes also the lightning conductor) is connected to the neutral power line where it enters the building, keeping this potential-difference low. In the US neutral and earth ground are supposed to be bonded only once at the service entrance. A separate ground from the neutral conductor is carried to sub-panels where is it not bonded. Additional bonding can cause weirdness and will turn the ground into a current carrying conductor. However, an older building I used to be in (built 1978) only gave me a neutral with bonded subs, so you'll run into all kinds of stuff depending on the age of the building. Working at a university was particularly interesting with of the vast range of building ages. In my experience, each building has a building ground-point at the service entrance, as outlined. I the problem in a campus on some soils is that building grounds might be several volts apart--except during thunder storms when the voltage difference might be (it appears) thousands of volts, and with a lightning strike to one of them many thousands of volts. That is why I argue for glass only between buildings. I don't care how much PoE saves. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: Contacts re email deliverability problem to tmomail.net?
On Fri, May 14, 2010 at 5:52 PM, Graham Freeman jah...@gmail.com wrote: A client of mine is having trouble delivering (legitimate) email to tmomail.net, and I'm having trouble finding the right contact. I just tested, and was able to successfully send an email to my Tmobile address [myphon...@tmomail.net. Are you getting bounces / failures back that are of any use? Also FWIW (and sanity check) any reason why your client wants to use email-to-SMS, rather than just SMS. From what I understand email-to-sms isn't the best platform for getting messages to mobile devices but I may be missing some client-specific visibility. --Jaren
Re: Contacts re email deliverability problem to tmomail.net?
On 14 May 10, at 17:23 , Jaren Angerbauer wrote: I just tested, and was able to successfully send an email to my Tmobile address [myphon...@tmomail.net. Are you getting bounces / failures back that are of any use? Also FWIW (and sanity check) any reason why your client wants to use email-to-SMS, rather than just SMS. From what I understand email-to-sms isn't the best platform for getting messages to mobile devices but I may be missing some client-specific visibility. Hi, Jaren, Delivering SMS-to-SMS would be impractical and prohibitively expensive. This is for an iPhone messaging app that optionally delivers messages to SMS recipients for free. The business model depends on email-to-SMS gateways. Like you, we were able to deliver messages in low volumes, but as the app became increasingly popular (at one point in the Top 20 in the App Store) the volume exceeded a opaque-to-us rate limit at Tmobile, but not at other mobile providers - some of whom we're sending many more messages than we ever tried to deliver to Tmobile. Two examples out of thousands: Apr 30 23:52:52 pomelo.borange.com postfix/error[17836]: [ID 197553 mail.info] D44451D9570: to=[...@tmomail.net, relay=none, delay=80196, delays=80195/0.18/0/0, dsn=4.0.0, status=deferred (delivery temporarily suspended: host mm3.tmomail.net[66.94.25.228] refused to talk to me: 421 mail.tmail.com closing connection) May 1 16:17:58 pomelo.borange.com postfix/smtp[24906]: [ID 197553 mail.info] 7CC5D1E9D7F: to=[...@tmomail.net, relay=mm3.tmomail.net[66.94.9.228]:25, delay=59233, delays=59229/0/4.2/0, dsn=4.0.0, status=deferred (host mm3.tmomail.net[66.94.9.228] refused to talk to me: 421 mail.tmail.com closing connection) thanks, Graham
Re: Contacts re email deliverability problem to tmomail.net?
On Fri, May 14, 2010 at 7:33 PM, Graham Freeman jah...@gmail.com wrote: Delivering SMS-to-SMS would be impractical and prohibitively expensive. This is for an iPhone messaging app that optionally delivers messages to SMS recipients for free. The business model depends on email-to-SMS gateways. I'm surprised more gateways aren't rate limiting or blocking you; my experience with these services is such that the providers really want you to utilize SMS instead, if you build up any sort of significant volume. I've certainly seen multiple providers delay this inbound mail periodically. Cheers, Al Iverson
Stand alone voltage/etc monitoring?
NANOG, How can I best monitor power quality (ie: voltage, etc) as a colo customer? We monitor temperature and humidity in multiple places on each floor we are on, network bandwidth/errors/latency/pps/link-state on every link, power used per circuit, tons of metrics on servers, but I can't seem to find a simple and small way to monitor voltage, etc. I looked in the routers, cabinet-level switched power-strips (CDUs), switches, and servers, and I don't see anything we already have that can report that info. I see there are probably some small UPSes ($400 or so) that can report this info. Seems silly to buy UPSes to get that info. Is there a quick/small/handy/better way to get power quality info? If so, what is it? I don't own the facility. Thanks! Mike -- Michael J. McCafferty Principal M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more
Re: ipv6 transit over tunneled connection
er... if I may - this whining about the evils of tunnels rings a bit hollow, esp for those who think that a VPN is the right thing to do. --bill On Sat, May 15, 2010 at 08:44:53AM +1000, Karl Auer wrote: On Fri, 2010-05-14 at 14:57 -0400, Christopher Morrow wrote: Tunnels promote poor paths promote? Tunnel topology does not (necessarily) match the underlying topology, especially if you choose (or are forced to accept) a distant broker. But promote? , they bring along LOTS of issues wrt PMTUD, PMTUD that doesn't work on v6 probably doesn't work on v4. I agree that a bad PMTU can wreak more havoc on v6 than v4, but most of the issues are workaroundable. asymmetry of paths, improper/inefficient paths (see example paths from several ripe preso's by jereon/others), longer latency. All relating to the above. I suspect you really mean paths in the underlying topology, which is a by definition issue. None of these are necessary features of tunnels. Given the relatively low number of tunnel terminating services, and the fairly low level of choice available to people who want tunnels, these are bigger problems than they need to be. More demand will see these problems (as with so many transitional issues) lessen substantially. If the tunnel exits your border you can't control what happens and you can't affect that tunnels performance characteristics. Whereas with IPv4 you have complete control over everything that happens once packets exit your border? This is no different with IPv6 than with IPv4, except that you have fewer choices at present, so must make more drastic compromises. it's 2010, get native v6. Easily said :-( If you can't get native IPv6, then using a tunnel lets you get started; it lets you begin educating, testing and even delivering IPv6-based services. If, on the other hand, you wait until everything is perfect, you will be wy behind the eight-ball. Oh - and tunnels are usually way cheaper than native connectivity, so it's easier to get the idea of going v6 past the bean-counters. So: Yep, native IPv6 if you can get it. Otherwise, take tunnels. But whichever you do, do it now. Regards, K. -- ~~~ Karl Auer (ka...@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
Re: ipv6 transit over tunneled connection
On 5/14/10 2:36 PM, Jared Mauch wrote: Being that there's issues that leave us unable to get native connectivity, we have a BGP tunnel thanks to HE (with a 20ms latency from Seattle to Freemont). You should be able to get native IPv6 in Seattle from a variety of providers. If you're not finding it, you're not really looking (IMHO). I can almost guarantee that noone can give us the level of service we get for the price we do - did an awful lot of research back in 2008 to find a new co-loc. We've also had nearly perfect uptime with the only downtime being caused by our own growing pains with equipment that has obsecure bugs relating to ipv4 and ipv6 BGP interactions. Changing providers isn't really an option for us as alternatives are guaranteed to push us over budget. is a limiting factor for us since we're not a business focused on profit. Tunneling is our only option at this point. Tunnels suck if not done correctly. We sometimes have faster and more reliable connections through IPv6, so ymmv. The tunneled part of the IPv6 internet fell to the wayside a long time ago, there are stragglers and I have even seen people try to peer over tunnels in 2010, but anyone still adding that level of overlay (v6-over-v4) may find themselves in a world of hurt soon enough. I'm willing to run the risk that my tunneled connection may have problems - its part of the game of being on the leading edge. rant This is not directed at anyone in particular, but people forget that not everyone has thousands, tens of thousands, hundreds of thousands, etc of money in their budget to accomplish their goals. There are people out there, such as ourselves, that have a very limited budget to work within each month/year. Some of us do what we do out of our own pockets because we like doing it. For example, people have called me crazy for running P3 and P4 era HP DL360/380s instead of the new generation stuff, but those nice new servers cost serious coin, and I don't see people stepping up to fund these upgrades. Just an observation, but I'm fairly sure that I'm not the only one who feels that those with rather high budgets tend to forget that not everyone has the luxury of a virtual blank check. /rant -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: Stand alone voltage/etc monitoring?
On Fri, 2010-05-14 at 17:57 -0700, Michael J McCafferty wrote: I see there are probably some small UPSes ($400 or so) that can report this info. Seems silly to buy UPSes to get that info. Is there a quick/small/handy/better way to get power quality info? If so, what is it? I don't own the facility. I've looked at various inline power monitoring appliances solutions and honestly, most of them will cost more than a small UPS. The question is, where do you want to monitor the voltage? At the input side of the rack-PDU? Are your PDUs manageable? Do you want to monitor voltage to each device (output side of the PDU)? Or do you just want to sample monitor on the side (as opposed to inline) and fed from the same circuit feeding the input side of your PDUs assuming all your equipment/PDUs are receiving the same power quality? I monitor at the UPS for my home systems. My UPSes are APC brand. A SmartUPS 500 w/Web/SNMP card will run you about $350 to $400 and you poll them for input voltage and frequency. Here's a snapshot from a couple of years ago... I do have dirty power. http://farm1.static.flickr.com/226/464847907_c3038c21e4_o.png -- /*=[ Jake Khuon kh...@neebu.net ]=+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==*/
Re: ipv6 transit over tunneled connection
Guys, I've started this thread looking for advice on available options. There's no doubt in my mind that native connectivity is better than tunnels, but unfortunately tunnel is the only way to get me started, 'cause my upstream does not support ipv6 (hopefully just yet) and I have no budget for additional circuits to ipv6-enabled carrier. So my question still stands: is anyone aware of a reasonable tunneled ipv6 transit service (I mean aside from HE tunnel broker)? The load will be really light. I don't expect we'll break a few Mbit/s in the nearest future and when we do then I guess it'll be the time to look for the native transit. Thanks, Michael On Thursday 13 May 2010 18:18:12 Michael Ulitskiy wrote: Hello, We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial? Thanks, Michael
Re: ipv6 transit over tunneled connection
On Fri, May 14, 2010 at 9:58 PM, Brielle Bruns br...@2mbit.com wrote: rant Just an observation, but I'm fairly sure that I'm not the only one who feels that those with rather high budgets tend to forget that not everyone has the luxury of a virtual blank check. /rant awesome, take an old 2800 or 2500, plug in a t1 to one of the providers listed (twt seems like a great choice, or atlantech, who I think also does v6 and seems to offer 300$/mon t1's regularly), run v6 ONLY on that, take the 10/100m ether out the back and v6-up the rest of your network. See, done for 300$/month... the reason I said 'find a provider that does do native v6, terminate there and tunnel or spread-out internally from there' was exactly because spending 'tens of thousands of dollars' right off the bat was probably hard to justify. thanks though. -chris
Re: ipv6 transit over tunneled connection
On Fri, May 14, 2010 at 11:25 PM, Michael Ulitskiy mulits...@acedsl.com wrote: So my question still stands: is anyone aware of a reasonable tunneled ipv6 transit service (I mean aside from HE tunnel broker)? The load will be really light. I don't expect we'll break a few Mbit/s in the nearest future and when we do then I guess it'll be the time to look for the native transit. beware the uTorrent ... (see johnb's notes about this) sixxs i think also had NYC based tunnel boxes, no? http://www.sixxs.net/pops/ usewr01 OCCAID Inc. uschi02 Your.Org, Inc. and I think kloch @carpathia was doing some of this for a time, though perhaps only ASH/PHX ? -chris
Re: Dial Concentrators - TNT / APX8000 R.I.P.
Mark Foster wrote: Thus the wider concern I flagged; if the only source for equipment and spares is the grey market, aren't the vendors missing the boat on something which shouldn't even have a major overhead to maintain? There is no sales of new chassis, which means the manufacturing is shut down. The costs to maintain support and spares for an obsolete platform with a declining customer base and no further sales is quite high for the vendor. If they charged the real cost to provide support to the operator, most likely the operator wouldn't take the support contract. End result: end of support. If the operator /really/ needs to keep it going, they'll figure out a way to spare it. Telcos have been specialists in this regard for a long time. What about developing nations where Internet isn't yet as commonplace as it is in the 'west' ? They skip dialup.
Re: Dial Concentrators - TNT / APX8000 R.I.P.
On 2010-05-14 22:04, Alastair Johnson wrote: Mark Foster wrote: What about developing nations where Internet isn't yet as commonplace as it is in the 'west' ? They skip dialup. dial modems are the end game for a 140 year old technology (300-3400hz pots lines). There is literally no reason if you don't already have that infrastructure that you would expend capital to replicate that sort of physical plant.
