Re: Google contact?
On Thu, 17 Apr 2008, Joel Jaeggli wrote: they have ~6% of the employees of the employees of say verizon and slightly less than the 123 years of cruft that the later has. Verizon is one company in name only. There are so many groups and business units, all with their own inbound numbers and no communication between them. Several hundred left hands and several hundred right hands, if you get my meaning. jms
RE: rack power question
On Mon, 24 Mar 2008, Frank Bulk - iNAME wrote: So perhaps the question isn't so much how many kW's I can pack into a 42U rack, but for the data center designer, what's the best price point if real estate is not a significant issue. Or to say it another way, what kW density per rack will give me the lowest priced capital and operating cost per square foot. Does it really matter if you can only offer 5kW/rack if you can price it at 80% of the guy who can sells a 10kW/rack product? Or is this a tough point for the sales person to make? While there are certainly customers out there who think along these lines, most of the enterprise customers I've run across in the past who would be in the market for data center colo would just as soon play the how-many- servers-can-i-jam-into-this-rack game, which is one part of the how-many-racks-can-i-jam-into-this-cage game for some folks... You might get some traction with the responsible deployment angle, but I could only guess at how much traction... jms
Re: mtu mis-match
On Wed, 19 Mar 2008, ann kok wrote: I have this problem about mtu mismatch Some DSL clients, some are working fine. (browsing...ping ...) Some DSL clients have this problem they can't browse the sites. they can ssh the host but couldn't run the command in the shell prompt ping packet are working fine (no packet lost) Why? but I still don't know why mtu can cause this problem Are you using PPPoE to transport and manage your DSL users, or are they bridged? Ping packets, unless you specifically use a larger packet size, are usually pretty small. Try running ping tests with a larger packet size, say, 1495 bytes, and see if those fail. HTTP, SSH, etc, can easily (and often do) generate packets up to the maximum segment size. That's why MTU mismatches can seem to affect some types of traffic but not others. The 'lowest common denominator' for MTUs is often 1500 bytes, but protocols that need to wrap or tunnel existing packets (GRE, PPPoE, IPSEC, etc) impose some overhead of their own. Unless the MTU or TCP maximum segment size of the original traffic is reduced a bit, the tunneled packets will need to be fragmented for transport across the network. This can lead to performance problems like the ones you're seeing. The magic number for an MTU on PPPoE DSL is 1492 bytes, based on past DSL aggregation work I've done. jms
Re: IPv6 on SOHO routers?
On Thu, 13 Mar 2008, Matthew Moyle-Croft wrote: A friend of mine who works for a company that owns another company that sells consumer CPE said Well, this is a volume business. Why release a feature that isn't being demanded much yet, when we could do it later and sell you ANOTHER CPE to replace the one you just bought?. While it doesn't quality as out-of-the-box v6 support, a Linksys WRT54G with a replacement image like Sveasoft Talisman does claim to support it. I haven't tested it yet on a guinea pig WRT54G, but I'll get around to that at some point soon :) jms
Re: cost of dual-stack vs cost of v6-only [Re: IPv6 on SOHO routers?]
On Thu, 13 Mar 2008, David Conrad wrote: There are already things like http://ipv6.google.com/, True, since yesterday. However, while I applaud their efforts, Google is still primarily a search engine. How much of the content Google serves up is accessible via IPv6? I might suggest reviewing http://bgp.he.net/ipv6-progress-report.cgi... Google is still a search engine, but through many of the products they've grown in-house (GMail, etc...) and acquired (YouTube, etc...), they control a growing amount of content jms
Re: Customer-facing ACLs
On Fri, 7 Mar 2008, Justin Shore wrote: Do you block any customer-facing egress traffic at all? What about ingress? SMTP, NetBIOS, MS-SQL, common proxy ports (3128, 6588)? What ICMP types do you allow or disallow? In my previous life, I worked at a mid-sized ISP. A common practice for bridged DSL customers was to block outbound traffic to the various Netbios ports, along with a few other ports that were added at the time to keep Slammer and friends under control. We also deployed filters through RADIUS that covered much of the same ground for dialup and PPPoE DSL users and it worked reasonably well. I do recall weighing the merits of extending that to drop outbound SMTP to exerything except our mail farm, but it wasn't deployed because there was a geat deal a fear of customer backlash and that it would drive more calls into the call center. jms
Re: what the cause?
On Tue, 19 Feb 2008, Frank wrote: all the AS numbers are the same Are you running this trace from a BGP speaking router on your network? I'm also going to guess you're not taking full BGP routes from your upstreams? What exactly do you think is broken? As for the dropped traceroute probes, are you doing any sort of filtering of ICMP that could account for that? Note that dropped traceroute probes should _not_ be equated to packet loss without further investigation. jms On Feb 19, 2008 10:39 PM, Frank [EMAIL PROTECTED] wrote: Hi guys, Can you help me correct my our router? please see the details below. BTW, our ISP told me that there's no problem with their side but still i can't find any of my configuration that causing this. Looking forward for your help thanks your. ./fRank #traceroute nanog.org Type escape sequence to abort. Tracing the route to nanog.org (198.108.1.50) 1 61.9.31.21.mozcom.net (61.9.31.21)* [AS 6163] *4 msec 4 msec 4 msec 2 fe0-0.peak-7206-border-2.mozcom.net (61.9.0.243)* [AS 6163]* 4 msec 0 msec 0 msec 3 203.177.211.41 *[AS 6163] *4 msec 4 msec 4 msec 4 203.177.59.5 *[AS 6163]* 8 msec 4 msec 4 msec 5 203.177.31.166 *[AS 6163]* 4 msec 8 msec 4 msec 6 203.177.254.185 *[AS 6163]* 180 msec 176 msec 180 msec 7 gi1-16.ccr01.lax04.atlas.cogentco.com (38.104.82.129)* [AS 6163] *184 msec 188 msec 188 msec 8 te4-3.mpd01.lax01.atlas.cogentco.com (154.54.24.69) *[AS 6163]* 352 msec te3-3.mpd01.lax01.atlas.cogentco.com (154.54.24.61)* [AS 6163]* 196 msec 180 msec 9 te2-4.mpd01.iah01.atlas.cogentco.com (154.54.5.101)* [AS 6163] *216 msec te8-2.mpd01.iah01.atlas.cogentco.com (154.54.3.37) *[AS 6163] *216 msec te2-4.mpd01.iah01.atlas.cogentco.com (154.54.5.101) *[AS 6163]* 212 msec 10 te8-3.mpd01.dfw01.atlas.cogentco.com (154.54.2.14) *[AS 6163]* 220 msec te3-2.mpd01.mci01.atlas.cogentco.com (154.54.5.218)* [AS 6163] *228 msec te7-3.mpd01.dfw01.atlas.cogentco.com (154.54.5.129) *[AS 6163]* 220 msec 11 te7-4.mpd01.ord01.atlas.cogentco.com (154.54.2.190) *[AS 6163]* 240 msec te8-2.mpd01.mci01.atlas.cogentco.com (154.54.5.126) *[AS 6163] *232 msec te7-3.mpd01.mci01.atlas.cogentco.com (154.54.3.18) *[AS 6163]* 232 msec 12 vl3489.mpd01.ord03.atlas.cogentco.com (154.54.5.18) *[AS 6163]* 232 msec te2-1.mpd01.ord01.atlas.cogentco.com (154.54.2.234) *[AS 6163]* 228 msec te2-3.mpd01.ord01.atlas.cogentco.com (154.54.7.137) *[AS 6163]* 232 msec 13 * vl3489.mpd01.ord03.atlas.cogentco.com (154.54.5.18)* [AS 6163]* 368 msec 436 msec 14 Merit.demarc.cogentco.com (38.112.7.10) *[AS 6163] *228 msec * fe0-0-0x43.michnet10.mich.net (198.108.22.243) *[AS 6163]* 240 msec 15 fe0-0-0x43.michnet10.mich.net (198.108.22.243) *[AS 6163]* 240 msec nanog.org (198.108.1.50) *[AS 6163] *240 msec fe0-0-0x43.michnet10.mich.net (198.108.22.243) *[AS 6163]* 240 msec -- ./fRank
Re: Blackholing traffic by ASN
On Wed, 30 Jan 2008, Justin Shore wrote: I'm sure all of us have parts of the Internet that we block for one reason or another. I have existing methods for null routing traffic from annoying hosts and subnets on our border routers today (I'm still working on a network blackhole). However I've never tackled the problem by targeting a bad guy's ASN. What's the best option for null routing traffic by ASN? I could always add another deny statement in my inbound eBGP route-maps to match a new as-path ACL for _BAD-ASN_ to keep from accepting their routes to begin with. Are there any other good tricks that I can employ? You could do it with an as-path access-list. Example: router bgp 65500 no auto-summary no synchronization log-neighbor-changes neighbor 1.2.3.4 remote-as 65400 neighbor 1.2.3.4 description UPSTREAM1 neighbor 1.2.3.4 filter-list 10 in neighbor 1.2.3.4 soft-reconfiguration inbound ip as-path access-list 10 deny (_65300)+$ ip as-path access-list 10 permit .* This example should drop any prefixes you receive from your upstream that include 65300 as the origin AS in the AS path, but permit anything else. If you're concerned about prefixes that could have 65300 anywhere in the path, take the $ off of the regex. You could also probably write a route-map to redirect traffic from your network to prefixes from that AS to null0, or to a traffic analsis box. jms I have another question along those same lines. Once I do have my blackhole up and running I can easily funnel hosts or subnets into the blackhole. What about funneling all routes to a particular ASN into the blackhole? Are there any useful tricks here? The ASN I'm referring to is that of the Russian Business Network. A Google search should turn up plenty of info for those that haven't heard of them.
Re: DreamHost Contact?
On Mon, 31 Dec 2007, Leigh Porter wrote: Stasiniewicz, Adam wrote: I am 99.9% sure that after successfully hosting websites for Al-Qaeda for over 3 years (on US based servers, by US citizens, living in the US) they are not going to care much about some SSH port scan. Isn't this what you folks call freedom of speech ? There are exceptions to that particular freedom, and many of those exceptions have pretty well-established legal precedents. The First Amendment has been well tested in court. I would think that a website operating inside the US that is providing a communications channel for terrorist groups that have an established pattern of wanting to harm the interests of the US and other countries would fall into one of those well tested exemptions, particularly after 9/11. jms
Re: IEEE 40GE 100GE
On Wed, 12 Dec 2007, Robert E. Seastrom wrote: A practical question here: does anyone know offhand if 4km reach is adequate for interbuilding access (i.e., DC[124] to DC3) access at Equinix Ashburn, including worst-case interior wiring and cross connects? I'm thinking that's cutting it close. The enterprise people are substantially less likely to find themselves with a lot of interconnections in a GCE (Ginormous Campus Environment) than we are, and I suspect that skews the 90% number a bit. Folks who are more familiar with the layout of other facilities may wish to chime in here. I'm not in any of the Equinix facilities, but I do run a decent-sized urban campus network and a 3km-4km distance limitation would be cutting it really close for me in some cases. Some of the 10G links on my backbone today do require multiple physical cross-connects, which would eats into the link budget. Most of my backbone connections work find with 10G-LX4 optics, but there are a few places where 10G-ER is needed. I haven't read the draft spec yet to see what's being proposed for a link budget at 3/4/10km, but that's just as important as the physical distance. jms Bora Akyol [EMAIL PROTECTED] writes: IEEE is seeking feedback from network operators etc on the reach requirements for 40GE 100GE. If you have direct feedback to give, please contact Chris Cole directly (email address below). This is very important as it will directly impact how much you pay for those soon to be cherished 40 100 GE hardware in the future. I believe information on how many patch panel connections you expect the links to go through is also highly valued. Regards Bora From: Chris Cole [EMAIL PROTECTED] Subject: Re: [HSSG] Reach Ad Hoc To: [EMAIL PROTECTED] Date: Tue, 11 Dec 2007 16:21:31 -0800 Reply-To: Chris Cole [EMAIL PROTECTED] During the November HSSG meeting, optics vendors made a presentation proposing changing the 10km reach objective to 3km or 4km. One of my motivations for working on the proposal was informal input from a number of 100GE end users that 90% of their data center and short interconnect needs would be met by a reach objective less then 4km (versus 10km.) With such a reach distribution, a 4km or less optimized reach objective would result in overall cost savings. As part of the HSSG effort to review this proposal, numerous requests, both informal as well as from the HSSG chair and Reach Ad Hoc chair, have been made for contributions to quantify the 10km and under reach distribution. While the optics vendors as suppliers can accurately represent the relative costs of optics alternatives, they can not represent end user requirements. To date, we have seen no end user presentation or data supporting changing the 10km reach objective to 4km or less. Unless such contributions are forthcoming, it is likely that there will be no motivation to make the change. This sentiment can be seen in the 12/7 Reach Ad Hoc conference call minutes. I would encourage any HSSG participant that views their volume 100GE SMF needs as better met by a 4km or shorter reach objective to make a contribution containing reach distribution data in support of this position. Otherwise we will move forward with the existing approved objectives. Chris From: Andy Moorwood [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 6:03 AM To: [EMAIL PROTECTED] Subject: [HSSG] Reach Ad Hoc Colleagues, the meeting notes from our call last week are now posted on the IEEE website http://www.ieee802.org/3/hssg/public/reach/MeetingNotes_r1_1207.pdf Thank you for your contributions Andy --
Re: General question on rfc1918
On Tue, 13 Nov 2007, Drew Weaver wrote: Hi there, I just had a real quick question. I hope this is found to be on topic. Is it to be expected to see rfc1918 src'd packets coming from transit carriers? I would recommend grilling your carriers to find out why they're not dropping packets sourced from or destined to 1918 addresses. jms
Re: Returned mail: 17 Delivery failures on Tue, 06 Nov 2007
On Thu, 8 Nov 2007, Trent Lloyd wrote: Yeh I get these as well. I know the list admins and people from Merit are looking into why this is happening, so we'll see what they come up with. At this point it's probably not necessary for other folks to post me-toos to the list. jms On 07/11/2007, at 11:16 PM, Alan Spicer wrote: * Why do we have to continue to receive this delivery failure? It must be going to the whole list. It's not me being rejected so why do I care? This seems to come at least once a day now. This seems to be something new, or something new causing it. Reporting-MTA: dns; mozart.merit.edu Arrival-Date: Tue, 6 Nov 2007 00:00:00 -0500 (EST) Content-Type: text/plain Final-Recipient: RFC822; [EMAIL PROTECTED] Action: failed Status: 5.2.0 Diagnostic-Code: SMTP; 550 5.7.1 message content rejected Last-Attempt-Date: Tue, 6 Nov 2007 23:59:59 -0500 (EST) X-Suppressed-Delivery-Status-Count: 17 --- Alan Spicer Radio Amateur (General): KA4UDX Restricted Radiotelephone: RR00022962 General Mobile Radio Service: WQHB349 ([EMAIL PROTECTED]),([EMAIL PROTECTED]) DBA Alan Spicer Telcom / Alan Spicer Marine Telecom Computer Services, Wired/Wireless Networking, Cell/Sat/Landline Communications, General Consulting... Marine, Business, Small Office and Home Office (SOHO) * http://www.marinetelecom.net/ * * 954-683-3426 Business Mobile * 866-977-5245 Toll Free 800# * 954-977-5245 Office * skype:alanspicertelecom - Original Message - From: Mail Delivery Subsystem [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 03:30 Subject: Returned mail: 17 Delivery failures on Tue, 06 Nov 2007 On this date, there were delivery failures where the associated deliver status notification messages were suppressed. --- The following addresses had suppressed delivery status notifications --- [EMAIL PROTECTED] - Transcript of session is unavailable - No information is available on specific messages. No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.20/1108 - Release Date: 11/3/2007 9:42 PM ATT00082.dat
Re: Researchers ping through first full 'Internet census' in 25 years
On Fri, 12 Oct 2007, Chris Owen wrote: You can't consider every wacko on the net when doing something like this. Anyone who considers a ping an attack probably isn't worth worrying about. I tend to agree, but back when I manned the abuse desk (among others) at my former employer, I would see abuse reports come in all the time that were basically a report from whatever security software someone was running on their PC, accompanied by a message that was usually something along the lines of this: HOST x.x.x.x ON YOUR NETWORK PINGED ME I TAKE MY SECURITY SERIOUSLY!! I'M CALLING THE FBI!!! The knee-jerk reaction is rarely the right one :) jms
Re: Researchers ping through first full 'Internet census' in 25 years
On Fri, 12 Oct 2007, Leigh Porter wrote: You are more likely to get 5000 zonealarm emails Got tons of those... ...and BlackIce, DShield, Norton, SamSpade, and all the rest :) But there were also lots of people who took time out of their busy day to personally write their own flaming emails, rather than just relying on the boilerplate reports many of the packages above commonly send out. I felt honored :) jms Justin M. Streiner wrote: On Fri, 12 Oct 2007, Chris Owen wrote: You can't consider every wacko on the net when doing something like this. Anyone who considers a ping an attack probably isn't worth worrying about. I tend to agree, but back when I manned the abuse desk (among others) at my former employer, I would see abuse reports come in all the time that were basically a report from whatever security software someone was running on their PC, accompanied by a message that was usually something along the lines of this: HOST x.x.x.x ON YOUR NETWORK PINGED ME I TAKE MY SECURITY SERIOUSLY!! I'M CALLING THE FBI!!! The knee-jerk reaction is rarely the right one :) jms
Re: OT: Visio or Autocad
On Wed, 10 Oct 2007, Stephen Fulton wrote: A good friend of mine swears that Autocad is superior for network design to Visio. I don't disagree, but only because I have never used Autocad for network design. So far Visio has generally met my needs when I'm working on a design, but I have found it lacking (or perhaps just my Visio skills?) when trying to merge L2 and L3 designs. Most of the time I start from scratch on each layer, but it does become a burden as changes are made once the design becomes operational, and over its' lifetime. Is anyone using Autocad for network design? What are your thoughts? I'm using AutoCAD, but just for physical plant stuff such as route maps where I can overlay my plant data onto GIS maps. We also use it because architects and contractors sometimes supply us with CAD drawings when we're reviewing construction plans and such. I use Visio 2003 for the 'official' backbone maps used by our NOC and neteng groups. Most of my peers also use Visio for doing design drawings. AutoCAD and Visio both have their strengths and weaknesses. It really boils down to your needs, preferences, learning curve tolerance, etc. I've never tried to use AutoCAD for a network diagram, but for my way of working at least, it would seem to be pretty cumbersome, plus my templates and any customer shapes I've made are already built around Visio, so I'd have to re-create that to do the same task in AutoCad. jms
Re: How Not to Multihome
On Tue, 9 Oct 2007, Patrick W. Gilmore wrote: Justin, if Provider A _has_ permission from Provider B to announce a prefix, do you believe Provider A should be allowed to announce the prefix? As long as all of the relevant parties know about it and are OK with it, that's fine. It's just not my first choice for solving the customer's multihoming dilemma, that's all :) jms
Re: Why do some ISP's have bandwidth quotas?
On Mon, 8 Oct 2007, Andy Johnson wrote: In my experience, the support cost of DSL is significantly cheaper than dial-up in terms of helpdesk calls. DSL/Cable/FiOS is typically a plug and play, where as dialup can be quite a bit more troublesome, involving more tech time in the long run. I occasionally see providers offering pay-per-incident tech support, particularly for their lower-priced service offerings, as a way to offset the higher support costs as a percentage of overall revenue from those users. I'm not saying it's right or wrong, but it is out there. jms
Re: How Not to Multihome
On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. Some providers take a pretty dim view of seeing chunks of their address space show up in advertisements originating from someone who isn't one of their customers. It can make troubleshooting connectivity problems for that customer (from the provider's point of view) very painful, i.e. Hey, this AS, who isn't one of our customers, is hijacking IP space assigned to one of our customers! The provider could then contact your host's upstream(s) and ask them to drop said announcement under the impression they're stopping someone from doing something bad. Also, if some network out there aggregates prefixes in an aggessive/odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems. Standard caveats about the block being a /24 or larger also apply. jms
Re: How Not to Multihome
On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: That brings up an interesing point. My biggest fear was that one of my other customers could possible be closer to me that the ISP that provides the primary link and it would cause them to favor the backup link because of AS path. I think they are going to fight me on this and telling them to multihome to their original ISP would probably be frowned upon at this point. I was hoping that there was an RFC for multihoming that I could use to bail myself out. If you went ahead and did this, the more specific route being announced by you on behalf of your customer would be more likely to attract traffic back to you. Prefix length is checked in the BGP route selection process before AS path length. This would work in normal everything works fine situations, but when things break, troubleshooting the source of the customer's reachabilit woes will get very interesting. jms
Re: How Not to Multihome
On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. That is not at all guaranteed. I never said it was. My experience, both in my previous life as the operator of a regional ISP and since then in other capacities is that having disjoint origins for a chunk of some provider's address space is basically asking for trouble, and it's the kind of trouble that may ony pop up when something breaks. My experience has also been that if a customer has a need to multihome and is willing to invest both in the equipment and the expertise to do so, then so be it. If you do you have permission from the owner of the block, you Should Not Announce it. Agreed. If the owner gives you permission and can't figure out why their block is originated by another ASN as well, they need help. (Yes, I realize the latter part of the last sentence is probably true for the majority of providers, but whatever.) In either case, your hypothetical question should not hold. Also, if some network out there aggregates prefixes in an aggessive/odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems. How is this different than if the customers gets their own ASN and announces a sub-block from one of the providers? In the case you described, the provider who holds the parent address block should expect to see an advertisement for a chunk of that block come in as part of the BGP feeds they receive from their upstreams, and they need to accept traffic accordingly. The customer would need to tell the provider of their intentions to multihome. If the provider in question employs some type of ingress/egress filtering, that filter would need to be updated to recognize that traffic sourced from that sub-block as legitimate, even if it comes in over their normal transit pipes. In the case I described, where the end user requested that a third party provide transit for their PA space, without that provider necessarily being aware of it is when things can break in strange and spectacular ways. Or are you suggesting they should get PI space? PI space, while nice, is not an option for many end users. jms
Re: How Not to Multihome
On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: please elaborate. My knowledge of IPv6 is admittedly lacking, but I always assumed that the routing tables would be much larger if the internet were to convert from IPv4 due to the sheer number of networks available. Not many networks are pushing IPv6 at this point, or more correctly, not many relative to the 230k+ routes that currently makes up a full IPv4 routing table. There likely won't be a mass flash-cut to IPv6, which is a subject that has been debated to death and back again here on NANOG over the last few weeks :) jms
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
On Mon, 8 Oct 2007, David Conrad wrote: Others have indicated that such filters (assuming they exist) will not last in the face of paying customers presenting longer than /24 prefixes for routing. Specifically, that ISPs will relax their filters (allowing longer than /24) in order to get their peers to accept their long prefixes. Anybody have an opinion on the likelihood of this? The only exceptions I've seen to the /24 policy are when the customer in question multihomes to the same upstream - sometimes done with a specific AS designated for that purpose, i.e. what UUNET does with AS7046. Those routes are then aggregated that provider's parent block(s). As far as allowing prefixes longer than a /24, that decision was made when the Internet was considerably smaller than it is now, and many networks adopted /24 as the cutoff point. If you make the cutoff point smaller, what is the new point... /26? /32? Many networks see customers multi-homing as pretty easy justification to provide them with a /24 of PA space, even if they're small enough that justifying a /24 while single-homed wouldn't work. jms
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
On Mon, 8 Oct 2007, Jon Lewis wrote: adopted /24 as the cutoff point. If you make the cutoff point smaller, what is the new point... /26? /32? Anything longer than /24 is unlikely to propogate far on the internet. You can all check your filters to see. I just checked mine, and neither Level3 nor Time Warner has tried to send me anything longer than /24 in recent history. If they did, it'd show up as hits on a distribute-list deny rule. I realize that - I was posing a rhetorical question to the previous poster :) This is actually in the ARIN rules. Multihoming is justification (regardless of utilization) for one of the multihomed network's providers to assign them a /24. Been down that road a few times too, both as a provider and a customer. jms
Re: How Not to Multihome
On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: If you went ahead and did this, the more specific route being announced by you on behalf of your customer would be more likely to attract traffic back to you. Prefix length is checked in the BGP route selection process before AS path length. This would work in normal everything works fine situations, but when things break, troubleshooting the source of the customer's reachabilit woes will get very interesting. You have made an assumption that the original upstream would not originate a prefix equivalent to the one you are originating. Internally or externally? A /24 would exist in the provider's IGP to point traffic to that customer. Off the top of my head, I don't see why the provider who holds the parent block would do this externally. If the provider has, say, a /18 and they assign a /24 of that to this customer, there would be no legitimate reason to originate that /24 and propagate it out to the rest of the Internet. Note that I don't consider breaking that /18 up into 64 /24s and announcing them all separately to accomplish some sort of poor-man's traffic engineering to be a legitimate reason :) jms
Re: Why do some ISP's have bandwidth quotas?
On Thu, 4 Oct 2007, Hex Star wrote: Why is it that the US has ISP's with either no quotas or obscenely high ones while countries like Australia have ISP's with ~12gb quotas? Is there some kind of added cost running a non US ISP? Depending upon the country you're in, that is a possibility. Some countries have either state-run or monopolistic telcos, so there is little or no competition to force prices down over time. Even in the US, there is a huge variability in the price of telco services from one part of the country to another. jms
Re: Bee attack, fiber cut, 7-hour outage
On Fri, 21 Sep 2007, Deepak Jain wrote: Is this a 7 hour outage a comment on rural Central Texas availability of fiber splicers or novel ways fiber gets cut? Anytime you talk about rural I'm impressed with 7 hours, however -- isn't SONET supposed to make this better? Sure, if: 1. the protect path is configured and enabled 2. both the working and protect paths don't run through the same conduit/duct/buffer jms
Re: Good Stuff [was] Re: shameful-cabling gallery of infamy - does anybody know
On Wed, 12 Sep 2007, Chris Adams wrote: Once upon a time, David Lesher [EMAIL PROTECTED] said: If you find any pictures of NY.NET; Terry Kennedy made the above look sloppy. Many places ban cable ties due to the sharp ends; I believe the pictures in question are here: http://www.tmk.com/pics-111/ jms
Re: Good Stuff [was] Re: shameful-cabling gallery of infamy - does anybody know where it went?
On Tue, 11 Sep 2007, Scott Weeks wrote: It was brought to my attention that some of the folks here may not have ever seen good wiring, so I snapped a few photos of good wiring here and wrote a quickie web page for the photos. I couldn't get pictures of Ethernet wiring, but it's the same. Except the last photo, it's all wax string done very neatly. This is the goal. ;-) Nice - they even wrapped the fiber to keep the wax twine from pinching it. Some of the telcos around here do (or did) very clean wiring jobs like this. The ATT Local (TCG from way back in the day) guys who put the OC48 bay and related breakouts for T1s and DS3s did very neat wiring. Some of the local old-school Bell Atlantic/Verizon techs also did very clean work, but most of them took the early retirement packages that were offered 4-5 years ago. jms
Re: shameful-cabling gallery of infamy - does anybody know where it went?
On Mon, 10 Sep 2007, Warren Kumari wrote: One of the places where I worked had a bunch of networking gear and around 12x1U servers all squeezed into a shower stall There was a cardboard sign hanging from the faucet saying WARNING!!! Do not turn on Not too far from the dial POP I mentioned in my last post, was another dial/T1 POP in northwestern Maryland. Prior to our acquisition of the company that originally built the POP, it was located in two rooms of the basement of a 200-ish year old homestead in the area. That wasn't the problem - structurally, the building was perfectly fine. The only problem specific to the building was a total lack of cooling in the basement. Several racks of routers, servers, and telco gear throw off lots of heat, so the temperature in that room was never below 95 degrees even in the dead of winter. There were also some well-fed cockroaches, who would occasionally help us move equipment. My only conern with them was that they'd threaten to unionize and lobby for better working conditions :) http://www.cluebyfour.org/~streiner/hgr-pop-2000-roaches.JPG The telco demarc for the T1s. The bread racks holding the routers and dial gear would be just to the left of this view. You can see some of the spider web wiring peeking out from the beams above. http://www.cluebyfour.org/~streiner/hgr-pop-2000-far-end.JPG More telco gear in another part of the basement. Yes, the muxes are wrapped in plastic, apparently to keep the dust off of them :) http://www.cluebyfour.org/~streiner/hgr-pop-2000-separate-telco-room.JPG The problem was the installation work done by some of the people who worked for the company we acquired. T1 blocks were on one wall and the routers were in the opposite corner of the room - total distance was about 30-35 feet if the wiring was done 'the right way'. The solution I found they used was to buy a bunch of 100-foot Cat5 jumpers and loop the excess length back and forth on itself, cinch it all together with zip ties (bend radius recommendations be damned) then anchor the whole mess to one of the ceiling beams with a staple gun. Multiply that by 20-ish T1s and the ceiling turned into a spider web very quickly. Power distribution was also very interesting. It consisted of a piece of Romex pulled from a nearby electrical panel to a string of household duplex outlet boxes nailed to a 2x4. Somewhere in the mess of wiring for that beast, it appears that the maker never bothered to test for a good ground... jms
Re: shameful-cabling gallery of infamy - does anybody know where it went?
Note that telcos are not immune to shoddy cabling/installation work. The link below is from a dial/T1 POP at I place I worked in several years ago. In case the detail is hard to make out, the paper sign taped to the ladder says DO NOT MOVE LADDER. The background is that Bell Atlantic mounted a T1 smartjack cage to the wall using undersized drywall screws. The cage eventually pulled out of the wall and came crashing to the floor, at which point some of the T1s in this location went down. We called Bell. They tested. They dispatched. This was their solution. Final note: the ladder wasn't theirs :) http://www.cluebyfour.org/~streiner/mbr-pop-2000-ladder.JPG jms
Re: 2M today, 10M with no change in technology? An informal survey.
On Tue, 28 Aug 2007, Chris L. Morrow wrote: And the 7600 is a router? :) I thought it was just a 6500 that sommeone got drunk and tipped over on it's side, like a cow... I still needle my Cisco rep about that from time to time. IMHO, the 6500/7600 split was one of the dumbest, most poorly thought-out decisions Cisco ever made. That and they still haven't given me the warm-and-fuzzy about the plans for IOS licensing. Where I work, we're heavily invested in 6500s in the core and I don't see that changing any time soon. The borders are Junipers because they 'just plain work' :) jms
Re: Market for diversity (was: Re: Cogent latency / congestion)
On Sat, 25 Aug 2007, Andy Davidson wrote: Is it not possible to require that each of your suppliers provide over a specified path ? I'm planning a build-out that will require a diverse path between two points, and one supplier has named two routes, and promised that they wont change for the duration of the contract. Perhaps I am naive, but a promise should be a promise. Note: IANAL, nor do I play one on TV. Spell out exactly what you want (read: make no assumptions about even the most mundane details) when talking to your account rep and go over the contract and accompanying schedules with a fine-toothed comb before you sign. You want to make sure all those details are spelled out the same way that you provided them to your salescritter and also check for legalese that gives the provider room to do things like re-groom your circuit/lamdba/whatever you're buying onto another (possibly convergent) path without your notification and consent. Even then, be prepared to take your provider(s) to task and perform due diligence on those physical routes on a regular basis. Note that getting this information in the first place may require you to execute a non- disclosure agreement. Check the wording of that agreement as well to make sure that it won't prevent you from a) performing future due diligence and b) seeking legal relief if a future round of due diligence shows that the terms of your contract have been breached. jms
Re: Cogent latency / congestion
On Mon, 20 Aug 2007, Deepak Jain wrote: Sounds like a DHS/FBI investigation will be starting soon. Eesh.. if we start having to secure 500,000 route miles of fiber routes against sabotage, um... well, I guess I'll have to become a fiber installation contractor. :) That and carriers will have to stop value-engineering route diversity out of their networks. jms
Re: San Francisco Power Outage
On Tue, 24 Jul 2007, Tuc at T-B-O-H.NET wrote: (I remember two guys with VERY LONG screwdrivers poking a live transfer switch to get it to reset properly, and was told to step back 20 feet as thats how far they expected to get thrown if they did something wrong). (I also remember them resetting the switch, then TRIPPING it again just to make sure it could be reset again!) Ahhh, a trip down memory lane :) The ISP I used to work at had a small ping-and-power colo space, and we also housed a large dial/DSL POP in the same building. A customer went in to do hardware maintenance on one of their colo boxes. Two important notes here: 1. The machine was still plugged in to the power outlet when they decided to do this work. 2. They decided to stick a screwdriver into the power supply WHILE said machine was plugged into said power outlet. I guess those no user serviceable parts inside warning labels are just friendly recommendations and nothing more... While the machine was fed from a circuit that other colo customers were on, the breaker apparently didn't trip quickly enough to keep the resulting short from sending the 20 kva Liebert UPS at the back of the room into a fit. It alarmed then shut down within 1-2 seconds of this customer doing the trick with the screwdriver. This UPS also fed said large dial and DSL POP. Nothing quite like the sound of a whole machine room spinning down at the same time. It gives you that lovely oh shit feeling in the pit of your stomach. I do remember fighting back the urge to stab said customer with that screwdriver... jms
Re: recommendations for Cisco repair?
On Fri, 18 May 2007, Carl Alexander wrote: I've searched the archives, and am somewhat surprised to find no discussion of this: Does anyone have a recommendation for cisco repair/refurbishing? (Background for any who care: We had a power supply die on a 7206VXR; a junior admin went to swap in a replacement p/s and pulled the power cord out of the other, running, p/s. He realized as he did it that he'd screwed up and shoved the cable back into the p/s. The router no longer boots. We want someone to go over each component, figure out which are damaged, repair or replace them, and put some sort of reasonable warranty on their work.) By doesn't boot, do you mean it doesn't power on at all, or it powers on, but you don't see a proper boot sequence from the console? If the router powers up, there are a number of possibilities, depending on what you see on the console. If the router powers up, but hangs when it should start loading its boot image, it's possible your bootflash is corrupted, in which case you can try formatting the bootflash and xmodeming a new boot image onto it. You might be able to find a competent electronics repair shop to repair the power supplies if that's what's fried, however you can get 7200 power supplies pretty cheaply on the used market, probably not much more than a repair shop would charge to tear your power supplies apart. If the problem is not the power supplies, but something on the NPE or midplane, your only viable option is to replace the broken components. Do you have another 7206VXR chassis that you can swap components into, to find out what works and what doesn't? jms
Re: RTT from NY to New Delhi?
On Wed, 16 May 2007, Joe Maimon wrote: What should I expect? I am seeing ~350 from a vendor provided mpls cloud to a site in Sukhrali Chowk, Gurgaon, Haryana, India Where are you running your tests from? USA (east or west coast)? Europe? Elsewhere in Asia? jms
Re: RTT from NY to New Delhi?
On Wed, 16 May 2007, Joe Maimon wrote: What should I expect? I am seeing ~350 from a vendor provided mpls cloud to a site in Sukhrali Chowk, Gurgaon, Haryana, India Disregard my previous post. I completely overlooked the subject that said NY to New Delhi *smacks forehead*. Rule 1: Don't post before caffeine kicks in. Rule 2: You do NOT talk about Fight Club. So... my 'idiot moment' for the day behind me, 350ms may be a little bit high, but not totally unreasonable/unexpected. jms
RE: HSRP availability in datacenters?
On Fri, 11 May 2007, Randal Kohutek wrote: I agree, 6500s or 4500s for distribution are where it's at ... Unfortunately they cost a lot. Which is why the suits are considering financing them by charging for the features they provide. One way I've seen providers address is this to have two different classes of service offerings. One has redundancy built in and the other doesn't - then you price the offerings accordingly. That could apply to basic ping-and-power colo, managed services, or anything in between. The cost difference could be justified by the fact that the redundant service takes up resources (finite resources at that) on two different big expensive switches. This has been a hot topic around the office, with all of us network guys saying `keep hsrp everywhere` because it makes our phones ring less, but we realize that network upgrades aren't free, which is making the non-IT folks all antsy. And that's a very valid point. Many organizations pay different amounts of attention to manpower costs vs. capex to buy the big expensive switches and opex to keep things running. Manpower is (hopefully ;) in your organization) not cheap. jms
ATT (7018) BGP clue sought
I'm trying to track down someone at ATT that can answer questions about their implementation of BGP communities - questions that are not answered in their BGP policy document. Conversations with first and second line support people have not been productive. Any help that someone in a network engineering role could provide would be greatly appreciated. jms
Re: SaidCom disconnected by Level 3 (former Telcove property)
On Sat, 17 Mar 2007, Brandon Galbraith wrote: True :) I'd also think (read: hope) if an organization was located in an area where multi-homing was not possible, then that organization and its customers would not be doing things that are mission critical, i.e. business stops if there is no Internet connectivity. Mission critical seems to be quite subjective these days. Sure. That's why I qualified my remarks. jms
Re: NOC Personel Question (Possibly OT)
On Wed, 14 Mar 2007, Todd Christell wrote: Sorry if this is OT but we are having a discussion with our HR department. We are in the process of getting a 24 X 7 NOC in place and HR has a problem with calling them NOC Specialist. What is the generally accepted title? Not sure why your HR dept would even care :) hmmm. NOC Engineer? NOC Analyst? NOC (insert generic group name here)? jms
Re: NOC Personel Question (Possibly OT)
On Thu, 15 Mar 2007, Simon Lyall wrote: On Wed, 14 Mar 2007, Justin M. Streiner wrote: Not sure why your HR dept would even care :) So they can look them up on a pay scale list and decide what they should be paid. In pretty much every place I've worked, the pay scale was set by the hiring manager. HR's role was to handle the paperwork. As always, YMMV. Probably not to respond to the list on this one since we're already close to the on-topic/off-topic line. If you want to respond offline, by all means feel free. jms
Re: single homed public-peer bandwidth ... pricing survey ?
On Tue, 6 Mar 2007, Jason Arnaute wrote: Yes, that's what I am saying - one pipe only, and if it goes down, I go down. Ok, so it sounds like they're doing MPLS or some sort of policy routing to force your traffic out one of their transit providers. I've seen other providers do this. Is this something you contractually requested? If so, I'd hope the price would be less than the multi-homed service I'm assuming they sell to other customers. So ... I am wondering if roughly $150/mb/s is just way off the charts for something like that, or if I am only overpaying by roughly 10-30% or so ... That depends on how much bandwidth you're buying. If you're buying 1 Mb/s, that's probably not too unreasonable, though maybe just a bit high. If you're buying 100 Mb/s, I'd hazard a guess that you're being robbed. Double-check your contract for what they sold you, compared to what you bought. And then, of course, I'd like to be pointed to where I can learn why HE.NET and L3 are so cheap compared to that, and what my cost/benefit would be to switching... Again, it comes down to your current contract and the fine print on the deals the other providers are pitching. I doubt someone will sell you 1 Mb/s of bandwidth at $30/Mb. Those numbers likely have strings attached to them, i.e. if you buy 100 Mb/s or more, sign some kind of long-term deal, buy other value-add services, etc. (as for racks and power, it is on the high average side. Roughly $1000/mo for a full cabinet) In some parts of the country, colocation is becoming more of a seller's market - high demand, space is at a premium. jms
Re: Undersea fiber cut after Taiwan earthquake - PCCW / Singtel / KT e tc connectivity disrupted
On Sun, 21 Jan 2007, Aaron Glenn wrote: Just the other night I was trolling marketing materials for various lit services from a number of providers and I ran across what I found to be an interesting PDF from the ol' SBC (can't find it at the moment). It was a government services product briefing and in it it detailed six levels of path diversity. These six levels ranged from additional fiber on the same cable to redundant, diverse paths to redundant facility entrances into redundant wire centers. What struck me as interesting is that the government gets clearly definied levels of diversity for their services, but I've never run across anything similar in the commercial/enterprise/wholesale market. I believe such levels of diversity and detail were specifically mandated for the Fedwire. Are the Sprints/Verizons/ATTs/FLAGs/etc of the world clearly defining levels of diversity for their services to people? From past discussions with them when I was in the ISP world, I'd have to say for the most part the answer is no, and the bits of info that deviated from that stance were normally divulged under NDA. jms
Re: How big a network is routed these days?
On Wed, 17 Jan 2007, John Smith wrote: my organization is considering PI addresses as a way to multihost. Having read the archives regarding disadvantages and alternatives, my question is how big a network must one have to be reasonably sure the BGP routers will accept the route? A /24 is the smallest block of IPv4 addresses that you can reasonably expect to be globally reachable. Depending on where you're located, the different address registries (ARIN, RIPE, APNIC, etc...) have different policies regarding the smallest PI block they'll allocate to end users. jms
Re: Routing Loop Strangeness
On Thu, 4 Jan 2007, Nachman Yaakov Ziskind wrote: 25 11.11.11.2 44 msec 26 11.11.11.1 48 msec 27 11.11.11.2 48 msec 28 11.11.11.1 48 msec Yep. Way cool. Unfortunately it's not the first time that: 1) someone with enable screwed up a routing design or did something dumb like dueling static routes, or some similar kind of rubbish. 2) someone with enable (or someone who manages peple with enable) co-opted arbitrary non-1918 IP space for use on their internal network. Calling it RFC1919 space would almost be funny if it weren't such a pain the butt to deal with people who do things like this. jms
Re: on a different manners topic, was Re: Phishing...
This little piece will be top-posted, but everthing else will be inline. I'm also going to trim the pieces that I won't be responding to *gasp*! Please don't shoot me - comments are inline ;-) On Wed, 3 Jan 2007, Edward Lewis wrote: I'm not going to pick on the it's (grammatically correct, but it refers the email disclaimers which I don't feel like commenting on) but I want to say that I've come to appreciate top-posting. With top-posts, there is no need to scroll down the list, and it is more like a conversation than injecting comments in-line. Most of the conversations I participare in are at least somehwat bi-directional, rather than having one person speak a chapter and requiring the other person to do the same with their responses. Keep in mind I'm not saying you're wrong, I think we just interpret message flow a little differently. Some say that top-posting reverses the conversation, but if you are thumbing through the archives of top-posted threads, each contribution is on the first screen and you can navigate message to message in time-order. In my personal opinion, reading through archives of in-lined threads is much more of a problem - for one because threads take off in other directions and an in-line conversation never stands alone. Usually with a few nested in-lines I loose who said what context too. I disagree. The general convention has been that a paragraph or text block contains a complete thought, or at least a chain of sentences that are at least somewhat related to each other. People usually limit their response to just that little bit of text, so the you-say-X, I-respond-Y flow of the thread is indeed preserved. (As an exercise, try to prepare a reply in-line and then as a top-post. You will see that in-line means less typing, as you don't have to rephrase the question. In-line is less work to render, but I think it is a poor communication style.) Again, I disagree, but that's just my opinion. Top-posting everything means I either have to scroll down through the whole message to locate the piece of text that person responded to, or perhaps have to locate the previous message because the person didn't bother to quote the previous message in their reply. Too much context-switching and caching makes for inefficient message reading :) As far as the HTML, I don't think I use it, but I fail to see why it's rude. Sorry, it is newer technology and it does screw up old tools. (I do get bit by it - the hotels seem to love HTML confirmations that I can't read on my work mailer.) It's my/reader's choice to not use newer tools. It makes assumptions that everyone a) wants to read HTML messages and/or b) has a mail reader capable of rendering them. I'm reading this message from my Linux machine at home, using the newest version of Pine over an SSH session. Compared to firing up mozilla/thunderbird/evolution and X-forwarding the display to the machine I'm sitting in front of, this setup is substantially faster and more lightweight for remote reading. There. I've said it...oh, and the disclaimers don't give me heartburn. I just ignore them. I usually do as well, but when I receive a 1-line email from someone and it has a 1-page disclaimer at the bottom that chances are I will not read, then yes I get a little annoyed :) It's right up there with people who assume the rest of the world uses Outlook/Exchange, i.e. Smith, Joe would like to recall the message 'ABCDEFG'. jms
RE: http://cisco.com 403 Forbidden
On Wed, 3 Jan 2007, Scott Morris wrote: Works fine for me. And a 403 Forbidden is a web server error, not a resolution error if I remember right. Correct. Someone made a boo-boo on some component of www.cisco.com, i.e. changed a chunk of the web server configuration or broke the permissions on some piece of the underlying document tree. www.cisco.com loads fine from here, but maybe the issue has already been resolved... jms
Re: GBLX issues?
On Wed, 13 Dec 2006, J. Oquendo wrote: Anyone seeing issues for GBLX around NY? Do you have traceroutes or other useful data to illustrate said broken-ness? jms
Re: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Thu, 9 Nov 2006, Adrian Chadd wrote: On Thu, Nov 09, 2006, Robert Boyle wrote: You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.) Is there a somewhat-reliable bogon BGP feed that can be subscribed to these days? You probably want to have a look at http://www.cymru.com/BGP/bogon-rs.html jms
RE: [c-nsp] [Re: huge amount of weird traffic on poin-to-point ethernet link]
On Thu, 9 Nov 2006, Donald Stahl wrote: Sorry I have to agree with Steve as well. I know I've left networks with Bogon lists in place and then gotten calls a year or more later asking why traffic can't isn't coming in from XYZ new client. Turns out the new admin never updated the bogon list. This process can be automated. See my previous post. jms
Re: Watch your replies (was Kremen....)
On Wed, 13 Sep 2006, [EMAIL PROTECTED] wrote: It's insulting when you trim the message to a shorter statement that you are responding to. The other 18 lines may not have been important to this particular response but they were not content free. If your content was in any way, interesting, then people will have read it in the message that you posted. I see no need to repeat a bunch of irrelevant text when I am only replying to one point in your email. Personally, I wish more people would trim away all the irrelevant junk when replying. I'm not singling any one person out, but when a thread that started off talking about RIR policy issues and IP address portability debate gets this far off track, then it's time for that thread to die or be taken out-of-band. Agreed? jms
RE: Kremen's Buddy?
On Tue, 12 Sep 2006, [EMAIL PROTECTED] wrote: It seems to me that this nicely illustrates a major problem with the current system. Here we have large blocks of IP space that, by their own rules, ARIN should take back. It all sounds nice on paper, but clearly there is a hole in the system whereby ARIN doesn't know and apparently has no way of figuring out that the space is no longer in use. It makes me wonder just how much space like that there is out there artifically increasing IP scarcity. I don't know what the solution is, but the way things currently work it seems like if you can justify a block today, it's yours forever even if you stop actively using it. Maybe allowing for some kind of IP market would cut down on that type of hoarding -- you would at the very least change the type of value those subnets have. Many of those legacy allocations were made before ARIN came into being and IP assignments were doled out by the InterNIC. This was also before IANA/ICANN started allocating /8s to the various RIRs to hand out to organizations in their respective geographic areas. That said I think $RIR's approach has been that they won't push an organization on their legacy blocks. There have been a few cases of organizations willingly turning in their legacy blocks for more appropriately sized ranges in the past. jms
Re: [Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
On Mon, 11 Sep 2006, Chris Jester wrote: IP addresses appear to be property - - read http://news.findlaw.com/ hdocs/docs/cyberlaw/kremencohen72503opn.pdf. Given that domain names are property, IP addresses should be property, especially in California where are constitution states All things of value are property Intrinsic or non-intrinsic value? It's an important distinction. Also, what about ARINS hardcore attitude making it near impossible to aquire ip space, even when you justify it's use? I have had nightmares myself as well as MANY of my collegues share similar experiences. I am having an issue right now with a UNIVERSITY in Mexico tryin to get ip's from the mexican counterpart. I worked for a large-ish ISP for over seven years and made multiple requests for IP space from ARIN in that time. My experience with this was not at all bad. I did not find it to be like pulling teeth to get the space. As long as the request documentation is in order, it was not too bad. I disagree with the notion that IP addresses are property. jms
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
The complaint was, at best, an entertaining read. IANAL. As was mentioned earlier, it looks like Kremen's whole case is built on a number of false assumptions: 1. Netblocks are the property of the organization once their assignment request is approved by ARIN or other RIR. Since this is false, the none of the parties involved in Kremen v. Cohen would have legal standing to make the transfer of Cohen's netblocks a condition of satisfying the judgment in that case. 2. There is an open market for buying and selling IP addresses. While ISPs can and sometimes do charge fees to their customers to use a block of PA space, they cannot do the same on an 'open' market. The customer normally may use the PA space until their business relationship with the ISP is terminated, i.e. the space is non-portable. 3. ARIN's policies discriminate against smaller providers by preventing them from getting larger netblocks. Going back to 1997 from what I can find, ARIN's address assignment policies have always advocated a pay-as-you-go model. If an organization gets close to using all of their assigned addresses, they can request another block once they've provided justification that the first assignment has been efficiently used. The complaint acknowledges that IP addresses are finite resources and that macro-allocation of address ranges is handled by ICANN. 4. Recently... Classless Inter-Domain Routing or CIDR... As others have mentioned, this is hilarious. I guess I'll have to upgrade my routers to use that newfangled routing protocol, BGP4 CIDR had a huge impact in putting the brakes on wasteful IP address allocation. The days of /16s being available pretty much for the asking are long gone. 5. Providing information to justify an assignment or transfer request will force the requestor to reveal information that is confidential and proprietary. The way I see it, this helps maintain some degree of transparency of ARIN's policies, customer business names and addresses are items that are probably already matters of public record from domain name registrations and so forth. Also, the information provided to ARIN when requesting more space is normally more detailed than what is required to be made public through SWIP or RWHOIS. The information specifically submitted to ARIN for proving a request is justified is not released to the public. jms
Re: Router / Protocol Problem
On Wed, 6 Sep 2006, Mike Walter wrote: I normally would not post to the group, but I am 100% stumped and have talked with peers with no luck. I have (2) Cisco 7204 Routers running BGP with 3 peers and HSRP. I am not doing anything special with BGP, pretty much a default config that has not changed in years. Please provide details on both your default config and the hardware you're using. You say you have two Cisco 7204s - are these straight '04s, or 7204VXRs? What NPE(s) are you using, and how much memory is on them? The BGP you're getting from your peers - are you getting full routes from any of them? Do you have CEF enabled on these routers? What IOS version(s) are running on these routers? What else are they doing besides slinging BGP routes? Does the problem go away for a while if you reboot one router or the other? Without knowing any of this, it sounds like you might have NPE-225, -300, or -400 with 256 MB of RAM and you are running into memory exhaustion issues from carrying full routes. That's been a pretty popular topic on this list and others like cisco-nsp in the last 12 months :) At a minimum, what do the output of show mem summary and show ip bgp sum from each router show you? Have you seen other performance problems lately, such as things getting mysteriously slower, beyond the rachability issues you mentioned above? If so, check if CEF is still running (if it was configured in the first place). When a 7200 gets dangerously low on free memory and CEF is running, it may cannibalize the IP CEF process to try to conserve memory. Earlier 12.0 releases did this - I don't know if newer ones still do it. jms
RE: Router / Protocol Problem
On Wed, 6 Sep 2006, Mike Walter wrote: Thanks for everyone's great input. Here are answers to Justin's questions. #1 - 12.3.6a - 7204VXR (NPE400) 512MB - 200+ MB free #2 - 12.2.15T5 - cisco 7204VXR (NPE225) - 256MB (I have a NPE400 - 512MB I want to swap in) - 23MB Free (Issue?) Full Routes from all peers. No internal routing protocol as of yet, all static routes. Getting ready to implement OSPF. I have not rebooted the routers as a test. I have CEF on both routers. I have had some customers complaining about slowness. That NPE-225 could be the culprit. 23 MB free is workable, but definitely low. I see that router is running 12.2.15T5. T train IOS releases are where features are normally introduced first and are often more buggy than mainline IOS releases. I wouldn't be surprised if that release has some memory leaks that is exacerbating your issue. If you graph memory utilization with MRTG or some other handy graphing tool, memory leaks often show up as a pronounced 'saw-tooth' pattern when you look at the utilization over time. Also, how badly is the CPU getting hit on that NPE-225? Since you're carrying full routes, I wouldn't be surprised to see the BGP Scanner process beating your CPU up every 60-ish seconds. What does the output of show proc cpu hist show you? If you have lots of spikes up to 100% peak utilization in the history graphs, then that can definitely be a source of latency. jms
RE: NNTP feed.
On Tue, 5 Sep 2006, John van Oppen wrote: we don't run one either... :) The last person I know who was running one, was in the proccess of killing it. I used to run one, but haven't, since about 2000 :) The provider i worked for at the time got out of the game and outsourced news because otherwise we would have needed to dump a lot of money into disk space to keep people from bitching about the sub-24 hr retention times on alt.binaries.$VICE :( That was the blessing and the curse of cyclical filesystems, I guess :) On the plus side, Highwind's news server software just flat-out ran - never gave me a single problem in the 3 years I ran it. That plus a separate box running diablo to manage the feeds was a winning combination :) More and more people are outsourcing news because providing good news service requires tons of disk space and loads of network bandwidth, i.e. it costs a lot of money to operate, and for many providers, it doesn't make any money. The last time I looked at newsfeed stats, a full feed with all the alt.binaries crap was running around 350 GB/day - I wouldn't be at all surprised if it's substantially higher now. jms
RE: NNTP feed.
Sorry to reply to my own post, but after reading further into this thread, I saw that my estimation of substantially higher than 350 GB/day shows how long I've been out of the business of driving large news servers :) jms On Tue, 5 Sep 2006, Justin M. Streiner wrote: On Tue, 5 Sep 2006, John van Oppen wrote: we don't run one either... :) The last person I know who was running one, was in the proccess of killing it. I used to run one, but haven't, since about 2000 :) The provider i worked for at the time got out of the game and outsourced news because otherwise we would have needed to dump a lot of money into disk space to keep people from bitching about the sub-24 hr retention times on alt.binaries.$VICE :( That was the blessing and the curse of cyclical filesystems, I guess :) On the plus side, Highwind's news server software just flat-out ran - never gave me a single problem in the 3 years I ran it. That plus a separate box running diablo to manage the feeds was a winning combination :) More and more people are outsourcing news because providing good news service requires tons of disk space and loads of network bandwidth, i.e. it costs a lot of money to operate, and for many providers, it doesn't make any money. The last time I looked at newsfeed stats, a full feed with all the alt.binaries crap was running around 350 GB/day - I wouldn't be at all surprised if it's substantially higher now. jms
RE: Hot weather and power outages continue
On Mon, 24 Jul 2006, Christian Nielsen wrote: 20 - 30 years ago, Air Conditioning in a house was more of a luxury. For us, it was a Swamp Cooler. Most new houses today are built with AC and it is becoming standard practice to install them on older houses. So the load on the system will only get worse if things start to heat up. Aging distribution plants are have caused lots of problems. We had an 18-hour power outage in Oakland (neighborhood just east of downtown Pittsburgh) about 10 days ago when two separate 25kV feeders from the local substation blew at the same time. Local utility crews ended up having to replace around 400' of fried underground feeder cable. Our core sites are on redundant power, but in many cases this didn't include the chiller plant. Some of the rooms got hot, but we didn't lose any core equipment. Other large organizations in the area were not so lucky. jms
Re: Virtual routers from Cisco
On Mon, 26 Jun 2006, MARLON BORBA wrote: A friend of mine told me about a new breed of routers from Cisco which have two virtual machines over the same physical hardware -- sort of a VMWare or Xen host with guests. Does someone know about that, or had a practical experience with that new Cisco product? I'm pretty sure this functionality is now in the current IOS XR releases for the CRS platform. I think there was talk about eventually porting some of the IOS XR features to the 12000 series, but I don't know what work has actually been done there, or if that included the routing context capabilities. jms
Re: Who wants to be in charge of the Internet today?
On Fri, 23 Jun 2006, Jeff Shultz wrote: Thus explainith why CEOs should not be responsible for this. I wonder if their CIOs or other techies have ever tried to explain the concept of a CERT to them. Of course they have. Gives you minty fresh breath, right? jms
multimode LC-LC fiber jumpers
If you know where I could lay my hands on a few (5 at most) 5 meter multimode duplex LC-LC jumpers in the Pittsburgh, PA area, please shoot me a note off-list. Thanks jms
Re: Strange network problem accessing Ebay and versiontracker websites
On Wed, 3 May 2006, Shane Owens wrote: Can anyone give me any suggestions as to what routes to take to troubleshoot this? Logic tell me that is I have reach ability and one browser work but another doesn't it's a software problem with either the browser or the site, but being able to take the same machine to another network and have it work points to a whole different problem. Could this be a MTU issue? It sounds like that is a possibility. Are the DSL users being served by PPPoE? Setting the IP MTU on your PPPoE access template, depending on whose gear you're using to provide the servide provider end of your DSL services, to 1492 may help. jms
Re: Welcome back, Ma Bell
On Mon, 6 Mar 2006, Christian Kuhtz wrote: That being said, the 'new ATT' with all those assets will need to be integrated, and work efficiently. Turf battles will ensue. Tens of Integration, going on past experience, is highly unlikely. The last time I had any interaction with Worldcom regarding circuit/provisioning issues, there was little, if any integration of legacy engineering/provisioning data/OSSen. In other words, Oh, that's an MFS circuit ID, I'll need to get onto another system to get the details on it. Same thing with different incarnations of Bell of Pennsylv^H^H^H^H^HBell Atl^H^H^H^HVerizon. It's the same phenomenon of having 37 different numbers to call to get anything done at $RBOC, none of which are connected to each other. If their phone tree is that disorganized, I have little reason to suspect the underlying support systems are any different, nor will they be under the SB^H^H^HNew ATT. jms
Re: flow - web
On Fri, 3 Feb 2006, Randy Bush wrote: i have a few routers of various flavors spewing netflow data. currently i use flowtools, and get text reports via email. but they're s 20th century. what will accept flow data from the routers and give me a sexy web page or two showing the elephant apps and sites? has to be in freebsd ports tree, as i don't have much time to spend on this. nfsen (http://nfsen.sourceforge.net) and nfdump (http://nfdump.sourceforge.net) look like a decent stab at what you want. nfdump is the data collector and nfsen is the sexy-web-page-maker. I don't know if it's in the freebsd ports tree though... jms
Re: Martin Hannigan
On Wed, 25 Jan 2006, Joe Abley wrote: The NANOG list administrators can be reached at [EMAIL PROTECTED] That is almost certainly a better place to send comments related to the AUP than the this list. (I would have kept this comment to private mail except that it seems possible that a public discussion about the merits of particular subscribers is about to unfold here, which would be a shame.) Agreed. All: *PLEASE* let this thread die. Allowing it to continue serves no constructive purpose whatsoever. jms
Re: Changing ASNs - Gotchas??
On Fri, 28 Oct 2005, Flint Barber wrote: What are the real gotchas for changing ASNs that people have run into? There is a minor one in terms of route-registry timeliness, I can't update RADB until the change takes place and ISPs don't run their update scripts on my timetable. So I see there might be a gap. If someone knows a strategy there, I would be most appreciative. Beyond that, what extended trouble have engineers seen from remote networks? As background, I am changing an ASN at one location that has 5 ISP peers( all ranked in the top 20) connected to it over the weekend. I have made all of the arrangements with those ISPs the best I can, but am concerned some about propagation beyond them. The ASN was assigned about 60 days ago by ARIN and I have added it to RADB so most filters should have been updated. Anyone know of trouble beyond what I have mentioned or have a strategy to ensure a successful migration to mitigate the gotchas?? Do you have and downstream customer BGP sessions to deal with, or just transits and peers? There really isn't a nice, auto-magic way to guarantee that everything is OK after a change like this. The best you can do immediately is establish a reasonable level of confidence. What I'd suggest: 1) verify with each transit provider that they're hearing AND propagating the prefixes you're announcing to them as you get the sessions reconfigured. 2) verify you're receiving the prefixes you should be - should be pretty much the same as what you were receiving prior to the change 3) verify what you're announcing appears in the public route servers, particularly those not located on networks you're directly connected to. Also verify those prefixes are originated from the correct AS. You may run into places with isolated reachability issues if the remote site does very aggressive BGP flap damping, but those will correct themselves over time. As long as 'the world' sees what you announce and vice versa, you should be in good shape. As for the providers who generate filters based off of IRR data, some of those may have mechanisms to do some sort of a manual filter push to accommodate your needs. jms
Re: multi homing pressure
On Wed, 19 Oct 2005, Todd Vierling wrote: That's the operators' view, but not the customer's. The customer wants redundancy. That's why SLAs exist. SLAs exist to provide a means of allowing a vendor to 'feel your pain' when you experience some type of a service outage. They generally do not exist to act as a cost recovery mechanism for customers who lose revenue when mission critical app XYZ can't access 'the network', people coming in from 'the network' cannot access it. Being able to deduct some percentage of your monthly spend with your carrier often doesn't balance well against a network outage that affects the mission critical app that brings in a substantial percentage of the company's revenue. Each organization's tolerance for outages (read: revenue impact) must be weighed against the costs of multihoming and making the investments in infrastructure to improve relibility. Something like that, but not quite. Whenever one of these reports, which boil down to everyone must multi-home!, appears, it typically has a stark lack of information on alternatives to *direct* multi-homing. Hence Chris's earlier post about the multitude of think tanks which exist to state the obvious and make a buck while doing it :-) Many customers would rather not multihome directly, and prefer set it and forget it connectivity. It's much easier to maintain a multi-pipe connection that consists of one static default route than a pipe to multiple carriers. The former requires simple physical pipe management, which can be left alone for 99% of the time. The latter requires BGP feed, an ASN, and typically much more than 1% of an employee's time to keep running smoothly. I disagree with some of this. I've set BGP up for customers before on many occasions. Many were quite happy with a primary-backup mode of connectivity, which can be accommodated by getting an ASN, configuring BGP on your router(s) and with your upstreams, announcing your route(s) and accepting a default route from those upstreams. My experience has been that these types of setups are also pretty much 'fire and forget' as far as the customer is concerned - *once they're up and running*. If customer XYZ doesn't have the expertise in-house to set it up, they will often bring in a consultant to do it. I do agree that the process of applying for an ASN and so forth can take some time, but it's typically a one-time process. Customers who want to actually attempt to tune traffic to fit the size of their pipes are the ones who require much more time in the maintenance of their BGP environment, and often have higher capex and opex to go with it (bigger router to handle full BGP feeds, $router_vendor support contracts for same, etc). Obtaining single-homed connectivity from a Tier-2 mostly outsources network support, and small to medium size businesses tend to like that. It's not the only leaf end solution to the problem, but it's a viable one (and can be less costly to the rest of the world in turn). That depends greatly on the business need that drives the decision in the first place. Plus, some organizations are finding that locating critical service outside of their borders either voliates their security policies, or can hamper compliance with outside security mandates (GLB, SOX, HIPAA, etc). Maintaining compliance + improving reliability can motivate organizations to multihome. jms
Re: Requesting P.I. Space from ARIN - latest issues?
On Tue, 11 Oct 2005, [EMAIL PROTECTED] wrote: 1) I meet the Multihoming requirement, which means I can get a block as small as a /22, which is about right for my needs. Are there still any concerns about networks (as Verio and Sprint have done in the past) filtering out longer prefixes, and if so, does it depend on whether it;s former class A, B, C or swamp space? I know when I got my current block from my upstream, I had to make sure I got swamp space, because the former class B block they initially allocated to me wouldn't have made it past Verio's filters at that time. Most if not all of the /8s that get assigned to ARIN have a prescribed minimum allocation size. How rigorously that is followed is another story :-) I don't think you can specifically request that ARIN assign you space out of the swamp these days. jms
Re: Cogent/Level 3 depeering
On Wed, 5 Oct 2005, Jeff Shultz wrote: Matthew Crocker wrote: While I realize that the nuke survivable thing is probably an old wives tale, it seems ridiculous that the Internet can't adjust by routing any packets that used to go directly from Cogent to Level 3 though some 3rd (and) 4th (and) 5th set of providers that are connected in some fashion to both... If agreements are in place with those other providers to carry the traffic, then sure. Remember that when backbones peer with each other, they typically (and as normally dictated by peering policies on both sides) only announce their own routes and the routes of their downstream customers and agree not to announce a default route to each other. They do not announce a full routing table to each other. Upshot: When provider X de-peers provider Y, single-homed customers of either provider will likely have problems reaching single-homed sites of the other. Some of it comes down to the mob-rule mentality. The hope (though not often publicized :-) ) is that the de-peerER will force the de-peerEE into buying transit from them to get the de-peerEE's customers to stop calling in saying I can't get to site BLAH - FIX THIS! The de-peerEE (or their customers) may opt to try their case in the court of public opinion and try to get the de-peerER to reverse their stance and stop being 'the bad guy' :-) Irresistable force, immovable object. I now return you to your regularly scheduled programming. jms
Re: Cogent/Level 3 depeering
On Wed, 5 Oct 2005, Todd Vierling wrote: On Wed, 5 Oct 2005, Matthew Crocker wrote: This comes down to a little more than just depeering -- at least in the BGP sense. There's active route filtering going on as well if connectivity is dead; after all, I can bet the house that at least one of Cogent's network edge peers has connectivity to Level3, and vice versa. People who are single-homed to either Cogent or Level(3) are the ones who are most likely to feel the pain of broken connectivity. jms
Re: Address Space ASN Allocation Process
On Mon, 26 Sep 2005, Vicky Rode wrote: Just trying to get some clarity and direction regarding obtaining address space/ASN for my client. Is there a minimum address space (?) an entity would need to justify to go directly to RIR (ARIN in this case) as opposed to the upstream provider? Is /20 the minimum allocation? Can my client approach RIR and request for a /23? If you ask for a /23, at this point, ARIN will most likely tell them to get additional space from their upstream. If the organization is utilizing at least a /23's worth of space now and ready to multihome, they can request a /22 from ARIN. Their IPv4 allocation policies are documented here: http://www.arin.net/policy/nrpm.html#four If my client do procure a /23 how do they make make sure that this address space will be globally routable? I would recommend they register a maintainer, AS and appropriate route objects in the RADB or one of the many IRR mirrors. Some carriers build their filters based off of IRR data. That's still not a guarantee of global routability, but keeping their records in good order is a good start. Multihome will also be part of their network implementation, can they apply for an ASN number? They can apply if they're close to being ready (within 30 days) to multihome. You (your client) needs to be able to announce at least one /24 to two or more upstream providers in order to meet ARIN's criteria for assignment of an ASN. ARIN's ASN criteria are documented here: http://www.arin.net/registration/guidelines/asn.html jms
Re: 3 men die in weekend crashes
On Tue, 6 Sep 2005, [EMAIL PROTECTED] wrote: 3 men die in weekend crashes While tragic, how is this even *remotely* on-topic for this list? jms
Re: SWIP and Rwhois in the Real World
On Wed, 7 Sep 2005, Edward Lewis wrote: Their rwhois seems to be terminally down. Can we reclaim 4/8 from them now? Who is we? IANA says it belongs to BBN (ARIN not mentioned): http://www.iana.org/assignments/ipv4-address-space 004/8 Dec 92 Bolt Beranek and Newman Inc. 4/8 is most definitely a legacy allocation, which I don't believe ARIN has any power to reclaim unless Level3 surrenders it voluntarily (not likely). jms
Re: SWIP and Rwhois in the Real World
On Tue, 6 Sep 2005, Steve Gibbard wrote: Sometimes, they've gone on to repeat the lack of documentation followed by a mad scramble a time or two, but the lesson generally gets learned eventually. Agreed. That sort of record-keeping seems to come over time as part of the evolution of an ISP from the small start-up or mom-and-pop phase where such records are often cobbled together. Deploying good provisioning systems to tie things like IP addresses assigned to customers to an actual customer record and so forth usually come later in an ISP's evolution. I've seen some smaller ISPs that really had their act together re: record keeping, but way more who didn't. jms
RE: Katrina could inundate New Orleans
On Mon, 29 Aug 2005, Hannigan, Martin wrote: Some of this is on topic. Internet access is as important as the lights or water being on. Right, get out, but it'll be good to see reasonable updates on what's going on utilities wise down there when the weather shifts. I'm sure other infrastructure providers are watching Katrina's track closely as it heads inland. Wind becomes less of an issue as the storm degrades, but there's still plenty of rain left in a tropical storm or a tropical depression to cause major flooding well away from the hurricane makes landfall. Pittsburgh, PA is pretty far inland, but the remnants of Ivan last year did a real number on us last September. A number of COs in low-lying areas did receive at least some flood damage, with a small handful being taken out of service completely. jms
Re: After Hours Install of OC3
On Fri, 12 Aug 2005, Greenhagen, Robin wrote: Does anyone else require HICAP loop installs to be after hours? What experiences have you had (good or bad) with getting the carriers to do their work during off-peak hours for a reasonable fee? We've done off-hours turnups before, at my previous job with a decent-sized ISP. Some would come back with an off-hours turnup fee which we would turn around beat up our sales rep for, and they would usually reduce or waive it. Most of the fees were pretty low, like $500 or so. $5-$10k seems exorbitant for what amounts to a 'no shutdown', doing some basic acceptance testing and maybe, at the edge of the envelope, turning up a BGP session and testing that, too :-) I'd suggest talking to your sales rep to see if the Free Install promo extended to off-hours activations, or better yet, beat your sales rep up and see what happens... We did off-hours turnups for our customers if they requested it. jms
Re: /8 end user assignment?
On Thu, 4 Aug 2005, Stephen J. Wilcox wrote: I had said elsewhere this was unprecedented but was then pointed at 73.0.0.0/9, 73.128.0.0/10 which is Comcast assigned in April. I'm surprised none of these assignemtns have shown up on mailing lists.. I suspect this was done on the condition that Comcast migrate users from other IP ranges into 73/8.5, then return those older ranges to ARIN for reassignment. The net effect would be that Comcast could significantly reduce the number of routes they'd have to announce into the global BGP table. 12+ million addresses is a lot of cable modems :-) I don't work for Comcast, so this is purely conjecture on my part. jms
Re: source for GIS-correlated fiber conduit data
On Mon, 4 Jul 2005, Sam Crooks wrote: Can anyone point me in the direction of a source for fiber cable installations correlated to GIS data? You will probably have difficulty in getting this from your carriers of choice. Chances are, if they provide anything at all, it would be done under NDA. jms
Re: source for GIS-correlated fiber conduit data
On Tue, 5 Jul 2005, Christopher L. Morrow wrote: On Tue, 5 Jul 2005, Justin M. Streiner wrote: On Mon, 4 Jul 2005, Sam Crooks wrote: Can anyone point me in the direction of a source for fiber cable installations correlated to GIS data? You will probably have difficulty in getting this from your carriers of choice. Chances are, if they provide anything at all, it would be done under NDA. Didn't Sean Doran do this out of GMU about 2 years ago? and get slapped with some silly classification by the us-gov for it? (or am I thinking of another sean?) I do recall someone pulling together data that got a lot of the homeland security types all riled up, but I don't recall the source. From past experience, the OSP route maps I've seen for $CARRIER have been 1) done under strict NDA (we will show you the map only in our presence, you cannot keep it, make copies, scan it, smell it, touch it, etc) and 2) only for very specific cable routes that were directly relevant to my original request. jms
Re: Reback SMS / DSL packet loss issue.
On Wed, 18 May 2005, Stephen Fulton wrote: Occasionaly clients connected via ATM PVC's experience packet loss after reconnecting due to power loss. The line sync is fine, but packet loss of between 40 - 60% occurs. Only once I've used clear sub subscriber to disconnect the session does the packet loss stop. Anyone know why that would be? Which model of SMS is this and what version of code are you running? Also how are the customers connecting to you (bridged, one PVC per customer/static, PPPoE, PPPoA, etc...)? It's been a year or so since I've had my hands on an SMS box, but I can try to blow the dust off of my brain. Also, if you have a support contract with Redback, have you floated this past their TAC? jms
Re: Qwest protests SBC-ATT merger as harmful to competition
On Tue, 19 Apr 2005, Alex Rubenstein wrote: That may be, but they are right. If Qwest would have won the bid, then it would be up to Verizon to cry foul - and rest assured they would. Funny how that works :-) Do you think anyone will benefit from Verizon+MCI? After this merger, the incumbent ILEC in a huge market area will also own the only real CAP (remember Brooks and MFS?). Isn't it bizarre that it is possible that a regulated LEC will also own an unregulated CAP, which currently competes (vigorously, I might add) with the LEC? Do you think anyone will benefit from ATT+SBC? No. I didn't (and don't) agree with SBC+ATT, Verizon+MCI, or Qwest+MCI, if that one would have happened. Verizon will also get to expand their portfol-- er... patchwork of unrelated provisioning systems, engineering, support organizations with no less than 4 or 5 dozen different access numbers to call for support or troubleshooting, depending on what you want. MCI never fully integrated the MFS assets (MFS was bought _how_ many years ago???), and Verizon's track record for integration is no better. Bottom line: don't count on any economies of scale to come from this merger. Both mergers stink to high heaven. And we can probably rest assured that the FCC does not have the consumers' best interest in mind. They haven't for quite a long time. jms
Re: Anyone familiar with the SBC product lingo?
On Thu, 14 Apr 2005 [EMAIL PROTECTED] wrote: (Anybody here *NOT* seen cases where the 2 fibers leave the building on opposite sides, go down different streets - and rejoin 2 miles down the way because there's only one convenient bridge/tunnel/etc over the river, or similar?) Sure, quite often in fact. Ever been to Pittsburgh, PA? :-) The vast majority of the time, the route between point A and point B requires multiple bridge and/or tunnel crossings. jms
cable management systems
I've been tasked with evaluating cable management software systems for my employer. I work for a large university with 30-35,000 phones and roughly as many computers spread across 100+ buildings in 5 campuses, with substantial copper, coax, and fiber plants. That said, I'm much more interested in peoples' real-world experiences using CMS software packages in large multi-building environments than I am in vendor marketing materials. Feel free to respond to me off-list if you like. If you use some type of CMS package, did you buy it or built it in-house? Does it integrate with your existing workflow/trouble ticketing systems? Does it integrate with your existing network management/monitoring tools? What processes do you have in place to make sure moves/adds/changes (MACs) are processed through the CMS all the time, every time? There could be both technical and procedural/policy components to this. A CMS with stale data is often worse than having no CMS at all. If you are a CMS software vendor, you may contact me off-list. jms
