Re: attacking DDOS using BGP communities?
On (2002-10-18 00:15 -0400), John Fraizer wrote: 2) 'TTL' community. -just think about the amount of route-maps : Whoa. Decrementing a single community integer value while leaving others unchanged would seem to be a bit tricky. This would require much more work on the part of others than the first suggestion and I think it would attract far fewer participants for that matter. Actually would it matter if it wouldn't be additive change? Since it would be diagnostic/special case. But of course it would be trivial for the vendors to add support for changing the communities this way, if this could be performed as a additive change you could offer your customers automaticly partial visiblity under DOS attack until it's resolved rather than 0 visibility. Not to mention how much it would ease pinpointing faulty/aggressive parties thus in long run it could have very positive effect for things like proper anti-spoofing configurations. -- ++ytti
Re: attacking DDOS using BGP communities?
On (2002-10-18 04:13 -0400), John Fraizer wrote: You receive a prefix with the communities :1 :2 :3 and TTL-COMM:2. You need to decrement the TTL-COMM value while leaving the other 3 communities unchanged. Yes this would need change in IOS/JunOS but it wouldn't actually be hard to code this feature. But I still think it would be beneficial if green elves would configure it as non-additive change to all routers globally. Yes, you couldn't use it as offering partial visibility since it would most propably break few things here and there but it would increase your possibility in finding out which AS# is/are originating the attack. I'm just waiting for the green elves. But in the mean time, would anyone configure decrement of TTL-COMM if JunOS and IOS would magically start to support such feature in hopes of reaching some time large enough cover to actually do anything good. Unless *ALL* vendors change their code to compare AS-PATH length for prefixes against the TTL-COMM value, decrementing the value as the route is passed from peer to peer is the only way to make this work that I can think of. Doing that without nixing the other communities that may need to be passed as well becomes a serious challenge. Yes, it's quite optimistic and naive to think such concensus could be achieved when much more modest changes which would require global co-operation never happen. Heck, the route-map to do this without regard for other communities would still be pretty hairy. Am I missing something here? No, thanks for the comments. -- ++ytti
www.lucent.com
Hello, does someone know what happened to http://www.lucent.com ? Yesterday everything was fine, but now it seams like they are wiped out of the internet. No DNS resolution (unknown host ?!). Daniel
Re: www.lucent.com
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 Hello Daniel, Friday, October 18, 2002, 5:56:27 AM, you wrote: DMK does someone know what happened to http://www.lucent.com ? DMK Yesterday everything was fine, but now it seams like they DMK are wiped out of the internet. No DNS resolution (unknown host ?!). Works fine for me from Qwest's backbone. And it appears to have a proper DNS entry: datacenterwire.com /home/allan#dig www.lucent.com ;; ANSWER SECTION: www.lucent.com. 3H IN CNAME ap-www.lucent.com. ap-www.lucent.com. 0S IN A 192.11.229.2 ;; AUTHORITY SECTION: ap-www.lucent.com. 3H IN NSapserver1.lucent.com. ap-www.lucent.com. 3H IN NSapserver2.lucent.com. allan - -- Allan Liska [EMAIL PROTECTED] http://www.allan.org -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPa/dFSkg6TAvIBeFAQGGrQP+NSKR9paoX4X1A/ba6nXlxT3dlAGcOjAg ixOssvTyRkZj0uRzo6t4gsTx48bcj6qv3FfrgiaBaeh3KvW5qUl4RjhCSbdG+/DF to7qaJFM6j1H2qVxItIURHyRfSCshxoOBekVGkMPaFOF05PgkRYhMCFb8lgIvewZ D4romdikT0I= =BGxr -END PGP SIGNATURE-
The Cidr Report
This report has been generated at Fri Oct 18 21:45:11 2002 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
11-10-02114611 82522
12-10-02114687 82431
13-10-02114551 82294
14-10-02114344 82657
15-10-02114786 82675
16-10-02114805 82681
17-10-02114726 82664
18-10-02114704 82837
Possible Bogus Routes
192.0.0.0/24 AS3215 AS3215 France Telecom Transpac
AS Summary
13878 Number of ASes in routing system
5410 Number of ASes announcing only one prefix
1759 Largest number of prefixes announced by an AS
AS701 : ALTERNET-AS UUNET Technologies, Inc.
73212160 Largest address span announced by an AS (/32s)
AS568 : SUMNET-AS DISO-UNRRA
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 18Oct02 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 115049828493220028.0% All ASes
AS7132 591 68 52388.5% SBIS-AS Southwestern Bell
Internet Services
AS3908 1059 554 50547.7% SUPERNETASBLK SuperNet, Inc.
AS701 1759 1284 47527.0% ALTERNET-AS UUNET
Technologies, Inc.
AS7843 756 324 43257.1% ADELPHIA-AS Adelphia Corp.
AS7018 1352 996 35626.3% ATT-INTERNET4 ATT WorldNet
Services
AS4323 518 181 33765.1% TW-COMM Time Warner
Communications, Inc.
AS1221 1201 878 32326.9% ASN-TELSTRA Telstra Pty Ltd
AS18566 3134 30998.7% COVAD Covad Communications
AS852737 458 27937.9% ASN852 Telus Advanced
Communications
AS6347 346 77 26977.7% DIAMOND SAVVIS Communications
Corporation
AS4355 385 128 25766.8% ERMS-EARTHLNK EARTHLINK, INC
AS7046 578 342 23640.8% UUNET-CUSTOMER UUNET
Technologies, Inc.
AS209569 337 23240.8% ASN-QWEST Qwest
AS1239 879 661 21824.8% SPRINTLINK Sprint
AS1 651 434 21733.3% GNTY-1 Genuity
AS705443 226 21749.0% ASN-ALTERNET UUNET
Technologies, Inc.
AS4814 229 15 21493.4% CHINANET-BEIJING-AP China
Telecom (Group)
AS4151 292 88 20469.9% USDA-1 USDA
AS22927 215 20 19590.7% AR-TEAR2-LACNIC TELEFONICA DE
ARGENTINA
AS6595 249 56 19377.5% DODDSEUR DoD Education
Activity Network Assistance
Center
AS17676 224 34 19084.8% GIGAINFRA APNIC ASN block
AS4134 297 113 18462.0% ERX-CHINALINK Data
Communications Bureau
AS17557 301 121 18059.8% PKTELECOM-AS-AP APNIC ASN
block
AS6140 256 77 17969.9% IMPSAT-USA ImpSat USA, Inc.
AS2048 262 88 17466.4% LANET-1 State of Louisiana
AS6197 395 226 16942.8% BATI-ATL BellSouth Network
Solutions, Inc
AS690517 350 16732.3% MERIT-AS-27 Merit Network Inc.
AS6198 395 229 16642.0% BATI-MIA BellSouth Network
Solutions, Inc
AS1791 185 21 16488.6% SPRINTLINK3 Sprint Government
Systems Division
AS2548 426 266 16037.6% ICIX-MD-AS Business Internet,
Inc.
Total 16380 8656 772447.2% Top 30 total
Please see http://www.cidr-report.org for the full report
Copies of this report are mailed to:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
RE: www.lucent.com
Yes, they are back. Strange, even through looking glasses all over the world they were not reachable for at least an hour ?! D. On Fri, 18 Oct 2002, Gibson, Mark wrote: i can see them -Original Message- From: Daniel Marquez-Klaka [mailto:dmk;marquez.de] Sent: 18 October 2002 10:56 To: [EMAIL PROTECTED] Subject: www.lucent.com Hello, does someone know what happened to http://www.lucent.com ? Yesterday everything was fine, but now it seams like they are wiped out of the internet. No DNS resolution (unknown host ?!). Daniel -- This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited. If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents. Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated.
RE: attacking DDOS using BGP communities?
701 has a blackhole community, 701:, basically it sets the next-hop to something blackholed on their edge so the DOS attack gets dropped as soon as it hits them. I have made use of this to kill at least one DDOS event. A global blackhole community may be difficult to achieve, but getting the majority of large providers to implement one is a good start. -Original Message- From: Saku Ytti [mailto:saku+nanog;ytti.fi] Sent: Thursday, October 17, 2002 5:23 PM To: [EMAIL PROTECTED] Subject: attacking DDOS using BGP communities? How feasible would these ideas be? 1) Signaling unwanted traffic. You would set community which would just inform that you are receiving unwanted traffic. This way responsible AS# with statistical netflow could easily automaticly search for these networks and report to NOC if both there is increased traffic to them and community is on. -would it be affective at all? Could your netflow parser use it easily? +wouldn't need big changes 2) 'TTL' community. You would have ~10 communities representing how many AS hops until route should not be advertised anymore. If you would experience DOS you'd start from TTL 1 and increase until DOS flow starts again, with any luck you would end up having very limited amount of AS# to communicate with in hopes of fixing their anti-spoofing filters and to catch malicious party. -just think about the amount of route-maps : -you would need to flap the network possible 10 times == damped +some idea who to contact w/o co-operation of NOCs (can be hard) +wins you time, often DOS is over before you've reached 3rd AS number to ask where the traffic is originating. 3) 'null route' community. This would only be useful if it would mean that you are also accepting more spesific annoucement, preferally even /32. Most people are propably crying about the idea already, but if you plan it wisely with prefix-limit setting it might not be suicide. Just remember that all downstream prefix-limit+your prefices must be smaller than what your upstream has set for prefix-limit, if this is not done then your downstreams can effectively trigger your upstream prefix-limit killing your connectivity. How AS handles the 'null route' community could vary, others set next-hop to null0 other might set it to analyzer tool. Just that it shouldn't reach the other end anymore. -the obvious: explosion of global bgp routing table (no, not nececcarily) +effective, you'd instantly free your link from any DOS traffic to given destination. -- ++ytti
RE: attacking DDOS using BGP communities?
Interesting -- I was actually having a conversation about this very same thing with a friend of mine a few days ago. The problem we had, was that he had next-hop-self on all of his ibgp mesh routers. Does that not make it difficult to put an ip next-hop in? Also, would that ip next-hop be propagated throughout his mesh or would that same route-map have to be present on all the edge routers? The other thing we were toying with was a setting the administrative distance for said black-holed route to be less than that of his igp and having his IGP route to 127.0.0.1 or something. The whole goal was to try and kill the route as close to the source as possible so as not to have the traffic traverse the core. The question is, how to? -- AFAIK, I'm a BOFH for continually bashing you with a clue-by-four. OTOH, if you would just RTFM every once in a while, my life would suck *much* less. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-nanog;merit.edu] On Behalf Of Frank Scalzo Sent: Friday, October 18, 2002 9:52 AM To: Saku Ytti; [EMAIL PROTECTED] Subject: RE: attacking DDOS using BGP communities? 701 has a blackhole community, 701:, basically it sets the next-hop to something blackholed on their edge so the DOS attack gets dropped as soon as it hits them. I have made use of this to kill at least one DDOS event. A global blackhole community may be difficult to achieve, but getting the majority of large providers to implement one is a good start. -Original Message- From: Saku Ytti [mailto:saku+nanog;ytti.fi] Sent: Thursday, October 17, 2002 5:23 PM To: [EMAIL PROTECTED] Subject: attacking DDOS using BGP communities? How feasible would these ideas be? 1) Signaling unwanted traffic. You would set community which would just inform that you are receiving unwanted traffic. This way responsible AS# with statistical netflow could easily automaticly search for these networks and report to NOC if both there is increased traffic to them and community is on. -would it be affective at all? Could your netflow parser use it easily? +wouldn't need big changes 2) 'TTL' community. You would have ~10 communities representing how many AS hops until route should not be advertised anymore. If you would experience DOS you'd start from TTL 1 and increase until DOS flow starts again, with any luck you would end up having very limited amount of AS# to communicate with in hopes of fixing their anti-spoofing filters and to catch malicious party. -just think about the amount of route-maps : -you would need to flap the network possible 10 times == damped +some idea who to contact w/o co-operation of NOCs (can be hard) +wins you time, often DOS is over before you've reached 3rd AS number to ask where the traffic is originating. 3) 'null route' community. This would only be useful if it would mean that you are also accepting more spesific annoucement, preferally even /32. Most people are propably crying about the idea already, but if you plan it wisely with prefix-limit setting it might not be suicide. Just remember that all downstream prefix-limit+your prefices must be smaller than what your upstream has set for prefix-limit, if this is not done then your downstreams can effectively trigger your upstream prefix-limit killing your connectivity. How AS handles the 'null route' community could vary, others set next-hop to null0 other might set it to analyzer tool. Just that it shouldn't reach the other end anymore. -the obvious: explosion of global bgp routing table (no, not nececcarily) +effective, you'd instantly free your link from any DOS traffic to given destination. -- ++ytti
RE: attacking DDOS using BGP communities?
701 has a blackhole community, 701:, basically it sets the next-hop to something blackholed on their edge so the DOS attack gets dropped as soon as it hits them. I have made use of this to kill at least one DDOS event. A global blackhole community may be difficult to achieve, but getting the majority of large providers to implement one is a good start. Brilliant solution - lets stop DDOS attack on the customer by denying service to the customer is a non-distributed way. Alex
RE: attacking DDOS using BGP communities?
Interesting -- I was actually having a conversation about this very same thing with a friend of mine a few days ago. The problem we had, was that he had next-hop-self on all of his ibgp mesh routers. Does that not make it difficult to put an ip next-hop in? Also, would that ip next-hop be propagated throughout his mesh or would that same route-map have to be present on all the edge routers? The other thing we were toying with was a setting the administrative distance for said black-holed route to be less than that of his igp and having his IGP route to 127.0.0.1 or something. Again, by doing this you are denying service since you are dropping all the packets addressed to the target. Such protection mounts another DOS attack on the target, this time by preventing any packets traveling though your network from reaching the targets, as opposite to preventing DDOS from using your network. If such system is implemented, the DOS attacks will become a lot harder to trace and chase after, since the attackers will simply trigger target blackholing. Alex
RE: attacking DDOS using BGP communities?
Inline comments below... --Chris ([EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ### On Fri, 18 Oct 2002, Jason Lixfeld wrote: Interesting -- I was actually having a conversation about this very same thing with a friend of mine a few days ago. The problem we had, was that he had next-hop-self on all of his ibgp mesh routers. Does that not make it difficult to put an ip next-hop in? Also, would that ip next-hop be propagated throughout his mesh or would that same route-map have to be present on all the edge routers? Not difficult at all, I'll post out sample config bits before NANOG in Eugene :) (they are about half done... I'm just lazy) The other thing we were toying with was a setting the administrative distance for said black-holed route to be less than that of his igp and having his IGP route to 127.0.0.1 or something. Yikes... Just go with the simple solution :) Blackhole routes work just fine in bgp, sample blackhole route server configs exist at: http://www.secsup.org/Tracking/ for both Juniper and Cisco... and someone was going to forward me Foundry configs at one point too :) The whole goal was to try and kill the route as close to the source as possible so as not to have the traffic traverse the core. The question is, how to? Once you look beyond your ASN it gets very difficult to determine where the traffic is originating, unless the next ASN is terminal... Anyway, I'll get some configs at: http://www.secsup.org/CustomerBlackHole/ In the coming days. -- AFAIK, I'm a BOFH for continually bashing you with a clue-by-four. OTOH, if you would just RTFM every once in a while, my life would suck *much* less. -Original Message- From: [EMAIL PROTECTED] [mailto:owner-nanog;merit.edu] On Behalf Of Frank Scalzo Sent: Friday, October 18, 2002 9:52 AM To: Saku Ytti; [EMAIL PROTECTED] Subject: RE: attacking DDOS using BGP communities? 701 has a blackhole community, 701:, basically it sets the next-hop to something blackholed on their edge so the DOS attack gets dropped as soon as it hits them. I have made use of this to kill at least one DDOS event. A global blackhole community may be difficult to achieve, but getting the majority of large providers to implement one is a good start. -Original Message- From: Saku Ytti [mailto:saku+nanog;ytti.fi] Sent: Thursday, October 17, 2002 5:23 PM To: [EMAIL PROTECTED] Subject: attacking DDOS using BGP communities? How feasible would these ideas be? 1) Signaling unwanted traffic. You would set community which would just inform that you are receiving unwanted traffic. This way responsible AS# with statistical netflow could easily automaticly search for these networks and report to NOC if both there is increased traffic to them and community is on. -would it be affective at all? Could your netflow parser use it easily? +wouldn't need big changes 2) 'TTL' community. You would have ~10 communities representing how many AS hops until route should not be advertised anymore. If you would experience DOS you'd start from TTL 1 and increase until DOS flow starts again, with any luck you would end up having very limited amount of AS# to communicate with in hopes of fixing their anti-spoofing filters and to catch malicious party. -just think about the amount of route-maps : -you would need to flap the network possible 10 times == damped +some idea who to contact w/o co-operation of NOCs (can be hard) +wins you time, often DOS is over before you've reached 3rd AS number to ask where the traffic is originating. 3) 'null route' community. This would only be useful if it would mean that you are also accepting more spesific annoucement, preferally even /32. Most people are propably crying about the idea already, but if you plan it wisely with prefix-limit setting it might not be suicide. Just remember that all downstream prefix-limit+your prefices must be smaller than what your upstream has set for prefix-limit, if this is not done then your downstreams can effectively trigger your upstream prefix-limit killing your connectivity. How AS handles the 'null route' community could vary, others set next-hop to null0 other might set it to analyzer tool. Just that it shouldn't reach the other end anymore. -the obvious: explosion of global bgp routing table (no, not nececcarily) +effective, you'd instantly free your link from any DOS traffic to given destination. -- ++ytti
RE: www.lucent.com
DM Date: Fri, 18 Oct 2002 14:23:09 +0200 (CEST) DM From: Daniel Marquez-Klaka DM Strange, even through looking glasses all over the world DM they were not reachable for at least an hour ?! If the routes are announced correctly and there are no routing disasters, then it's probably inappropriate for NANOG-L. (Think long spam threads.) http://www.nanog.org/faq Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
Re: sprint passes uu?
i wrote: transit prices have been in free fall, and worldcom has not been following them downward. however, after the cleansing ritual of chapter 11, i think they will be in a fine position to reset their per-megabit charges in ways that make them a compelling transit provider. their network's been great. several people answered me, privately. i'm going to respond publically but preserve anonymity: But WorldCon billing is a nightmare. We'd really like to stay connected to UUNet, but WorldCon's inability to bill us in accordance with our contract and insistance that we pay bills they know are complete works of fiction make it really difficult. there is a curious mixture of fact and fiction in the general response to a uunet bill. in their version of banded rates, you don't know what rate you will owe until the end of the month, but you pay your commit at the start of the month (or at least that's what MIBH was doing, since the overall costs were lower in that case). i usually found that if i read my uunet bill by candlelight during a new moon, i was able to figure out what it all meant and tie it all back to some kind of reality. i know that there are also just plain errors in some of the bills i've been a third party to. however, these errors are no wierder than the ones on my SBC/PacBell frame relay bills. remember as you read these things that IP providers are resisting commodotization, and that means they have to give out quotes, contracts, and invoices that do not map apples to apples against a competitor's quotes, contracts, or invoices. this is creativity for the sake of creativity, and i'd like to see it end, but i don't know how or when that can happen. the real debate is about actual measured cost per bit or per bit-kilometer, and to that end, this next anonymized reply attempts to go there: I got Worldcom to quote me $170/meg for a 100Mb commitment about a month ago. If that's not freefall, I don't know what is. that's not freefall. get yourself a quote from cogent or level(3), for examples. at $170/Mbit for 100Mbit/sec commit you are either paying for name brand or you're paying for quality of on-net service to their other customers or you're just plain getting brutalized. note that $170/Mbit is actually below cost for any network smaller than sprint's or uunet's, once you figure in the people, the routes, the rent, and the depreciation, and then fuzz it based on economies of scale. however, the market hasn't bottomed yet, and most people still don't know what their costs are. once we bottom out and start regenerating, $200/Mbit to $300/Mbit for wholesale high-commit transit is going to be just about right, given the single-digit NPM that you get from high capital long term commodity plays. let's talk about network quality, though: their network's been great. modulo a couple of recent multi-hour meltdowns (one nationwide one regional), yes. i can remember similar meltdowns in sprint, teleglobe, abovenet, mci, cw, psi, qwest, and att (both voice and data for att). most of these networks were grown immaturely, without offline simulation of either current or proposed changed topologies. indeed, most of them are too large to simulate offline, so the only system level testing they get is the live kind. equipment vendors and routing protocols have been in continuous flux. periodic meltdowns do not indicate either incompetence or lack of investment, merely that there's been more growth than was sane. (in other words, the dotcom overshoot in networking was technical, not just fiscal.) uunet's network is still as good as they come, and the people who keep it running are still near the top of the field. (though i understand there's been some personnel runoff during the chapter 11.)
Re: sprint passes uu?
note that $170/Mbit is actually below cost for any network smaller than sprint's or uunet's, once you figure in the people, the routes, the rent, and the depreciation, and then fuzz it based on economies of scale. however, the market hasn't bottomed yet, and most people still don't know what their costs are. once we bottom out and start regenerating, $200/Mbit to $300/Mbit for wholesale high-commit transit is going to be just about right, given the single-digit NPM that you get from high capital long term commodity plays. This is total and udder rubbish, the same kind that took one of the best networks out there and destroyed it. CGS has a very strict definition. CGS of a company A that gets goods from B does not care about B having negative margins. There is a number of good providers that provide very limited service at a rate of under $100 Mbit/sec. An Enterprising Co takes transit from two of those companies paying $100 Mbit/sec to each. Adding a few services, one of which is called inhouse customer service that does not rely on former security guards paid $5.25 per hour and happily resell it at $300 per Mbit/sec. Factoring real salary costs, real equipment costs and real depreciation schedules, the Enterprising Co manages to make money hands over fist because it does not spend $80MM USD to built 15,000 sq. feet of space. Alex
Cisco Catalyst DOS Risk
http://www.theregister.co.uk/content/55/27690.html
Re: Sprint VS. Qwest
What possible reason would the average small transit buyer have for knowing the details of a carrier's peering arrangements - especially carriers like Sprint and Qwest? Both Sprint and Qwest are, most would agree, transit-free, tier 1 networks. They interconnect with all other similarly large networks. How much more do you want? The size of their interconnections to 701? I'm not sure how that is useful. The only really useful information about peering from carriers of this size might be packet loss statistics across private peering connections. That is an actual performance metric, and could tend to seperate some providers from others, and reward those who keep their peering connections properly sized. Perhaps this is what you mean by better peering? Locations and sizes won't help you at all, if this is what you are looking for. I suppose the question is, what is your goal? If you are looking for transit, there are numerous criteria - - price - customer service - clueful engineer accessability - network stability - network reach - i.e. do they have a POP where you want to interconnect? - Packetloss and latency metrics - Special features - rich community set, multicast, etc - Dan On Thu, 17 Oct 2002, Stephen J. Wilcox wrote: Well Sprints non-peering policy is second to none if that helps with CW a close second. :) Steve On Wed, 16 Oct 2002, Christopher K. Neitzert wrote: List, Neither Sprint nor Qwest are serious about earning my business and are not providing me with their network peering details. I was hoping that the list might have the collective resources to help me determine who has better peering. thanks chirstopher
Re: future transit prices
someone wrote, in response to my piece this morning... Can you explain more about why you think transit prices will return to the $200-$300/mbps. I've been quoted $40/mbps on a 50mbps commit (95th%) ... which I think is pretty much as low as it's going to get. I can understand prices going back up near $100/mbps over time, but $200 is much more than I'm expecting. the way i think about this is that somebody has to carry the traffic to wherever it's got to go. with a top tier of huge networks, the pricing model gets smoother in two ways: (1) the distance insensitivity in sales has a larger set of costs to average against; and (2) cost per bit-kilom goes down as pipe size goes up. however, the cost per bit per second of switching these is relatively constant over time (people, rent, depreciation or lease of equipment). a non-top tier provider who wants to get into the game will not be able to make money at market prices until they fill their network to a certain crossover point. (and if you buy your pipes too small you can't get there at all, and if you buy them too large then you can never fill the whole thing.) a lot of networks, both top-tier and non-top-tier, have been selling transit without being able to determine their costs other than at a very gross level. the thought seems to have been, we have to charge what the market will bear, and hope we're the last ones standing. but i think we, as an industry, have pretty much burned all the cash we'll be able to burn in that way. when i look at the ingredients: worldwide presence (peering points, pops, whatever) worldwide L1/L2 costs between pops staff (engineering, operations, management, sales, marketing, etc) capital (for all those pops) rent (of things that aren't pops, like HQ offices) marketing, legal, travel, other goo and so on it looks to me like you could run an OC48 backbone at 60% capacity and make a sustained single digit NPM selling at $250/Mbit average, or you could do an OC192 backbone at 60% capacity and single digit margins at maybe $175/Mbit. perhaps an OC768 backbone running at 60% will be able to make single digit NPM at $100/Mbit, but i'm really reaching on that one. doing it for less involves either (a) not knowing your costs yet, or (b) buying market share, or (c) cost containment strategies like using assets that have been recently through the cleansing ritual of bankruptcy, or (d) selling ahead of usage like getting 100Mbit/sec commits from a lot of 20Mbit/sec customers. none of those things lasts forever. Regardless of which of us is right, I guess I'm still pretty safe if I lock in todays rates for multiple years. oh yeah, oh yeah, oh yeah.
Re: future transit prices
How do you compute CGS on a network that is 25% utilized? Is it expenses/current utilization or expenses/maximum capacity? I think a lot of the low-ball pricing that is in the market is the result of networks selling off underutilized capacity at discounted pricing just to get some additional cash flow. This pricing probably doesn't take into account the necessary capex that will be required to upgrade the network when it approaches saturation. On 10/18/02 10:46 AM, Paul Vixie [EMAIL PROTECTED] wrote: someone wrote, in response to my piece this morning... Can you explain more about why you think transit prices will return to the $200-$300/mbps. I've been quoted $40/mbps on a 50mbps commit (95th%) ... which I think is pretty much as low as it's going to get. I can understand prices going back up near $100/mbps over time, but $200 is much more than I'm expecting. the way i think about this is that somebody has to carry the traffic to wherever it's got to go. with a top tier of huge networks, the pricing model gets smoother in two ways: (1) the distance insensitivity in sales has a larger set of costs to average against; and (2) cost per bit-kilom goes down as pipe size goes up. however, the cost per bit per second of switching these is relatively constant over time (people, rent, depreciation or lease of equipment). a non-top tier provider who wants to get into the game will not be able to make money at market prices until they fill their network to a certain crossover point. (and if you buy your pipes too small you can't get there at all, and if you buy them too large then you can never fill the whole thing.) a lot of networks, both top-tier and non-top-tier, have been selling transit without being able to determine their costs other than at a very gross level. the thought seems to have been, we have to charge what the market will bear, and hope we're the last ones standing. but i think we, as an industry, have pretty much burned all the cash we'll be able to burn in that way. when i look at the ingredients: worldwide presence (peering points, pops, whatever) worldwide L1/L2 costs between pops staff (engineering, operations, management, sales, marketing, etc) capital (for all those pops) rent (of things that aren't pops, like HQ offices) marketing, legal, travel, other goo and so on it looks to me like you could run an OC48 backbone at 60% capacity and make a sustained single digit NPM selling at $250/Mbit average, or you could do an OC192 backbone at 60% capacity and single digit margins at maybe $175/Mbit. perhaps an OC768 backbone running at 60% will be able to make single digit NPM at $100/Mbit, but i'm really reaching on that one. doing it for less involves either (a) not knowing your costs yet, or (b) buying market share, or (c) cost containment strategies like using assets that have been recently through the cleansing ritual of bankruptcy, or (d) selling ahead of usage like getting 100Mbit/sec commits from a lot of 20Mbit/sec customers. none of those things lasts forever. Regardless of which of us is right, I guess I'm still pretty safe if I lock in todays rates for multiple years. oh yeah, oh yeah, oh yeah.
Re: future transit prices
How do you compute CGS on a network that is 25% utilized? bad Is it expenses/current utilization or expenses/maximum capacity? i want to be in a situation where i owe income taxes. so it's all about costs vs. sales. I think a lot of the low-ball pricing that is in the market is the result of networks selling off underutilized capacity at discounted pricing just to get some additional cash flow. in other words, people don't know what their costs are, so any sales are good. this is one of the situations that can't last. This pricing probably doesn't take into account the necessary capex that will be required to upgrade the network when it approaches saturation. actually it assumes that equity funding will be available for step functions in capacity as long as the underlying business is returning high single digit NPM. (that's how large-capex commodity plays work, since share price will be a function of P:E.)
Re: Sprint VS. Qwest
In a message written on Fri, Oct 18, 2002 at 04:56:13PM -0500, Mark Borchers wrote: OK, given the choice between tier 1 A and tier 1 B, suppose you can show that interconnect bandwidth between the two is underprovisioned. Armed with that knowledge, which of the two do you choose as your transit provider? Much of nanog suggests you should always have two providers. If indeed A and B were congested to each other, and everything else was equal, then those two providers would be your best choice. In reality it's never that simple. Two providers may have the same number of peers and total bandwidth, however one may have all of them in your city, and another may have none in your city. It could be argued that you will get better performance from the one who has them in your city. At the end of the day, no provider is even 50% of the internet (my assertion), which means more of your bits will leave your providers network then will stay on it. If the majority of your bits are crossing interconnects to other providers, and they won't tell you anything about those interconnects, shouldn't that raise a red flag? Disclosure is a complicated problem. Peering contracts can prohibit it. Everyone wants to hide their own skeletons. Information is often distorted on the way from engineering to sales. That's no reason to take trust us, we do a good job as an answer. Having the information to make your own decision is important. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
Juniper and Foundry l2/l3 core plus mpls
Greetings Nanog, My company is currently evaluating both Foundry (netiron line) and Juniper (m160 and t320) devices to use in a high speed l2/l3 core with l2 mpls. Core speeds will start at oc48 (ospf and fully meshed ibgp core, full internet routes, peering, customer routes, etc) but needs to scale to oc192. Dense Gige is also a requirement. I of course have both companies data and testimonials but thought I would go to some actual network operators to get opinions on one or the other as a preference. I have heard some negative things about one of the above vendors ability to handle a lot of routes in less than stable conditions, bad optics, mpls was also brought into question as an issue. Much appreciated.Do you Yahoo!? Faith Hill - Exclusive Performances, Videos, & more faith.yahoo.com
Re: Juniper and Foundry l2/l3 core plus mpls
On Fri, Oct 18, 2002 at 04:17:46PM -0700, jack ardent wrote: My company is currently evaluating both Foundry (netiron line) and Juniper (m160 and t320) devices to use in a high speed l2/l3 core with l2 mpls. o/~ One of these things is not like the others, One of these things just doesn't belong. o/~ -- 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)
Re: Sprint VS. Qwest
On Fri, Oct 18, 2002 at 12:18:47PM -0500, dgold wrote: Both Sprint and Qwest are, most would agree, transit-free, tier 1 networks. They interconnect with all other similarly large networks. How much more do you want? The size of their interconnections to 701? I'm not sure how that is useful. http://west-boot.mfnx.net/traffic/sjc/sjc-sprint-oc3.html http://west-boot.mfnx.net/traffic/iad/iad-sprint-oc3.html http://west-boot.mfnx.net/traffic/chi/chi-sprint.html http://west-boot.mfnx.net/traffic/nyc/nyc-sprint.html http://west-boot.mfnx.net/traffic/lax/lax-sprint.html 'cause yeah, no tier 1 has ever run congested to another, right? -- 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)
