European packet loss average increasing
My non-scientific measurements (i.e. pings to well known european sites) show an increase in packet loss to about 6%, the 10 day average previously was less than 1%. Neither ns.ebone.net nor auth1.ebone.net are answering queries. BGP data still looks normal KPNQwest data http://bgp.potaroo.net/as286/ So far I don't see much change in traffic levels at LINX http://www.linx.net/tools/stats/index.thtml AMS-IX graphs seem to have a glitch, or one heck of a DDOS. http://www.ams-ix.net/hugegraph.html
Re: Sprint peering policy
I don't post here much but since i have been asked a direct question i will give an answer and a factoid or two and ask a question or two of my own >Perhaps we need NANOG-OldFarts mailing list? yes -says one old fart how about a list with a charter of discussing industry changes that might find some islands of stability in the on going industry collapse? one that examines some of the fundamental ways in which the economics of the industry is changing? >T3 lines were technically >available and priced by 1990; nobody had the money or customer demand >to justify getting them. They were being used by telcos to upgrade >their POTS services, for the internet the T-3 backbone upgrade was the highly relevant part. ANS was formed as a public private partnership to give IBM an opportunity for a test bed (via the NSFNet backbone) to develop hardware that could route IP packets at 45 megs. The upgrade was announced in early 1991 but it was a LONG time (late 92 early 93 before ANS was moving packets at that speed. (See brock meeks expose of merits claims on the T3 NsfNet backbone that ran in the july 7 1992 issue of communications daily.) > >Are you talking about Net99 here? > >I can't even remember what year Net99 kicked off... >Must have been what, 1994? I was chatting with >Joe Stroup by cellphone from my inlaws place >during their pre-launch nationwide tour, and the >inlaws moved in there in 1994. Historical footnote - I was the person who introduced joe Stroup to karl Denninger I think in the summer of 1993 maybe it was spring 94. > >Yes... Cook report 3.07 summary, Sept/Oct 94, >seems to confirm that timing. yes stroup and denninger announced their plans at or around the time of the CIX meeting in september >Announced late 94, >rolled out early 95. [Side note: Gordon, for historical >purposes, would it be unreasonable if we asked you to >make the full reports freely available if they're >older than say 5 years? 3 years? Or are you >still making money off the archaic gathering dust >ones ... 8-) ] Since YOU ASKED. When Creative Commons goes live in the fall I believe that pretty much everything you have just asked about will be available there under a public domain but no commercial use license. > >1995 is not going back nearly far enough. > >I'm talking about pre-CIX (remember that?). CIX was announced at my Feb 14 1991 OTA workshop by susan estrada and bill schraeder...rick adams was supposed to be there but was sick. al weis was there...cix was a move against ANS >Pre-NAPs. Pre-any-telcos-routing-IP. > >Man, 1992-4 were busy years, though. > > >-george william herbert >[EMAIL PROTECTED] Finally I'd like to ask a question in return. I am trying to look at what will grow up on the ashes of the current industry collapse. We are beginning to see gigabit ethernet over municipally owned dark fiber networks. Fiber to the home is beginning to appear in a few isolated areas. World Wide Packets has a business model predicated on that. As more build outs continue in places like quebec, and grant county washington and provo utah, ashland oregon, stockholm and other places around the globe, you have a potential new business opportunity for folk to use the Internet for the delivery of bandwidth intensive content and services to these municipally owned networks. As bandwidth prices plunge this model LOOKs attractive until it runs into the reality of the cost of tier one transit. That cost, i suspect, renders it of doubtful viability. With regard to this issue however Paul Vixie's comments on peering have been especially interesting. Are there folk with adequate routes and connectivity that would undertake to form a network that might be independent of the current internet core back bone of what (112,000 routes?) on top of which sit the half dozen or so Tier one players that peer primarily with each other and demand transit $$$ from everyone else? Web and email stay on the legacy backbone...new services migrate to a backbone with a cost structure unencumbered by the tier one oligopolists? Now i realize there may be plenty of issues that render this suggestion absurd. But i sense from the recent peering discussion here and from other conversations i have had that there is a fair amount of discontent with the current tier one peering oligopoly and that some folk are exploring ideas for evolution given current market conditions. Since this does not mesh well with the operational charter of NANOG, i think we likely need to take any discussion elsewhere. Anyone who has ideas, means and interests to discuss these issues please mail me off list. Yes this does fit in with other things that I am researching and writing about. see http://cookreport.com/11.05-6.shtml There is plenty to lament about what has happened to all of us. However, I think that it is useful to look ahead at how we may eventu
Re: Sprint peering policy
Perhaps we need NANOG-OldFarts mailing list? >> I think this is putting the cart before the horse. >> >> We were getting upgraded bandwidth capabilities, >> fiber put in the ground, etc from traditional Telcos >> prior to the rise of the Internet; they were finding cheaper >> ways to run phone service around. > >This is totally incorrect. Ask anyone who had been in this business from the >beginning of nineties, not late nineties. How about people who were in the business or doing engineering on WANs in the late 80s? >Telcos, while upgrading their >systems, happily pointed at the PUC filings and sold you DS1 that went two >blocks for $700 per month, that being inside a city. The local loop situation was, and in many cases remains, a major problem point; at one point, the ISP I was with was paying more for the last mile from C&W facilities in each city to our POPs than for the long haul T-1 lines forming the nationwide backbone. We dropped our total telco costs by about 10% by locating our main NOC in a building housing C&W and AT&T Longlines facilities and calling in a contractor with a concrete drill to run conduit up through our ceiling into the AT&T and C&W machine rooms... All of that said, the long distance lines were already negotiable, and getting very rapidly more so, in 1991 and 1992. >> The rise of the Internet as a telecom bandwidth demand >> driver attracted the attention of investment bankers >> and capital, which then became somewhat of a set of >> complex feedback loops (capital going into all sorts >> of internet industries, infrastructure, etc, partly >> because it appeared to be good business and partly >> because of hype). The result was that speculation >> and hype drove overcapacity. > >This again is incorrect. The rise of content attracted investment bankers. Oh? And here I am wondering why the fiber plant growth started its serious upswing in the late 80s, prior to the invention of HTTP/HTML. >> Before anyone had invested serious money in any of >> the internet infrastructure companies, people were >> building out 10 megabit, T3 backbones and were talking >> to telco gear providers about what it would take to >> do 155 megabit and 622 megabit backbones and so on >> and so on. > >This is again incorrect. The people that you are talking about were UUNET >and MCI, and we are talking 1994. That's years too late. UUNet had some 10 megabit WAN links while I was still in college, using those crazy 10meg-ethernet-into-SONNET custom hardware boxes if I remember right. T3 lines were technically available and priced by 1990; nobody had the money or customer demand to justify getting them. They were being used by telcos to upgrade their POTS services, but people were already asking what we could do with them with pure stream IP data, and looking at the OC-3 and OC-12 protocols as they developed, though that was mostly driven by LAN rather than WAN. >> It was clear to those of us in the late >> 80s and early 90s that if demand kept pulling, we needed >> to keep creating bandwidth. > >There had not been demand in 80. Neither had there been demand in the >beginning of 1990s. Strange. When I started using the Internet, *the* T-1 backbone wasn't all done yet. I got a bad name a couple of times by pulling X11 releases down from MIT at times of day that it caused noticable delay in the rest of the country's coast-to-coast IP traffic. By the time I graduated college, there were three backbones, and T-1 was no longer the hottest WAN technology in use. The demand growth curve goes back a long, long ways, Alex. >> But in no way can you claim that it took a terabuck >> in capital push to make it happen. Demand pull was >> fully operational and working just fine before >> ISPs started being snapped up by phone companies >> and visa versa, and the huge money came into play. > >Yes I can. It did take terrabucks to get this industry rolling. You are mistaking terrabucks invested in capacity push as opposed to responding to demand pull. Demand pull is fine; when there's demand, if the cost model works out, you invest to support it. Capacity push is speculation on a growth curve. We didn't need that, though everyone who likes dark fiber now is acting like a kid in a candy shop since a terabuck or so was wasted on overprovisioning it... >> Hype might have been lower and growth somewhat >> slower, but I can easily see the set of people >> who were building out backbones with T-1s and >> the early fiber links having grown them up to >> networks capable of today's traffic. > >Are you talking about Net99 here? I can't even remember what year Net99 kicked off... Must have been what, 1994? I was chatting with Joe Stroup by cellphone from my inlaws place during their pre-launch nationwide tour, and the inlaws moved in there in 1994. Yes... Cook report 3.07 summary, Sept/Oct 94, seems to confirm that timing. Announced late 94, rolled out early 95. [Side note: Gordon, for histori
Re: Sprint peering policy
On Tue, 02 Jul 2002 16:13:46 CDT, Richard Irving <[EMAIL PROTECTED]> said: > > This crossed my desk, thought someone might find it > relevant.. (I am not sure who wrote it... ;) > router> conf t > # > Date: Tue, 2 Jul 2002 08:28:04 -0600 Credit where it's due: http://www.satirewire.com/news/june02/ceonistas.shtml msg03299/pgp0.pgp Description: PGP signature
Re: Sprint peering policy
This crossed my desk, thought someone might find it relevant.. (I am not sure who wrote it... ;) router> conf t #
Determining the ingress interfaces
Hi I asked the following question here a few weeks back, and got suggestions to use "traceroute -g," traffic filters, and assume bi-directional paths are same. How do we determine the appropriate peer AS, and hence ingress interface(s) at an ISP's border routers, for traffic arriving _from_ IP address blocks not allocated to the ISP, and destined _to_ specific IP address(es) within the ISP's network ? In other words, how do we create a mapping between non-ISP-owned address blocks and the ISP's peer ASs, such that given a non-ISP-owned address block, we can determine the peer AS thru which traffic from the address block enters the ISP's network? So do you BGP-gurus think that the following approach answers the question? I would greatly appreciate your feedback. Approach: Use data from BGP tables of as many ASs as possible. One candidate that can provide such data is the routeviews project at Univ of Oregon run by Dave Meyer. The routeviews server maintains eBGP sessions with about 63 BGP speakers, and dumps "sh ip bgp" every 2 hours. Filter out all entries from latest routeviews data with destination IP address(es) that we care about listed as "Network." May need to include larger address blocks belonging to ISP as well, since destination IP address(es) may have been aggregated into them by some ASs. For each address block filtered above, determine all ASs that are peers with the ISP's AS. This can done by creating a set of all ASs that appear immediately to left of ISP's AS for each path listed to address block, making sure there are no repetitions of ASs in the set. For each peer AS, create many-to-one mapping from source ASs to peer AS. (source ASs are all ASs on each AS path, except peer AS and ISP's AS; check that no source AS maps to multiple peer AS). Associate IP address blocks with each source AS (partly using routeviews data, partly thru ARIN d/b, etc), thus creating mapping from non-ISP-owned IP address blocks to peer ASs. Use network topology info for ISP's network to determine mapping between peer AS and ingress interface(s). Example usage of approach: Determine mapping of source ASs to peer ASs for destination IP address 4.2.101.20 on Genuity's network. (Genuity only used as an example here) Relevant data from routeviews oix-full-snapshot-2002-06-23-1000.dat in "sh ip bgp" format: Network Next HopPath * 4.0.0.0 193.0.0.56 9057 3356 1 i (some lines deleted) * 217.75.96.6016150 8434 286 1 1 (some lines deleted) * 141.142.12.11224 38 10514 3356 1 i (some lines deleted) * 4.2.101.0/24 141.142.12.11224 38 6325 1 i * 202.249.2.867500 2497 1 i * 203.194.0.5 9942 1 i * 66.203.205.62 852 1 i * 167.142.3.6 5056 1 e * 206.220.240.95 10764 1 i * 157.130.182.254 19092 1 i * 203.62.252.26 1221 4637 1 i * 202.232.1.912497 1 i *> 4.0.4.901 i Destination IP address: 4.2.101.20 Destination AS: 1 Relevant IP address blocks: 4.0.0.0, 4.2.101.0/24 Peer ASs: 3356, 286, 6325, 2497, 9942, 852, 5056, 10764, 19092, 1221, 2497 Source ASs: , 9057, 16150, 8434, 1224, 38, 10514, 7500, 1221 Mapping from source ASs to peer ASs: Peer AS Source AS 3356, 9057, 10514 286 16150, 8434 63251224, 38 24977500 46371221 The approach is based on the observation that each AS only advertises to its peers the "best" route it knows to a specific destination network. So given an AS path to a destination network in the routeviews data, the "best" path that traffic from each of the source ASs on the path would take to the destination network can be determined. e.g. * 4.0.0.0 141.142.12.1 0 1224 38 10514 3356 1 i The "best" path for local traffic of 1224 to 4.0.0.0 is 38-10514-3356-1; "best" path for local traffic of 38 is 10514-3356-1; "best" path for local traffic of 10514 is 3356-1; Hence the peer AS to use for getting to destination network can be determined for local and transit traffic of each source AS. (Is this true?) The effectiveness of the approach is dependent on the number of views captured in the "sh IP bgp" data. i.e. the more paths that are listed for a destination network, the more mappings from source ASs to peer ASs can be determined. Thanks. Rajesh.
RE: AOL mail netblocks
Yes we do filter SMTP outbound from the dialup base. You are correct that our users should not have local mail servers. I can't speak to whether we constantly filter or only filter when we notice a problem. It's also possible that the spammers somehow figure out how to get around our filters from time to time. The end users source address ranges are the our IRR( whois.aoltw.net) under the route set RS-ATDN-DAHA. The data is also in the RADB. If there are specific questions please send them off-list. I may ICMP-REDIRECT you to our NOC though. Thanks, Cleve... > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Martin Hannigan > Sent: Tuesday, July 02, 2002 11:03 AM > To: [EMAIL PROTECTED] > Cc: Daniska Tomas; [EMAIL PROTECTED] > Subject: RE: AOL mail netblocks > > > > On Tue, 2 Jul 2002 [EMAIL PROTECTED] wrote: > > > On Tue, 2 Jul 2002, Martin Hannigan wrote: > > > > > I was hoping someone was going to say that "AOL already does this > > > themselves". In the 'old' days, there was a list of what to allow > > > under .ipt.aol.com. It's pretty easy for them to do it, and I'm > > > guessing that they do actually filter this outbound, or their > > > managed modem providers may, I'm just looking for a confirmation. > > > > I don't think they do filter outbound SMTP. I've gotten complaints from > > AOL dial-up users that AOL does not filter outbound SMTP, and that they > > don't provide outgoig SMTP servers (hard to believe), so we should not > > block AOL dial-up addresses, because these people have to run their own > > SMTP servers. My thought/feeling on this is "BS and apathy". The vast > > vast majority of AOL dial-ups have no business doing direct-to-MX email. > > The handful that think they do can find workarounds or a more > appropriate > > provider. > > Ok then, is there a place where I can bath myself in AOL > dialup identified netblocks? > > I'm not trying to start a spam discussion here on the Operations > list just get some operational information. > -M > > Cleve Mickles Network Architecture America Online, Network Operations
RE: Total Traffic. Was: Sprint peering policy
On Tue, 2002-07-02 at 15:58, Geo. wrote: > > > I typically have a 251Kbps (broadband) stream from www.thebasement.com.au > > Speaking of streaming, I once saw this mentioned here, does anyone have the > current URL for the 300K streak for BBC news? http://www.bbc.co.uk/newsa/n5ctrl/tvseq/bb_news_ost.ram -- = Giles HeronPrincipal Network ArchitectPacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" =
performance testing/monitoring
hate to break up the peering thread but i'm wondering if anyone has experience/knowledge of Empirix tools? i worked with them back when they were known as midnight networks but they focused on protocol conformance testing at the time (mid-90s). they're "corporate history" has no mention of midnight though. they do seem to have some network simulation tools which i'm also interested in. heck, i think someone might have even asked about that in the last few days so maybe this is a relevant/appropriate topic. will take replies off-list if not. -b
Re: Sprint peering policy
On Mon, 2002-07-01 at 17:53, Paul Vixie wrote: > > > What is the connection between unregulated peering and the financial > > difficulties we have seen? > > > > The problems have been caused by: > > > > - Bad business models > > - Greed > > - Corporate officers who have shirked their fudiciary responsibilities to > > the stockholders > > > > If you can somehow tie peering into this, please be my guest, but it would > > be a bit of a stretch. > > you've asked and answered your own question, though. remember, wcom tried > to buy sprint and it was only the EU's antitrust folks who stopped them. And I like to think that my demonstration of the insane paths that packets travelled to Wcom, which I made to the anti-trust tribunal at the time, helped to get that purchase stopped.
RE: Total Traffic. Was: Sprint peering policy
> I typically have a 251Kbps (broadband) stream from www.thebasement.com.au Speaking of streaming, I once saw this mentioned here, does anyone have the current URL for the 300K streak for BBC news? Geo.
Re: Opnet, Wandl, etc.
>We are looking into using a full or partial mesh MPLS overlay for traffic >characterization on our network and need a tool to model utilization and >simulate failures. At first we won't be doing any real TE. The MPLS network simulator perhaps? http://flower.ce.cnu.ac.kr/~fog1/mns/ There's something called Deriveit that you can get on a 30 day trial which might be sufficient for some people. --Michael Dillon
OT: Total Traffic. Was: Sprint peering policy
Richard, I know a few news server admins who might disagree with you. Or at least it seems that way at times. ;) I typically have a 251Kbps (broadband) stream from www.thebasement.com.au running in the background when on line. The stream is coming out of Australia (don't think it's been Akakamized yet. Did I spell that right?) so that stream is on a US backbone. That's in addition to anything else I may be doing. This is only a single point of data but single points eventually add up to a bucket. Additional thoughts. Wonder what that peak traffic would be if individual sites and services weren't as rate limited as most are by pipe size, hardware or software? Or how about a 6Gbps HDTV video conference stream (UCLA (?)- MIT on Internet2). Just my 2¢. The delete key is your friend. -Al Rowland -Original Message- From: Richard A Steenbergen [mailto:[EMAIL PROTECTED]] Sent: Monday, July 01, 2002 6:07 PM To: Stephen J. Wilcox Cc: Deepak Jain; Miquel van Smoorenburg; [EMAIL PROTECTED] Subject: Re: Sprint peering policy On Tue, Jul 02, 2002 at 12:47:36AM +0100, Stephen J. Wilcox wrote: > > I'm curious about all these comments on bandwidth, "few Mbs is > nothing", "dropping OC48 to IXs". > > Theres an imbalance somewhere, everyone on this list claims to be > switching many gigs of data per second and yet where is it all going? > Not on the IX graphs anyway > > Did someone mention large bandwidths and everyone else felt they > needed to use similar figures or is everyone really switching that > amount but just hiding it well in private peerings? I know theres some > big networks on this list but theres a lot more small ones.. It's all so much posturing, just like the people who claim they need OC768 now or any time in the near future, or the people who sell 1Mbps customers on the fact that their OC192 links are important. If there is more than ~150Gbps of traffic total (counting the traffic only once through the system) going through the US backbones I'd be very surprised. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Opnet, Wandl, etc.
We are looking into using a full or partial mesh MPLS overlay for traffic characterization on our network and need a tool to model utilization and simulate failures. At first we won't be doing any real TE. Does anyone know of any open source tools (maybe similar to Wandl) that have this functionality? I could do what I need with spreadsheets really but it would be more time intensive. Thanks -Tom __ Tom Holbrook Sr. Network Engineer Atlanta Earthlink
Re: Sprint peering policy
> > If your full cost of peering with UUNET (including things such as > > depreciation) comes to $400 per mbit/sec and via a promisig local ISP you > > can get transit to UUNET at $200 per mbit/sec, your costs will decrease. > > Just because the IP is free with peering does not mean that it costs $0 to > > peer. > > Nor does it cost $0 on top of that $200 to buy transit. Really? I did not know that the quotes that I get do not say that they give me a free router and $0 install cost. > This may hold > true to some degree for a small-ish network, but probably not for a > larger one. Even factoring in depreciation, line cards, etc, I would > imagine you won't find OC3 transit in 4 cities from any ISP to be as > cheap as OC3 peering in 4 cities, for example. Add to that the chance > that, as a larger network, you'll probably be getting your pipes at > volume discounts. I can from the top of my head, without breaking NDA name at least 1 promising local ISP. > I never meant to imply that peering is 0-cost. I just don't agree with > the blanket statement that peering (or lack thereof) has no financial > impact. Peering networks, at this time, have very significant downside effect to fiancials that I can see, unless you are talking about UUNET, Sprint, AT&T, Level3, Q and C&W. Alex
Re: Sprint peering policy
> > I think this is putting the cart before the horse. > > We were getting upgraded bandwidth capabilities, > fiber put in the ground, etc from traditional Telcos > prior to the rise of the Internet; they were finding cheaper > ways to run phone service around. This is totally incorrect. Ask anyone who had been in this business from the beginning of nineties, not late nineties. Telcos, while upgrading their systems, happily pointed at the PUC filings and sold you DS1 that went two blocks for $700 per month, that being inside a city. > The rise of the Internet as a telecom bandwidth demand > driver attracted the attention of investment bankers > and capital, which then became somewhat of a set of > complex feedback loops (capital going into all sorts > of internet industries, infrastructure, etc, partly > because it appeared to be good business and partly > because of hype). The result was that speculation > and hype drove overcapacity. This again is incorrect. The rise of content attracted investment bankers. > Before anyone had invested serious money in any of > the internet infrastructure companies, people were > building out 10 megabit, T3 backbones and were talking > to telco gear providers about what it would take to > do 155 megabit and 622 megabit backbones and so on > and so on. This is again incorrect. The people that you are talking about were UUNET and MCI, and we are talking 1994. > It was clear to those of us in the late > 80s and early 90s that if demand kept pulling, we needed > to keep creating bandwidth. There had not been demand in 80. Neither had there been demand in the beginning of 1990s. > But in no way can you claim that it took a terabuck > in capital push to make it happen. Demand pull was > fully operational and working just fine before > ISPs started being snapped up by phone companies > and visa versa, and the huge money came into play. Yes I can. It did take terrabucks to get this industry rolling. > Hype might have been lower and growth somewhat > slower, but I can easily see the set of people > who were building out backbones with T-1s and > the early fiber links having grown them up to > networks capable of today's traffic. Are you talking about Net99 here? Alex
RE: AOL mail netblocks
On Tue, 2 Jul 2002 [EMAIL PROTECTED] wrote: > On Tue, 2 Jul 2002, Martin Hannigan wrote: > > > I was hoping someone was going to say that "AOL already does this > > themselves". In the 'old' days, there was a list of what to allow > > under .ipt.aol.com. It's pretty easy for them to do it, and I'm > > guessing that they do actually filter this outbound, or their > > managed modem providers may, I'm just looking for a confirmation. > > I don't think they do filter outbound SMTP. I've gotten complaints from > AOL dial-up users that AOL does not filter outbound SMTP, and that they > don't provide outgoig SMTP servers (hard to believe), so we should not > block AOL dial-up addresses, because these people have to run their own > SMTP servers. My thought/feeling on this is "BS and apathy". The vast > vast majority of AOL dial-ups have no business doing direct-to-MX email. > The handful that think they do can find workarounds or a more appropriate > provider. Ok then, is there a place where I can bath myself in AOL dialup identified netblocks? I'm not trying to start a spam discussion here on the Operations list just get some operational information. -M
Re: True cost of peering (was Re: Sprint peering policy)
> NYIIX 1/4 rack + 100M switch connection - <$1K/mth > fiber cx for Gig-E to high-bandwidth peers: $0/mth > small GSR12000 - $20K from the local bankruptcy trustee > OC192 from Manhattan to Vienna, VA: $10K/mth > SIX is also quite inexpensive. > I've been told Equinix can be talked down from ~$3K/mth for a rack/power & > a couple cx to <$1500/mth. > > 2 years ago you couldn't build a coast-to-coast backbone and get peering > costs < $50/mbit. Now my rough calculations put it at ~$20/mbit if you do > it on the cheap. D-e-p-r-i-c-i-a-t-i-o-n. S-a-l-a-r-i-e-s. Alex
Re: True cost of peering (was Re: Sprint peering policy)
> > NYIIX 1/4 rack + 100M switch connection - <$1K/mth > > fiber cx for Gig-E to high-bandwidth peers: $0/mth > > small GSR12000 - $20K from the local bankruptcy trustee > > OC192 from Manhattan to Vienna, VA: $10K/mth > > SIX is also quite inexpensive. > > I've been told Equinix can be talked down from ~$3K/mth for a rack/power & > > a couple cx to <$1500/mth. > > The following problems exist with your plan: > > * 10Gbps circuit to a 100Mbps peering point... Are you sure your name >isn't Nick Catalano? With $0/mth cx fees from telehouse, it only makes sense to use the NYIIX switch for low-bandwidth peers, and do a private interconnect with the rest. > * What peers do you plan to find at NYIIX that you'll be doing Gbps to? 6461, 4323, & 4513 would be good candidates. > * OC192 interfaces don't grow on trees (or even ebay yet) Yeah, right now the best price point is for OC48 - I've seen used OC48 linecards for $2K. This time next year I expect to start seeing OC192 cards on the used market. > * Two peering points on the east coast won't get you squat Yeah, the point was to show just how cheap things are now. Adding Chicago, Seattle, & Pao Alto should be enough to satisfy peering requirements for 75% of your traffic. > * Crosscountry circuits are just a tiny bit more expensive Depending how you buy them - buying the backbone assets of a defunct carrier that has a bunch of OC48 & 192 lambda IRUs with 15+ years left on them should work out quite cheap amortized over the remaining IRU term. Next up on the auction block... Teleglobe. -Ralph
RE: Ebone going off the air (at last)...
the shutdown is in process see the webcam or #ebone... -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: 2. júla 2002 15:43 > To: [EMAIL PROTECTED] > Subject: Re: Ebone going off the air (at last)... > > > > >From what I can see personally, all BGP sessions with Ebone at major > >peering points in Europe went down in the last two hours, > and all their > >customer interfaces appear to be shut (or in the process of > being shut > >down). SDH and DWDM customer circuits are also being torn down as we > >speak. > > Hmmm > Try a traceroute from inside the Ebone IP network at > http://www.ebone.net. > A few minutes ago it was still > working. > > Have you got any confirmation that they are, in fact, > shutting down the > DWDM equipment? This would leave everyone in the dark except for IRU > customers... > > --Michael Dillon > ex-Ebone > > >
Re: Ebone going off the air (at last)...
>From what I can see personally, all BGP sessions with Ebone at major >peering points in Europe went down in the last two hours, and all their >customer interfaces appear to be shut (or in the process of being shut >down). SDH and DWDM customer circuits are also being torn down as we >speak. Hmmm Try a traceroute from inside the Ebone IP network at http://www.ebone.net. A few minutes ago it was still working. Have you got any confirmation that they are, in fact, shutting down the DWDM equipment? This would leave everyone in the dark except for IRU customers... --Michael Dillon ex-Ebone
Re: Ebone Shutdown
Sad (and mad as Hell) to lose a good old friend (Ebone). JPEG attachment says it all. --Steve -- <>
Ebone going off the air (at last)...
Yes, I realize this is NANOG and a lot of people here doesn't seem very interested about events over in Europe, but for those who might be interested and have not already seen this: http://nocpeople.org/ebone/broadcast2.html >From what I can see personally, all BGP sessions with Ebone at major peering points in Europe went down in the last two hours, and all their customer interfaces appear to be shut (or in the process of being shut down). SDH and DWDM customer circuits are also being torn down as we speak. Note, this is only the Ebone part of the bankrupt network, not the KPNQwest part. So, guess it's time to finally wave goodbye... -Lars Erik
Ebone Shutdown
http://www.nocpeople.org/ebone/broadcast2.html
RE: Sprint peering policy
The original comment I made was regarding the amount of traffic people suggest they have on their networks. I know UU, L3, Sprint, Verio etc will carry many gigabits but it was concerning the average list member rather than the exceptional major player... Answers so far vary.. Steve On 2 Jul 2002, Giles Heron wrote: > > On Tue, 2002-07-02 at 02:00, Grant A. Kirkwood wrote: > > > > At 09:54 PM 7/1/2002 -0400, Phil Rosenthal wrote: > > > > >My math shows ~500bps per US citizen: > > >Assuming 150,000,000,000 bits and 280,000,000 citizens. > > > > This also assumes US citizens don't sleep. > > and that non-US citizens never send traffic through the US or send > traffic to/from servers in the US. > > Given that traffic from Europe to Asia almost always goes via the US, > and given that it isn't unheard of for traffic between major European > ASs to go via the US (e.g. 702 and 9057 right now) then the former > assumption is clearly untrue. > > I think the fact that I'm sending this invalidates the second one? > > Giles > > > > -- > > Grant A. Kirkwood - grant(at)tnarg.org > > Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED > > > > >
RE: AOL mail netblocks
On Tue, 2 Jul 2002, Daniska Tomas wrote: > what the second line is for? > > if i block all first then why care about rest (which equals to none in such case) :) Obviously, I hope, the business realities of playing the spam game dictate that I can only control the spam, not stop it. I was hoping someone was going to say that "AOL already does this themselves". In the 'old' days, there was a list of what to allow under .ipt.aol.com. It's pretty easy for them to do it, and I'm guessing that they do actually filter this outbound, or their managed modem providers may, I'm just looking for a confirmation. -M
RE: AOL mail netblocks
what the second line is for? if i block all first then why care about rest (which equals to none in such case) :) -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first. > -Original Message- > From: Martin Hannigan [mailto:[EMAIL PROTECTED]] > Sent: 2. júla 2002 14:40 > To: [EMAIL PROTECTED] > Subject: AOL mail netblocks > > > > > Folks, is there still only a certain block of allowed addresses > that send mail from AOL i.e. block smtp from any any and then allow > 1.2.3.0/24 etc? > > Thanks, > > -M > > > > Regards, > > -- > Martin Hannigan [EMAIL PROTECTED] > Boston, MAhttp://www.fugawi.net > >
AOL mail netblocks
Folks, is there still only a certain block of allowed addresses that send mail from AOL i.e. block smtp from any any and then allow 1.2.3.0/24 etc? Thanks, -M Regards, -- Martin Hannigan [EMAIL PROTECTED] Boston, MA http://www.fugawi.net
RE: Sprint peering policy
On Tue, 2002-07-02 at 02:00, Grant A. Kirkwood wrote: > > At 09:54 PM 7/1/2002 -0400, Phil Rosenthal wrote: > > >My math shows ~500bps per US citizen: > >Assuming 150,000,000,000 bits and 280,000,000 citizens. > > This also assumes US citizens don't sleep. and that non-US citizens never send traffic through the US or send traffic to/from servers in the US. Given that traffic from Europe to Asia almost always goes via the US, and given that it isn't unheard of for traffic between major European ASs to go via the US (e.g. 702 and 9057 right now) then the former assumption is clearly untrue. I think the fact that I'm sending this invalidates the second one? Giles > -- > Grant A. Kirkwood - grant(at)tnarg.org > Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED > > -- = Giles HeronPrincipal Network ArchitectPacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" =
