Re: Comment spammers chewing blogger bandwidth like crazy
Thomas, Can you please send logs of what you have from 195.225.177.46 to [EMAIL PROTECTED] Thanks, --Phil On Jan 13, 2007, at 12:04 PM, Thomas Leavitt wrote: A friend of mine operates a blog at seeingtheforest.com, and he pays for traffic over a (fairly minimal) cap. He posted this comment recently: http://www.seeingtheforest.com/archives/2007/01/eating_bandwidt.htm Eating Bandwidth Last month something ate up a tremendous amount of bandwidth at Seeing the Forest, costing me a lot of money. So now I regularly check bandwidth use. Why has 209.160.72.10, HopOne in DC, been eating a HUGE amount of bandwidth? Gigabytes! What are they doing? (I banned them.) Why has 220.226.63.254, an IP in India, been eating a tremendous amount of bandwidth? What are they doing? Why has 195.225.177.46, an IP in Ukraine, been eating a tremendous amount of bandwidth? What are they doing? Why has 62.194.1.235 AND 83.170.82.35 AND 89.136.115.220 AND 62.163.39.183 AND 212.241.204.145, all from the /same company/ in Amsterdam, been eating a TREMENDOUS amount of bandwidth? What are they doing? Why is 206.225.90.30 and 69.64.74.56 and Abacus America Inc.eating a TREMENDOUS amount of my bandwidth, *** One of the comments said: Yeah, I've seen a huge bump in my blog's traffic, I haven't figured out what they're doing, but it ate like 4Gb of bandwidth last month. Now that you mention it, I checked last month's stats and yep, there's 209.160.72.10 producing 62% of my blog traffic. I did a little checking around the web and they're an obvious spam host. Banned. *** They also chew up a lot of CPU (comment filter code). At few times, myself, I've had to simply take code offline that was getting hit too heavily... seems like the IPs (and their ilk) listed above are good prospects for a "bad behavior" blacklist, at a level below that of "collaborative spam filter" (which doesn't prevent traffic or CPU cycles from being consumed). Given the volume of traffic mentioned, this must be a real problem for some hosts and networks... although, on the other hand, if their marginal use rates are high enough, they might actually be making money off this. Regards, Thomas Leavitt -- Thomas Leavitt - [EMAIL PROTECTED] - 831-295-3917 (cell) *** Independent Systems and Network Consultant, Santa Cruz, CA ***
Re: IP Delegations for Forum Spammers and Invalid Whois info
Hello, On Jul 3, 2006, at 3:53 AM, Simon Waters wrote: On Monday 03 Jul 2006 06:16, you wrote: Forgive the relative noobishness of the question, but I've not had to deal with this sort of situation before. Should I be forwarding to RIPE? I don't think RIPE will be that interested. The address range gets connectivity from someone. I suggest reporting upstream. Oh dear upstream is ISPrime -- anyone here think they are anything but a spam house? Is not then why are they still in NY? We are very much anti-spam and I will look into Mark's issue - I'm looking through the tickets for abuse@ and there is no email sent in from [EMAIL PROTECTED] ... Mark - Please email me off list with whatever issue you're having and I'll have it dealt with, please cc: [EMAIL PROTECTED] Thanks, --Phil
Re: Dep(3)(3)ring
For what it's worth, I'm seeing the following: >show ip bgp 65.106.2.1 BGP routing table entry for 65.104.0.0/14, version 91507552 Paths: (6 available, best #2, table Default-IP-Routing-Table) Advertised to update-groups: 1 2 3356 2828 4.78.164.109 from 4.78.164.109 (4.68.1.253) Origin IGP, metric 100, localpref 90, valid, external Community: 3356:3 3356:86 3356:575 3356:666 3356:2010 Community Definitions: 3356:666 - Peer route 3356:3- North America 3356:575 - USA 3356:2010 - NYC - New York City Perhaps this is back up as a paid peer? Perhaps they kissed and made up? Perhaps XO asked to turn it back up for a short while they set up transit? Who knows... Also, doesn't 2828 have transit from 1239? --Phil On Sep 28, 2005, at 1:24 AM, Alex Rubenstein wrote: Appears to be. XO's looking glass for BGP looking is broken (did it break today?), however, traceroute shows: 1 ge5-3-0d4.RAR2.NYC-NY.us.xo.net (65.106.2.1) 0 msec 4 msec 4 msec 2 * * * L3's looking glass: Show Level 3 (San Jose, CA) BGP routes for 207.155.252.78 No matching routes found for 207.155.252.78. Fun. On Wed, 28 Sep 2005, Richard A Steenbergen wrote: Since it hasn't hit nanog yet, I guess I'll go ahead and go ahead and be the first to point it out. It seems that Level 3 (3356) and XO (2828) are no longer carrying each other's routes. :) And just when I was about to release http://www.e-gerbil.net/ras/ failure.jpg :) -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net
Re: Outbound Route Optimization
On Jan 21, 2004, at 3:27 PM, Jim Devane wrote: Hello, I am trying to determine for myself the relevance of Intelligent Routing Devices like Sockeye, Route Science etc. I am not trying to determine who does it better, but rather if the concept of optimizing routes is addressing a significant problem in terms of improved traffic performance ( not in cost savings of disparate transit pipes ) I am interested in hearing other views ( both for and against ) these devices in the context of optimizing latency for a small multi-homed ISP. I want to make sure I understand their context correctly and have not missed any important points of view. My questions are these: “Is sub-optimal routing caused by BGP so pervasive it needs to be addressed?” “Are these devices able to effectively address the need?” BGP makes no decisions based on "quality" of a route. If you are using anything that's dependent on low latency/packet loss/jitter (eg, VoIP, games, ssh for someone who gets annoyed by >20ms of latency, etc), there's lots of room for improvement, especially when you are buying from "bargain" transit's. Everyone I know who's used a device like Sockeye, Route Science, etc, falls into one of two categories. 1) For reasons unrelated to them owning said device, I consider them to be generally lacking clue. 2) They hated it. I've never used one myself, but based on testimonials like that, I'd tend to say that they generally don't work too well. If you hire a consultant who knows what they're doing, it should be pretty simple to set up a meaningful routing policy which does this for you. Just my $0.02 --Phil Rosenthal ISPrime, Inc.
Re: Uunet/MCI communities
On Jan 15, 2004, at 6:54 PM, Wayne E. Bouchard wrote: Trolling through some of my saved messages shows that this information may be found at: whois [EMAIL PROTECTED] http://infopage.cary.cw.net/Routing_Registry/communities.htm On Thu, Jan 15, 2004 at 05:45:34PM -0600, Ejay Hire wrote: Can A Uunet/Mci person please unicast me a copy of the UUnet != CW --Phil Rosenthal ISPrime, Inc.
Re: Stopping ip range scans
Out of curiosity. How many of your scans come from hijacked IP space? On Dec 29, 2003, at 6:47 AM, [EMAIL PROTECTED] wrote: Recently (this year...) I've noticed increasing number of ip range scans of various types that envolve one or more ports being probed for our entire ip blocks sequentially. At first I attributed all this to various windows viruses, but I did some logging with callbacks soon after to origin machine on ports 22 and 25) and substantial number of these scans are coming from unix boxes. I'm willing to tolerate some random traffic like dns (although why would anybody send dns requests to ips that never ever had any servers on them?), but scans on random port of all my ips - that I consider to be a serious security issue and I'm getting tired of it to say the least (not to mention that its drain on resources as for example routers have to answer and try to route all the requests or answer back that they could not). So I'm wondering what are others doing on this regard? Is there any router configuration or possibly intrusion detection software for linux based firewall that can be used to notice as soon as this random scan starts and block the ip on temporary basis? Best would be some kind of way to immediatly detect the scan on the router and block it right there... Any people or networks tracking this down to perhaps alert each other? -- William Leibzon Elan Networks [EMAIL PROTECTED] --Phil Rosenthal ISPrime, Inc.
Re: Portable Cooling
On Nov 12, 2003, at 10:43 AM, Fisher, Shawn wrote: I searched the archives and couldn't find anything about a portable cooling units so am resorting to posting, sorry if its redundant. I am setting up a development lab and need additional cooling on a temporary basis. I recall a product called, "move n kool"? It looked like the robot on lost in space. They used to advertise in Boardwatch when Boardwatch was cool. (when Jack was running it) Not sure of the spelling, but wondered if anyone has had experience that or anything like it. TIA Shawn http://www.movincool.com/ --Phil Rosenthal ISPrime, Inc.
Re: Fascinating interview with Verisign CEO
On Oct 17, 2003, at 4:17 AM, Hank Nussbacher wrote: http://news.com.com/2008-7347-5092590.html -Hank This has to be the most unbelievable propaganda I have ever read. What needs to be done to take the GTLD service away from these crooks? Voting with my dollar, I'm happy to say I never have, and now, never will get a SSL cert from verisign. -P
Re: Pitfalls of annoucing /24s
On Oct 15, 2003, at 5:24 PM, H. Michael Smith, Jr. wrote: What about the /24's that many ISPs (especially tier 2-3) are assigning to multi-homed customers? What about an IX or "critical infrastructure providers" that may be issued a /24 from ARIN (Policy 2001-3)? As long as it's provider assigned, and your provider announces the supernet that the /24 is from, it will still work. If you announce PI space out of the old class A space in /24's, many networks wont be able to reach you.
Re: Pitfalls of annoucing /24s
http://info.us.bb.verio.net/routing.html#PeerFilter That's how Verio does it, and I assume, that's how most people who filter by length do it as well. --Phil On Oct 15, 2003, at 4:40 PM, John Palmer wrote: Good question. You know there are thousands of legacy /24's out there that were allocated by IANA as /24's How can you aggregate them up if all you have is the /24? To those who filter out /24's - how is this done - just by the netmask size? - Original Message - From: "Jean-Christophe Smith" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 15, 2003 15:34 Subject: Pitfalls of annoucing /24s In current practice would there be serious jeopardy of portions of the internet not being able to reach this address space due to bgp filters or other restrictions? What is the smallest acceptable block of IPs that can be announced without adverse or unpredictable results? Verio would most likely be picking up these routes from us. I don't want to cause a religious debate, but I am interested in what the industry consensus is. I'm just doing some research, any comments would be appreciated. Thanks, Jean-Christophe Smith --Phil Rosenthal ISPrime, Inc.
Re: AOL breaking dns spoof protection
dig www.aol.com. ; <<>> DiG 8.3 <<>> www.aol.com. ;; res options: init recurs defnam dnsrch ;; res_nsend to server default: Operation timed out I think that's your problem. It seems aol is not answering queries at all, when to be correct they should actually be sending back responses saying there is no record, so the client can then request an A record, and move on. --Phil On Thursday, August 7, 2003, at 1:32 PM, Booth, Michael (ENG) wrote: I can't even load www.aol.com now that we're running both IPV4 and IPV6 in the office. nslookup just times out. Does anyone else have this problem? Michael
RE: OT: 111 8th Ave. Parking
> it's been a while, but i used to park in the lot underneath the building. > > richard > -- > Richard Welty [EMAIL PROTECTED] > Averill Park Networking 518-573-7592 > Unix, Linux, IP Network Engineering, Security Be warned, there are quite a few stories with severe automotive abuse going on there. The last time I parked there, they crashed my car into a wall, and then claimed the damage was already there, took several weeks to get them to cover it... I take my chances with street parking, and would prefer to deal with parking tickets versus parking in the 111 8th garage. --Phil ISPrime
RE: Anybody doing a "Code Green" for 1434?
On this topic... I've noticed that my packet counters stopped going from >1000/sec to under 100/sec. Anyone else confirm the same? Has someone went and hacked the 5000 or so remaining infected hosts that were hackable somehow, and patched/rebooted? --Phil
Tracing where it started
Hello, It might be interesting if some people were to post when they received their first attack packet, and where it came from, if they happened to be logging. Here is the first packet we logged: Jan 25 00:29:37 EST 216.66.11.120 --Phil ISPrime
11-25-03 DDoS Juniper Filter
We have installed the following on all network ingress/egress points,
and have found it to filter the packets in question very effectively:
> show configuration firewall filter filter-012503
term deny-dos {
from {
packet-length 404;
protocol udp;
destination-port 1434;
}
then {
count codered-4;
discard;
}
}
term allow-rest {
then accept;
}
--Phil
ISPrime
Re: DOS?
On 1/25/03 2:00 AM, "Christopher J. Wolff" <[EMAIL PROTECTED]> wrote:
>
> Greetings,
>
> It looks like all hell is breaking loose on some of the nations
> backbones. http://www.internethealthreport.com
>
> The port counters on my AT&T DS3 were reading in the 250 megabit range,
> that is a DS3, mind you.
>
> Any source IP's I can add to the circular file would be appreciated.
> Any ranges I find I'll echo back to the list.
>
> Regards,
> Christopher J. Wolff, VP CIO
> Broadband Laboratories, Inc.
> http://www.bblabs.com
>
>
>
You need a filter similar to this (in junos format):
> show configuration firewall filter filter-012503
term deny-dos {
from {
packet-length 404;
protocol udp;
destination-port 1434;
}
then {
count codered-4;
discard;
}
}
term allow-rest {
then accept;
}
--Phil
ISPrime
RE:
-Original Message- From: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu] On Behalf Of Harsha Narayan Sent: Monday, November 11, 2002 9:40 PM To: [EMAIL PROTECTED] Subject: >How do ISPs manage the allocations they get from the RIRs? More specifically, > do they make the assignments from this sequentially or not? Are multihoming > assignments to customers amidst non-multihoming assignments? >I ask this because /23s and /24s seem to be scattered over a wide area > - they are not adjacent to each other. Single-homed customers migrating to multi-homed is one thing that would cause this. --Phil
RE: ISPs who de-aggregate intentionally?
AS21790 does this, and I don't know why. Plenty of /24's next to each other that could easily be /23. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeffrey Haas Sent: Tuesday, September 10, 2002 5:07 PM To: [EMAIL PROTECTED] Subject: ISPs who de-aggregate intentionally? As part of the process of making the latest BGP draft an IETF standard, the IDR working group is in the process of reviewing how the current draft reflects deployed code. As part of this effort, if anyone is aware of ISPs who intentionally de-aggregate routes and could contact me to share some of the reasoning and their methodologies behind this, I would greatly appreciate it. Please note - no names will be named, unless you want to be. A summary of the results will be posted back to this list. -- Jeff Haas NextHop Technologies
RE: Will Canada's Internet providers become spies?
Is news.com.com run by news.com ? http://news.com/2100-1023-955595.html?tag=politech == 404 --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Joe Baptista Sent: Tuesday, August 27, 2002 10:44 PM To: [EMAIL PROTECTED] Subject: Will Canada's Internet providers become spies? enjoy ... and i'm curious if there are any small or large system admins in canada here that this affects and their opinions. regards joe baptista - Original Message - From: "Declan McCullagh" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 27, 2002 6:43 PM Subject: FC: Will Canada's Internet providers become spies? http://news.com.com/2100-1023-955595.html?tag=politech Will Canada's ISPs become spies? By Declan McCullagh August 27, 2002, 12:56 PM PT WASHINGTON--The Canadian government is considering a proposal that would force Internet providers to rewire their networks for easy surveillance by police and spy agencies. A discussion draft released Sunday also contemplates creating a national database of every Canadian with an Internet account, a plan that could sharply curtail the right to be anonymous online. [...] --- From: David Akin <[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: Canada to review electronic surveillance laws Hey Declan -- May be a bit too 'Canadian' for Politech but here you are . ... David Akin CTV News The Globe and Mail Office: 416.313.2503 Mobile: 416.528.3819 > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 26, 2002 7:13 AM > Subject: Government of Canada to Review Lawful Access Laws > > > Date: 2002/08/25 > > QUEBEC, August 25, 2002 -- The Honourable Martin Cauchon, > Minister of Justice and Attorney General of Canada, the > Honourable Lawrence MacAulay, Solicitor General of Canada, > and the Honourable Allan Rock, Minister of Industry, today > announced that the Government of Canada will consult with > Canadians concerning lawful access to information and > communications. The consultation was launched by Minister > MacAulay, on behalf of his colleagues, at the annual meeting > of the Canadian Association of Chiefs of Police (CACP). > > "Lawful access legislation must protect the privacy of > Canadians and reflect their values. The Government of Canada > will be examining current laws to ensure crimes and other > threats to public safety can continue to be investigated > effectively," said Minister Cauchon. > > "Legislation governing lawful access was originally designed > for rotary telephones -- not e-mail or the Internet," said > Minister MacAulay. "Dated laws allow criminals and > terrorists to use technology to hide their illicit > activities. This initiative is about keeping our laws current > so that the police can do their job and keep Canadians safe." > > "Technology is a great enabler for Canadians, but also > presents challenges for law enforcement," said Minister Rock. > "Through this process, we are seeking ideas from law > enforcement, industry and all Canadians to find a solution > that supports public safety and privacy, and how to achieve > this without inhibiting industry's ability to innovate and compete." > > Lawful access is the lawful interception of communications, > and the search and seizure of information by law enforcement > and national security agencies. Updating lawful access > legislation is essential to a broad range of investigative > bodies, in their continued efforts to fight crimes such as > terrorism, child pornography, drug trafficking, smuggling, > Internet and telemarketing fraud, price fixing and money > laundering. Lawful access can only be exercised with a lawful > authority, and is well entrenched in laws such as the > Criminal Code, the Canadian Security Intelligence Act, the > Competition Act and other Acts of Parliament. Lawful access > legislation also recognizes the privacy rights of all people > in Canada and their rights under the Canadian Charter of > Rights and Freedoms. > > This consultation process will involve key stakeholders > including law enforcement, telecommunications companies, > civil liberties and privacy organizations. The public will > also be given the opportunity to consider lawful access > issues and options for change by obtaining a consultation > paper, which is available at > www.canada.justice.gc.ca/en/cons/la_al. Those wishing to > respond may send their submissions to [EMAIL PROTECTED] > before November 15, 2002. > > In the January 2001 Speech from the Throne, the Government of > Canada pledged to provide modern tools to safeguard Canadians > from emerging threats such as cyber-crime. The lawful access > consultation will contribute to the Government's ongoing > commitments, both nationally and internationally, to ensure a > balanced and eff
RE: redundancy [was: something about arrogance]
I have in the past single-homed to Level(3) and Verio, each in their own facility in NC. In that time, both carriers had about 1 solid hour a month of solid downtime (some months were worse, some were better). Some of the outages were on the order of 8 solid hours (verio) or 4 hours (level3). We did not run HSRP with Level3, so it may be difficult to guarantee the uptime of one gige handoff... But we ran HSRP with verio, and of all the outages (about 20 of them) -- Maybe two of them were avoided because of HSRP. Other than that, it was all downtime. At this point, I couldn't conceive single-homing to any uplink anymore. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Pedro R Marques Sent: Tuesday, July 30, 2002 6:23 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: redundancy [was: something about arrogance] Brad writes: >I'm probably demonstrating my ignorance here (and my stupidity in > stepping into a long-standing highly charged argument), but I'm > completely missing something. For reasons of redundancy & > reliability, even if you were to buy bandwidth in only one location, > wouldn't you want to buy it from at least two different providers? >If you buy bandwidth from two different providers at two > different locations, this would seem to me to be a good way to > provide backup in case on provider or one location goes > Tango-Uniform, and you could always backhaul the bandwidth for the > site/provider that is down. Several other posters have mentioned reasons why redundancy between 2 different connections to separate providers are not, in most situations, the preferable aproach but i would like to add another point/question... When considering redudancy/reliability/etc it is important to think about what kind of failures do you want to protect against vs cost of doing so. It is my impression, from reading this list and tidbits of gossip, that the most common causes of failure are: - link failure - equipment failure (routers mostly), both software and hardware - configuration errors All of those are much more frequent than the failure of an entire ISP (a transit provider). It is expected, i believe, of a competent ISP to provide redudancy both within a POP and intra-POP links/equipment and its connections to upstreams/peers. As such, probably the first level of redundancy that a origin AS (non-transit) would look at would be with the intent to protect from failures of its external connectivity link and termination equipment (routers on both ends). To do so, one can look at: - 2 external links to distinct providers - 2 external links to the same provider While i can't speak to the economics part of the equation (although i would expect it to be cheaper to buy an additional link than connect to a different provider) from a point of view of restoration, protecting a path with an alternate path from the same provider is certainly an aproach that gives you much better convengence times. This comes from the fact that in terms of network topology, the distance between 2 links to the same upstream is much shorter than 2 links to different upstreams. While, if you protect a path with an alternate path to the same ISP you can expect convergence to occur within the IGP convergence times of your provider, with 2 different providers you need global BGP convergence to occur. This gets to be longer dependent on how topologically distant your 2 upstreams are... for instance attempting to protect a path to an ISP with very wide connectivity with a protection path from one with very limited connectivity would be a particularly bad case as you would have to wait for the path announced by the larger ISP to be withdrawn n times from all its peering points and the protection path to make its way through in replacement. It is counter-intuitive to me what i perceive to be the standard practice of attempting to multi-home to 2 distinct providers by origin-only ASes... from several points of view: convergence times, load on the global routing system, complexity of management, etc, dual connectivity to different routers of the same provider (using distinct physical paths) would seem to me to make more sense. Unless the main concern is that the upstream ISP fails entirely... which given the fact that it tends to have frontpage honors on the NYTimes this days does not apear to be an all to common occurence (i mean operationally, not financially - clarification added to dispel potential humorous remarks). So, my question to the list is, why is multi-homing to 2 different providers such a desirable thing ? What is the motivation and why is it prefered over multiple connections to the same upstream ? Is the main motivation not so much reliability but having a shorter as-path to more destinations ? This would apear to me to be a clear advantage since that doesn't necessarily re
RE: routing table size
Now the question is, of that 70% figure, how much of that is aggregateable? --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Paul Schultz Sent: Monday, July 29, 2002 10:28 PM To: [EMAIL PROTECTED] Subject: Re: routing table size On Mon, 29 Jul 2002, Richard A Steenbergen wrote: > If someone has done an actual study of where these /24s (and probably > /23s > too) come from, please point it out. Until then, my money is on clueless > redist connected/statics, large cable/dsl providers who announce a /24 per > pop/city/whatever to their single transit provider, and general ignorance. To ease my own curiousity I kludged together a script to look at how much of /24 land is taken up by smalltimers announcing few prefixes, and larger networks announcing many. My last snapshot of the routing table is from the end of june, so may be (very slightly) outdated. Data from June 29, 2002 Total /24's: 61931 ASN's announcing /24's: 8645 Number of /24's announced by AS breakdown /24's ASN Count === = 1 3474 2 1662 3 740 4 533 5 377 6 236 7 203 8 164 9 113 10-14 421 15-19 184 20-29 199 30-39 101 40-49 57 50-59 41 60-69 29 70-79 21 80-89 12 90-99 11 100-149 20 150-199 17 200+29 Those "basement multihomers" announcing 1-5 /24's only account for ~20% of the total number of /24's out there. Multihomers with slightly larger basements (6-10 /24's) account for 10% of the total. That leaves the remaining 70% of /24's in the DFZ announced by people pushing out over 10 /24's from their AS. Interpret however you will (I tend to lean towards Richard's take on the situation.) - Paul
RE: Bogon list or Dshield.org type list
Title: Message I can comment on the dshield list. I have seen this before. I am checking one particular IP on my network that has a very popular freehost on it. Checking the load balancer IP (connections cannot be originated from this IP) -- it shows that there were 13 attacks initiated from the IP, and 7 targets. Whatever their algorithm is, it doesn't seem reliable enough for me to trust it if an IP that can not originate connections is listed as an attacker (albeit small on their list) --Phil -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of alsatoSent: Saturday, July 27, 2002 8:08 PMTo: [EMAIL PROTECTED]Subject: Bogon list or Dshield.org type list Im wondering how many of you use Bogon Lists and http://www.dshield.org/top10.html type lists on your routers? Im curious to know if you are an ISP with customers or backbone provider or someone else? I have a feeling not many people use these on routers? Im wondering why or why not? Ive never used them on my routers although I work for a new isp/cable provider. Im thinking it would make my users happy to use them though. alsato
RE: Any people still with old filters?
No. If they did, 80% of the internet would not be visible to them today., --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Roy Sent: Saturday, July 27, 2002 4:54 PM To: [EMAIL PROTECTED] Subject: Any people still with old filters? In a recent discussion with a company that owns a /16 and has it broken down further, the statement was made that there are ISPs that filter routes at /16 in what was traditional class B space. The example cited was Verio. Verio web pages state they don't do this any more (the filter is /21). Is there anyone that still filters routes longer than /8 and /16 in the traditional Class A and B space?
Whats wrong with Foundry Networks?
I've seen on this list, and from many other places a generic hatred for Foundry -- with comments like "It's IP stack is just plain broken". Whenever I ask people for specific examples, I get none. Now, I have seen plenty of bugs in Foundry -- but all in all, I think Foundry BigIron is the best router you can get, given the price. I am now using BigIron 8000's to do most all of what I used to have 6509's doing, and I haven't regretted the decision to switch for one second (I did use a mix of foundry and Cisco before -- and regretted the decision to include Cisco at all) Anyone care to share why they feel Foundry is inferior? --Phil
RE: verio arrogance
Say hypothetically it costs approximately $0.10 per route (in routing cpu/ram cost) per router. (average router cost $12,000 and 120,000 routes in the table). Lets also say hypothetically the average bgp speaking user has 3 bgp speaking routers. And lets say there are 25,000 AS's in use. By announcing as 4 blocks, instead of 1 aggregate, you are costing the bgp speaking community a total of $30,000. You are saving yourself money, at everyone else's expense. I know my math is not exactly correct, but it's an example to show why people get pissy about this sort of thing.. You aren't the biggest offender, but how should anyone draw an arbitrary line for "you are polluting too much" and "you are polluting, but to a reasonable extent". At this point, I have my whole network in NYC, so there isn't really any need for deaggregation. If/When my network expands to other cities, I will be planning things out to avoid deaggregating -- most likely with the deaggregate+no-export method. You could do a deaggregate+no-export method as well, even with your two different transit providers. You would just need to run ebgp-multihop to each of them from the opposite network, and announce your more-specifics there. Not a perfectly clean method, but at least it keeps your pollution local. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ralph Doncaster Sent: Friday, July 26, 2002 10:49 PM To: Stephen Griffin Cc: [EMAIL PROTECTED] Subject: Re: verio arrogance > > I'm a little disappointed you're wasting list bandwidth after this > > has been well discussed, and not a single post has offered a better > > technical alternative to de-aggregating my ARIN /20 (given my > > network topology). > > > > -Ralph > > Announce your largest aggregate, and announce more-specifics tagged > no-export to those peers who agree to accept them? Which is worse than announcing just the more specifics to 2 different transit providers in 2 different cities. > Upgrade the connectivity between your sites? Technically sound, economically stupid. You offering to pony up the $5K/mth for an OC3 so I can have a redundant link between Ottawa and Toronto? Besides the technical aspects of my network, I didn't see any proof that relaxed prefix filtering (and no I'm not saying accept /32's - the more specifics I got Verio to accept were /23's) would cause significant (i.e. >30%) routing table bloat when that was recently discussed. -Ralph
RE: debugging packet loss
--- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Lewis Isn't ping the first thing to be dropped in favor of other traffic? I remember a similar issue and Cisco saying that was the behavior. Don't quote me on that. jas --- Even if it is, that still means that other packets could be lost had those pings not been there. --Phil
RE: Security of DNSBL spam block systems
Title: Message IMHO Even the really large DNSBL's are barely used -- I think (much) less than 5% of total human mail recipients are behind a mailserver that uses one... --Phil -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Big_BandwidthSent: Tuesday, July 23, 2002 2:14 AMTo: [EMAIL PROTECTED]Subject: Security of DNSBL spam block systems What are the security implications of someone hacking a DNSBL (Real-time-spam-block-list) and changing the block list to include (deny email from) some very large portion or all IPv4 space? Given that a signifigant number of the spam blocking lists seem to operate on a shoestring budget in someone's basement, how can we be assured that they have sufficient resources to secure their systems adequatley, and monitor for intrusion 24x7? Unless I am missing something, this would seem to be a real handy and centralized method for someone to interfere substantially with the proper operation of a few thousand email servers and hold up global email traffic for a few hours. -BB
RE: PSINet/Cogent Latency
I see your point, but I still think RRD is "good enough". If cisco/foundry/juniper added this to their respective OS's -- I'd be a happy camper... If they don't -- I won't lose sleep over it. --Phil -Original Message- From: Doug Clements [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 2:12 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency - Original Message - From: "Phil Rosenthal" <[EMAIL PROTECTED]> Subject: RE: PSINet/Cogent Latency > I don't think RRD is that bad if you are gonna check only every 5 > minutes... > > Again, perhaps I'm just missing something, but so lets say you measure > 30 seconds late , and it thinks its on time -- So that one sample will > be higher , then the next one will be on time, so 30 seconds early for > that sample -- it will be lower. On the whole -- it will be accurate > enough -- no? If you're polling every 5 minutes, with 2 retrys per poll, and you miss 2 retrys, then your next poll will be 5 minutes late. It's not disastrous, but it's also not perfect. Again, peaks and vallys on your graph cost more than smooth lines, even with the same total bandwidth. Do you want to be the one to tell your customers your billing setup is "accurate enough", and especially that it's going to have a tendancy to be "accurate enough" in your favor? > Besides I think RRD has a bunch of things built in to deal with > precisely this problem. Wouldn't that be just spiffy! > I'm not saying a hardware solution can't be better -- but it is likely > overkill compared to a few cheap intels running RRD -- assuming your > snmpd can deal with the load... No extra hardware needed. I think the desired solution was integration into the router. The data is already there, you just need software to compile it and ship it out via a reliable reporting mechanism. For being relatively simple, it's a nice idea that it could replace the "almost" in an "almost accurate" billing process. --Doug
RE: PSINet/Cogent Latency
I have a small RRD project box that polls 200 interfaces and has it takes 1 minute, 5 seconds to run with 60% cpu usage (so obviously it can be streamlined if I wanted to work on it). I guess the limit in this implementation is 1000 interfaces per box in this setup -- but I see most of the CPU usage is in the forking of snmpget over and over. Im sure I could write a small program in C that could do this at least 10X more efficiently. That's 10,000 interfaces with RRD on one intel -- if you are determined to do it. I think if you are billing 10k interfaces, you can afford a 2nd intel box to check the 2nd 10,000, no? My point is that if you have sufficient clue, time, and motivation -- Today's generic PCs are capable to do many "large" tasks... --Phil -Original Message- From: Richard A Steenbergen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 2:10 AM To: Phil Rosenthal Cc: 'Doug Clements'; [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency On Tue, Jul 23, 2002 at 01:56:45AM -0400, Phil Rosenthal wrote: > > I don't think RRD is that bad if you are gonna check only every 5 > minutes... RRD doesn't measure anything, it stores and graphs data. The perl pollers everyone is using can barely keep up with 5 minute samples on a couple dozen routers and a few hundred interfaces, requiring "poller farms" to be distributed across a network, 'lest a box or part of the network break and you lose data. > Again, perhaps I'm just missing something, but so lets say you measure > 30 seconds late , and it thinks its on time -- So that one sample will > be higher , then the next one will be on time, so 30 seconds early for > that sample -- it will be lower. On the whole -- it will be accurate > enough -- no? "enough" is a relative term, but sure. :) > I'm not saying a hardware solution can't be better -- but it is likely > overkill compared to a few cheap intels running RRD -- assuming your > snmpd can deal with the load... What hardware... storing a few byte counters is trivial, but polling them through snmp is what is hard (never trust a protocol named "simple" or "trivial"). Creating a buffer of samples which can be periodically sampled should be easy and painless. I don't know if I call periodic ftp "painless" but its certainly a start. -- 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: PSINet/Cogent Latency
I don't think RRD is that bad if you are gonna check only every 5 minutes... Again, perhaps I'm just missing something, but so lets say you measure 30 seconds late , and it thinks its on time -- So that one sample will be higher , then the next one will be on time, so 30 seconds early for that sample -- it will be lower. On the whole -- it will be accurate enough -- no? Besides I think RRD has a bunch of things built in to deal with precisely this problem. I'm not saying a hardware solution can't be better -- but it is likely overkill compared to a few cheap intels running RRD -- assuming your snmpd can deal with the load... --Phil -Original Message- From: Doug Clements [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 1:50 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency - Original Message - From: "Phil Rosenthal" <[EMAIL PROTECTED]> Subject: RE: PSINet/Cogent Latency > Call me crazy -- but what's wrong with setting up RRDtool with a > heartbeat time of 30 seconds, and putting in cron: > * * * * * rrdscript.sh ; sleep 30s ; rrdscript.sh > > Wouldn't work just as well? > > I haven't tried it -- so perhaps this is too taxing (probably you > would only run this on a few interfaces anyway)... Redback's implementation overcame the limitation of monitoring say, 20,000 user circuits. You don't want to poll 20,000 interfaces for maybe 4 counters each, every 5 minutes. I think the problem with using rrdtool for billing purposes as described is that data can (and does) get lost. If your poller is a few cycles late, the burstable bandwidth measured goes up when the poller catches up to the interface counters. More bursting is bad for %ile (or good if you're selling it), and the customer won't like the fact that they're getting charged for artifically high measurements. Bulkstats lets the measurement happen independant of the reporting. --Doug
RE: PSINet/Cogent Latency
Call me crazy -- but what's wrong with setting up RRDtool with a heartbeat time of 30 seconds, and putting in cron: * * * * * rrdscript.sh ; sleep 30s ; rrdscript.sh Wouldn't work just as well? I haven't tried it -- so perhaps this is too taxing (probably you would only run this on a few interfaces anyway)... The last time I tested such a thing was on an uplink doing ~200 mgs and deviation was about +/- 5mbs per second --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Doug Clements Sent: Tuesday, July 23, 2002 12:59 AM To: Richard A Steenbergen Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency - Original Message - From: "Richard A Steenbergen" <[EMAIL PROTECTED]> Subject: Re: PSINet/Cogent Latency > Personally I would like to see the data collection done on the router > itself where it is simple to collect data very frequently, then pushed > out. This is particularly important when you are doing things like > billing 95th percentile, where a loss of connectivity between the > polling machine and the device is a loss of billing information. Redbacks can actually do this with what they call Bulkstats. Collects data on specified interfaces and ftp uploads the data file every so specified often. Pretty slick. Course, this isn't very helpful with Redback's extensive core router lineup, but still. --Doug
RE: PSINet/Cogent Latency
As you probably guessed, I do... TCP is designed to not saturate links, so... If you take what should be 60 megs of traffic and put it limit it to 45, else queue for a while, or drop if queue full... The sessions will slow-start back up to a slow enough speed that wont drop. No (or very little) packet loss, but lower quality of service anyway. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Rubenstein Sent: Tuesday, July 23, 2002 12:05 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: PSINet/Cogent Latency An effective way would to graph queue drops: Serial4/1/1 is up, line protocol is up Description: to PSI via 3x-xxx-xxx- Internet address is 154.13.64.22/30 Last clearing of "show interface" counters 5w4d Queueing strategy: fifo Output queue 0/40, 2275 drops; input queue 0/75, 0 drops 30 second input rate 5000 bits/sec, 6 packets/sec 30 second output rate 39911000 bits/sec, 4697 packets/sec 144472370 packets input, 2769590243 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 1 giants, 0 throttles 0 parity 5 input errors, 5 CRC, 0 frame, 0 overrun, 1 ignored, 0 abort 1969955129 packets output, 430008350 bytes, 0 underruns FYI, for those of you commenting on my full PSI pipe, with a very small queue depth of only 40 packets, we've seen 0.00011548% percent drop -- 1 in every 865914 packets sent. Agreed, not 0%, but still, arguably that would never, ever be noticed by anyone. Once again, I don't condone; however, 1/1th of a percent of packet loss is easily worth the decreased cost in traffic sent to this endpoint. Anyone disagree? (an important a seperate note is that CAR/CEF drops due to ICMP reaching over 10 mb/s would trigger the same counter) On Mon, 22 Jul 2002, [EMAIL PROTECTED] wrote: > > Is there patch or special config example available that would allow me > to use mrtg (or rather rrdtool) to measure more often and then graph > it in a way that would show standard 5-min graph but also separate > line showing those micro burst and actual peak usage? > > On Mon, 22 Jul 2002, Randy Bush wrote: > > > > > > 40mb/s isn't "loaded" for a DS3? > > > > if you are measuring 40mb at five min intervals, micro peaks are > > pegged out causing serious packet loss. > > > > randy > > > -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: PSINet/Cogent Latency
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Richard A Steenbergen On Mon, Jul 22, 2002 at 11:34:44PM -0400, Phil Rosenthal wrote: > I'd rather have a noncongested gige public peer than a ds3 private peer any day. Except apparently that's called trolling ;) --Phil
RE: PSINet/Cogent Latency
My point exactly -- I guess some people disagree... Probably with any sort of queuing there will only be minimal packet loss at 40mbit, but at any point one more stream can push it up to 43mbit, and then queuing might no longer be enough... (and even if it is, can we say lag?) --Phil -Original Message- From: Randy Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 11:31 PM To: Phil Rosenthal Cc: [EMAIL PROTECTED] Subject: RE: PSINet/Cogent Latency > 40mb/s isn't "loaded" for a DS3? if you are measuring 40mb at five min intervals, micro peaks are pegged out causing serious packet loss. randy
RE: PSINet/Cogent Latency
With the price of transit where it is today: #1 Transit is often cheaper than peering (if you factor in port costs on public exchanges, or link costs for private exchanges) #2 The difference in price is likely not large enough for me to risk: saturation, latency, etc... My customers pay me to provide them a premium service, and I see value in providing that service. Some people have no problem selling cogent -- what can I say... You get what you pay for... And no, I'm not trolling. Is having a different opinion not allowed now? And 40mbit over a 45mbit circuit, if it is to an uplink/peer -- well, if he has customers who are connected at 100mbit switched uncapped (likely) -- then many customers (possibly even some DSL customers...) can flood off his peer links with only a 5mbit stream. --Phil -Original Message- From: Brian Wallingford [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 11:13 PM To: Phil Rosenthal Cc: 'Alex Rubenstein'; [EMAIL PROTECTED] Subject: RE: PSINet/Cogent Latency Good for you, Phil. Chime in again when you've got something useful to offer. In the meantime, you may want to review Economics 101 along with certain queueing schemes, especially RED (no, I'm not endorsing the idea of oversubscribing to the extreme, but then again, neither was Alex). Also, re-read the previous post. There's a big difference between choice and facility. Did you grow up spending Summers in the Hamptons with no conception of the value of a dollar, or are you simply trolling? -brian On Mon, 22 Jul 2002, Phil Rosenthal wrote: : :Actually, I wouldn't think about getting T1, DS3 or OC3 in the first :place ;) :Oc-12 is the minimum link I would even look at -- and my preference is :gig-e... Even if there is only 90 megs on the interface... : :--Phil : :-Original Message- :From: Alex Rubenstein [mailto:[EMAIL PROTECTED]] :Sent: Monday, July 22, 2002 10:02 PM :To: Phil Rosenthal :Cc: [EMAIL PROTECTED] :Subject: RE: PSINet/Cogent Latency : : : : :On Mon, 22 Jul 2002, Phil Rosenthal wrote: : :> :> I call any upstream link 'over capacity' if either: :> 1) There is less than 50mb/s unused : :That must work well for T1's and DS3's. : : :> 2) The circuit is more than 50% in use : :I call it 'over capacity' too, but that doesn't mean all the ducks are :in a row to get both sides to realise an upgrade is needed, and even if :they do realise it, to actually get it done. I am sure 2238092 people on :this list can complain of the same problem. : :So, what do you do? You monitor it's usage, making adjustments to make :sure it doesn't get clobbered. You can easily run DS-3s at 35 to 40 :mbit/sec, with little to none increase in latency from the norm. Many :people do this as well, even up to OC12 or higher levels all the time. : : : : :> I guess by my definition a DS3 is always 'over capacity' : :Which must work very well for those DS3's doing 10 to 20 mb/s. Do you :upgrade those to OC3 or beyond? : : :-- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- :--Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- : : : :
RE: PSINet/Cogent Latency
Actually, I wouldn't think about getting T1, DS3 or OC3 in the first place ;) Oc-12 is the minimum link I would even look at -- and my preference is gig-e... Even if there is only 90 megs on the interface... --Phil -Original Message- From: Alex Rubenstein [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 10:02 PM To: Phil Rosenthal Cc: [EMAIL PROTECTED] Subject: RE: PSINet/Cogent Latency On Mon, 22 Jul 2002, Phil Rosenthal wrote: > > I call any upstream link 'over capacity' if either: > 1) There is less than 50mb/s unused That must work well for T1's and DS3's. > 2) The circuit is more than 50% in use I call it 'over capacity' too, but that doesn't mean all the ducks are in a row to get both sides to realise an upgrade is needed, and even if they do realise it, to actually get it done. I am sure 2238092 people on this list can complain of the same problem. So, what do you do? You monitor it's usage, making adjustments to make sure it doesn't get clobbered. You can easily run DS-3s at 35 to 40 mbit/sec, with little to none increase in latency from the norm. Many people do this as well, even up to OC12 or higher levels all the time. > I guess by my definition a DS3 is always 'over capacity' Which must work very well for those DS3's doing 10 to 20 mb/s. Do you upgrade those to OC3 or beyond? -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: PSINet/Cogent Latency
I call any upstream link 'over capacity' if either: 1) There is less than 50mb/s unused 2) The circuit is more than 50% in use I guess by my definition a DS3 is always 'over capacity' --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Brian Sent: Monday, July 22, 2002 9:36 PM To: [EMAIL PROTECTED]; 'Alex Rubenstein' Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency bwahaha, 2 funnee. I gotta think most people would be thinking of adding another ds3 at that point. Bri - Original Message - From: "Phil Rosenthal" <[EMAIL PROTECTED]> To: "'Alex Rubenstein'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, July 22, 2002 6:05 PM Subject: RE: PSINet/Cogent Latency > > 40mb/s isn't "loaded" for a DS3? > > --Phil > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf > Of Alex Rubenstein > Sent: Monday, July 22, 2002 8:27 PM > To: Derek Samford > Cc: [EMAIL PROTECTED] > Subject: Re: PSINet/Cogent Latency > > > > > Yes, it's horrid. I've been peering with PSI for going on three years, > and it's never been as bad as it is now. > > oddly enough, we see 30+ msec across a DS3 to them, which isn't that > loaded (35 to 40 mb/s). > > Then, behind whatever we peer with, we see over 400 msec, with 50% > loss, during business hours. > > > > On Mon, 22 Jul 2002, Derek Samford wrote: > > > > > There was some mail being tossed around earlier about Cogent > having > > latency. I'm actually seeing this on PSINet (Now owned by > > Cogent.) Is anyone else still seeing the latency they were > > experiencing earlier? > > > > Derek > > > > -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- > --Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- > > >
RE: PSINet/Cogent Latency
40mb/s isn't "loaded" for a DS3? --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Rubenstein Sent: Monday, July 22, 2002 8:27 PM To: Derek Samford Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency Yes, it's horrid. I've been peering with PSI for going on three years, and it's never been as bad as it is now. oddly enough, we see 30+ msec across a DS3 to them, which isn't that loaded (35 to 40 mb/s). Then, behind whatever we peer with, we see over 400 msec, with 50% loss, during business hours. On Mon, 22 Jul 2002, Derek Samford wrote: > > There was some mail being tossed around earlier about Cogent having > latency. I'm actually seeing this on PSINet (Now owned by > Cogent.) Is anyone else still seeing the latency they were > experiencing earlier? > > Derek > -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: effects of NYC power outage
A side-note on why 25 Broadway lost power. I am told they had the fuel, but the "Local 3" union worker who was watching the gauges on the generator misread the dials, and a human error caused the generator to run bone dry. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Marshall Eubanks Sent: Monday, July 22, 2002 8:27 AM To: Craig Partridge; [EMAIL PROTECTED] Subject: Re: effects of NYC power outage On Mon, 22 Jul 2002 08:05:21 -0400 Craig Partridge <[EMAIL PROTECTED]> wrote: > > > Anyone got good data comparing the effects on the Net (BGP > reachability, > etc) of this weekend's NYC power outage with the effects power outage late > on September 11th. > Hello; To be honest, I did not see any BGP or other routing effects from the NYC fire (there were problems on Abilene this weekend, but they were due to a bad router update). My data are presented on http://www.multicasttech.com/status and are fairly coarse-grained, having a 6 hour update cycle. The 9/11 problems actually came starting on 9/13 and 14 when the battery / generator power started running out at 25 Broadway. My understanding is that the biggest problem was the inability to access the facility to refuel. My (multicast-centric) analysis of the 9/11 response was presented at Nanog 23 : http://www.nanog.org/mtg-0110/eubanks.html You should also look at the other two presentations on 9/11 and the Internet at that meeting : http://www.nanog.org/mtg-0110/agenda.html Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ > I'm on a National Academy of Sciences committee looking at how the > Internet fared on 9/11 and we're always in search of good comparative > data. > > Thanks! > > Craig Partridge > Chief Scientist, BBN Technologies
Verio filtering... Would be nice if they at least honored what they said...
http://info.us.bb.verio.net/routing.html Quote: "We do not announce prefixes longer than /24." Then why do I have: 5 /25 2 /26 3 /27 3 /28 21 /29 *sigh* I guess we don't eat our own dogfood... Searching for matching routes, use ^C to quit... Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH S:SUPPRESSED F:FILTERED Prefix Next HopMetric LocPrf Weight Status 1 63.73.183.0/25 129.250.126.97 2 1000 EF AS_PATH: 2914 10910 10910 10910 10910 10910 10910 10910 10910 10910 8012 2 128.241.222.0/28 129.250.126.97 3 1000 EF AS_PATH: 2914 12008 3 168.143.110.0/28 129.250.126.97 3 1000 EF AS_PATH: 2914 12008 4 192.41.162.0/25129.250.126.97 3 1000 EF AS_PATH: 2914 14745 5 198.107.213.8/29 129.250.126.97 3 1000 EF AS_PATH: 2914 11854 11854 11854 11854 11854 11854 11854 6 198.107.213.16/29 129.250.126.97 3 1000 EF AS_PATH: 2914 11853 11853 11853 7 198.107.213.24/29 129.250.126.97 3 1000 EF AS_PATH: 2914 12179 8 198.107.213.32/29 129.250.126.97 3 1000 EF AS_PATH: 2914 13790 9 198.107.213.40/29 129.250.126.97 3 1000 EF AS_PATH: 2914 10912 10912 10912 Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH S:SUPPRESSED F:FILTERED Prefix Next HopMetric LocPrf Weight Status 10 198.107.213.48/29 129.250.126.97 3 1000 EF AS_PATH: 2914 12180 11 198.107.213.56/29 129.250.126.97 2 1000 EF AS_PATH: 2914 10910 10910 10910 10910 10910 10910 10910 10910 10910 12 198.107.213.64/29 129.250.126.97 4 1000 EF AS_PATH: 2914 13789 13789 13789 13789 13789 13 198.107.213.72/29 129.250.126.97 3 1000 EF AS_PATH: 2914 12178 14 198.107.213.80/29 129.250.126.97 3 1000 EF AS_PATH: 2914 6993 6993 6993 15 198.107.213.88/29 129.250.126.97 3 1000 EF AS_PATH: 2914 10911 10911 10911 16 198.107.213.96/29 129.250.126.97 3 1000 EF AS_PATH: 2914 10913 17 198.107.213.104/29 129.250.126.97 3 1000 EF AS_PATH: 2914 13791 13791 13791 13791 13791 13791 18 198.107.213.112/29 129.250.126.97 3 1000 EF AS_PATH: 2914 13792 13792 13792 13792 13792 13792 Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH S:SUPPRESSED F:FILTERED Prefix Next HopMetric LocPrf Weight Status 19 198.107.213.120/29 129.250.126.97 3 1000 EF AS_PATH: 2914 12181 20 198.107.213.144/29 129.250.126.97 3 1000 EF AS_PATH: 2914 14742 14742 14742 21 198.107.213.152/29 129.250.126.97 3 1000 EF AS_PATH: 2914 14636 14636 14636 14636 14636 14636 14636 22 198.107.213.160/29 129.250.126.97 3 1000 EF AS_PATH: 2914 14743 14743 14743 23 198.107.213.168/29 129.250.126.97 3 1000 EF AS_PATH: 2914 14745 24 198.107.213.176/29 129.250.126.97 3 1000 EF AS_PATH: 2914 19024 19024 19024 25 204.27.124.128/25 129.250.126.97 3 1000 EF AS_PATH: 2914 21637 26 204.171.181.32/29 129.250.126.97 3 1000 EF AS_PATH: 2914 16821 16821 16821 16821 27 207.20.149.96/27 129.250.126.97 3 1000 EF AS_PATH: 2914 11189 Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH S:SUPPRESSED F:FILTERED Prefix Next HopMetric LocPrf Weight Status 28 207.20.172.128/26 129.250.126.97 3 1000 EF AS_PATH: 2914 19359 29 207.174.18.128/27 129.250.126.97 3 1000 EF AS_PATH: 2914 13790 3404 19129 30 208.239.6.64/26129.250.126.97 3 1000 EF AS_PATH: 2914 11655 31 208.244.144.128/25 129.250.126.97 4 1000 EF AS_PATH: 2914 25626 32 209.69.100.224/28 129.250.126.97 3 1000 EF AS_PATH: 2914 18776 33 209.69.154.192/27 129.250.126.97 3 1000 EF AS_PATH: 2914 18776 34 210.7.223.0/25 129.250.126.97 3 1000 EF AS_PATH: 2914 9874 3549 4682 9335
RE: verio arrogance
How is it arrogant? I read that as: a customer set up an exploitable FormMail. Verio received notice about it. Verio removed the FormMail in question. Verio asked to be removed since they corrected the problem. Verio was ignored. Verio may have some problems with not terminating spammers, and I believe this to be the truth -- I buy from verio, and Don't spam, and whenever one of my clients spam, they get terminated for it. I receive plenty of spam from verio ips, and no matter how much I complain, it never gets terminated. This is probably a scenario of asking sales rep "If I want to spam, but I pay more per meg -- Is this OK?" and getting a positive answer. That is why the NANAE people don't like verio. But, nonetheless, I don't think that putting verio's mailserver on a formmail list is accomplishing anything good, since they fixed THAT problem... --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Kai Schlichting Sent: Thursday, July 18, 2002 6:37 PM To: [EMAIL PROTECTED] Cc: Kai Schlichting Subject: Re: verio arrogance How's THIS for Verio arrogance, going to a whole new level: http://www.monkeys.com/anti-spam/filtering/verio-demand.ps Details were on the SPAM-L list Wed, 17 Jul 2002 15:51:05 EDT: Verio threatens to sue Ron Guilmette over the IP 208.55.91.59 appearing on his FormMail.pl open-proxy/formmail server DNSBL. And given the ever-increasing number of spammers now hopping onto Verio tells me that Verio must be well down the spiral of death (spammers seem to be attracted by NSP's going chapter 7/11, or who are getting close), or else the dozen-or-so automated messages going to [EMAIL PROTECTED] every week complaining about connections (real or attempted) to hosts under my control, and originating from their spamming customers would have shown any results over time. I don't need connectivity to 208.55.0.0/16. I really don't, and I have not the slightest tolerance for litigious, small-minded, panic-lawyer-dialling scum like this. /etc/mail$ grep 208.55 access.local 208.55 550 Access for FormMail spam and litigious scum denied - Verio in their XXX - we block more than just 208.55.91.59 - Spammers must die - see http://www.monkeys.com/anti-spam/filtering/verio-demand.ps /etc/mail$ PS: I also have zero tolerance for Nadine-type spam-generating, "single-opt-in", "87% permission-based" emailers nowadays: 2 bounces or a single mail to a never-existing account, and all your /24's are off into gated.conf as a next-hop route to 127.0.0.1. And no, they won't get around that by advertising /25's. Good-bye route-prefix-filtering wars, and welcome to the war on spam, where Null0'd /28's for filtering 'undesirables' just doesn't cut it any more. Casualties like 10-15 bystanding rackspace.com customers with a "Nadine- type" mailer in neighboring IP space be damned: "move your servers into a different slum, cause da landlord's running down 'da neighborhood". -- "Just say No" to Spam Kai Schlichting New York, Palo Alto, You name it Sophisticated Technical Peon Kai's SpamShield is FREE! http://www.SpamShield.org | | | LeasedLines-FrameRelay-IPLs-ISDN-PPP-Cisco-Consulting-VoiceFax-Data-Muxe s WorldWideWebAnything-Intranets-NetAdmin-UnixAdmin-Security-ReallyHardMat h
RE: No one behind the wheel at WorldCom
I've found that a regex that is longer than about 200 characters with the format of ^1_(2|3|4|5)$ (say 20 different as numbers in the parenthesis) can easily crash a Bigiron running the latest code. If you were to set up a filter that only accepted updates with ^customer_(d1|d2|d3)$ d1=downstream of customer 1, it will choke with a fairly large peer... Don't know how the other vendors handle it. I reported this to foundry a few weeks ago, no fix as of yet (and I doubt there will be). --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Pedro R Marques Sent: Tuesday, July 16, 2002 2:44 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: No one behind the wheel at WorldCom [EMAIL PROTECTED] (Majdi S. Abbas) writes: > Actually, I think you'll find that bad data is only a small part > of the problem; even with good data, there isn't enough support from > various router vendors to make it worthwhile; it's effectively impossible > to prefix filter a large peer due to router software restrictions. We > need support for very large (256k+ to be safe) prefix filters, and the > routing process performance to actually handle a prefix list this large, > and not just one list, but many. > > IRR support for automagically building these prefix lists would > be a real plus too. Building and then pushing out filters on another > machine can be quite time consuming, especially for a large network. > From a point of view of routing software the major challenge of handling a 256k prefix list is not actually applying it to the received prefixes. The most popular BGP implementations all, to my knowledge, have prefix filtering algorithms that are O(log2(N)) and which probably scale ok... while it would be not very hard to make this a O(4) algorithm that is probably not the issue. Implementations do always have to do a O(log2(N)) lookup on the routing table with a received prefix, and to afaik that is not a performance problem for anyone. What all implementations that i'm familiar with do have a problem with is to actually accept the configuration of 256k lines of text to use as a filter. Configuration parsing is typically not designed for such numbers... it tends to work with major vendors albeith a bit slowly. If the above disagrees with your experience please let me know. Assuming that the bottleneck is in fact being able to parse configuration, it begs the question what to do about it... I'm sure all vendors will be able to, given enought incentive, optimize their text parsing code in order to do this faster... but it begs the question, would you actually fix anything by doing that ? My inclination would be to think that you would just tend to move the bottleneck to the backend systems managing the configuration of such lists, if it isn't there already, presently. Of course i'm completly ignorant of the backends that most of you use to manage your systems and the above is just uneducated guessing, although i would apreciate further education. I would be inclined to agree with your statement that the major blame should lie on "router vendors" if you see your router vendor as someone that sells you the network elements + the NMS to manage it. But in my guestimate the focal point of our search for a culprit should be the NMS or the NMS -> router management mechanism. Idealy the latter should be more computer friendly than text parsing. Just an attempt to equally and democratically distribute blame around :-) regards, Pedro.
RE: Colocation Enclosures
I may be wrong, but I believe Chatsworth makes some 2 section cabs. I remember verio having some 2-sections and I was pretty sure they only had Chatsworth in NYC... --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Christopher J. Wolff Sent: Monday, July 15, 2002 11:49 PM To: [EMAIL PROTECTED] Subject: Colocation Enclosures Greetings, I'm trying to find alternative sources for a 2 or 3 section locked colocation cabinet cosmetically similar to the following: http://www.budind.com/images/big/DC-8125bg.jpg It appears that Encoreusa is no longer in business so I would appreciate any pointers as to where I may locate such an enclosure. Thank you! Chris
RE: fractional gigabit ethernet links?
This may sound a bit ridiculous, but say the timer is every 0.25ms. 100kbit per 0.25ms = 400,000kbit or 400 mbit. It is remotely possible to hit a 300 mbit limit with only 100kbits of traffic, if the timer is sufficiently short, and your traffic is sufficiently bursty. Unless your traffic is Mcast, I doubt that issue is related. Can you ask your provider how exactly they are limiting the pipe? When dealing with 300 or so megs, I doubt they will be shaping with a policy friendly to you, as the logistics of doing so are a bit difficult. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Rubenstein Sent: Monday, July 15, 2002 11:06 PM To: Phil Rosenthal Cc: [EMAIL PROTECTED] Subject: RE: fractional gigabit ethernet links? On Mon, 15 Jul 2002, Phil Rosenthal wrote: > > Hello Alex, > > I'd say this sounds obvious, but may be deceptively so... > If you are taking a pipe capable of 1000 mbit, and rate-limiting it to > 311 mbit, the logic used may be: > > In the last 1000 msec have there been more than 311mbits? If yes: > drop. Except, we're at the levels of 100 kbit/second in our tests. I did just find CSCdr94172, which might be related. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: fractional gigabit ethernet links?
Hello Alex, I'd say this sounds obvious, but may be deceptively so... If you are taking a pipe capable of 1000 mbit, and rate-limiting it to 311 mbit, the logic used may be: In the last 1000 msec have there been more than 311mbits? If yes: drop. What you want is to shape the traffic, so the rule would be: In the last 1000 msec have there been more than 311 mbits? If yes: store until the msec period is up, then transmit. If you are pushing 100 mbits over this link, it is entirely likely that there will be a few sub-second burts up to 1000 mbit, and a few sub-second drops to 0mbit. An option for you would be to just figure out what the exact rate-limiting rules are, and then shape it into those rules on your side of the link -- assuming they wont change it to a shaping rule. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Rubenstein Sent: Monday, July 15, 2002 10:48 PM To: [EMAIL PROTECTED] Subject: fractional gigabit ethernet links? Hello, I'm trying to troubleshoot a problem with a fractional (311 mbit/second) gigabit-ethernet line provided to me by a metro access provider. Specifically, it is riding a gig-e port of a 15454. The behavior we are seeing is an occasional loss of packets, adding up to a few percent. When doing a cisco-type ping across the link, we were seeing a consistent 3 to 4 percent loss. For fun, the provider brought it up to 622 mbit/second, and loss dropped considerably, but still hangs at about 1 to 2 percent. There is no question in my mind the issue is with the line, as we've done a wide variety of tests to rule out the local equipment (MSFC2s, FYI). Any clues would be exceptional. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: No one behind the wheel at WorldCom
Wow, I feel stupid now, they actually have a /9. Ignore me ;) --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Phil Rosenthal Sent: Friday, July 12, 2002 10:24 PM To: [EMAIL PROTECTED] Subject: No one behind the wheel at WorldCom BGP routing table entry for 63.0.0.0/9, version 7001923 Paths: (5 available, best #1, table Default-IP-Routing-Table) Advertised to peer-groups: customer Advertised to non peer-group peers: 209.123.37.30 701 157.130.9.141 (metric 65024) from 209.123.11.10 (209.123.12.59) Origin IGP, localpref 300, valid, internal, best Community: 8001:666 8001:701 701 157.130.9.141 (metric 65024) from 209.123.11.245 (209.123.12.59) Origin IGP, localpref 300, valid, internal Community: 8001:666 8001:701 8001 7911 3561 701 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 200, valid, external Community: 8001:666 8001:7911 7911 3561 701, (received-only) 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 100, valid, external 15036 16631 174 701 209.123.37.30 from 209.123.37.30 (209.123.132.181) Origin IGP, localpref 100, valid, external Community: 8001:666 8001:16631 15036:0 15036:666 15036:16631 16631:1000 From: http://eng.nac.net/lookingglass/nyc.html Bgp: 63.0.0.0 Uunet has been announcing this for more than 2 days now. (not sure when since I cleared my bgp tables 2 days ago). --Phil
No one behind the wheel at WorldCom
BGP routing table entry for 63.0.0.0/9, version 7001923 Paths: (5 available, best #1, table Default-IP-Routing-Table) Advertised to peer-groups: customer Advertised to non peer-group peers: 209.123.37.30 701 157.130.9.141 (metric 65024) from 209.123.11.10 (209.123.12.59) Origin IGP, localpref 300, valid, internal, best Community: 8001:666 8001:701 701 157.130.9.141 (metric 65024) from 209.123.11.245 (209.123.12.59) Origin IGP, localpref 300, valid, internal Community: 8001:666 8001:701 8001 7911 3561 701 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 200, valid, external Community: 8001:666 8001:7911 7911 3561 701, (received-only) 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 100, valid, external 15036 16631 174 701 209.123.37.30 from 209.123.37.30 (209.123.132.181) Origin IGP, localpref 100, valid, external Community: 8001:666 8001:16631 15036:0 15036:666 15036:16631 16631:1000 From: http://eng.nac.net/lookingglass/nyc.html Bgp: 63.0.0.0 Uunet has been announcing this for more than 2 days now. (not sure when since I cleared my bgp tables 2 days ago). --Phil
RE: Just an FYI - Apache Worm on the loose
If you want to be really proactive... Just filter out port 80, and then you can't get hacked... --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Stephen J. Wilcox Sent: Wednesday, July 10, 2002 6:30 PM To: Scott Francis Cc: Jason Legate; [EMAIL PROTECTED] Subject: Re: Just an FYI - Apache Worm on the loose If you want to be proactive, filter this port across your backbone and you will very quickly see what hosts have been compromised.. on the other hand individual customers seem to use all their bandwidth so they tend to phone in pretty quick! Steve On Wed, 10 Jul 2002, Scott Francis wrote: > On Tue, Jul 09, 2002 at 02:26:23PM -0700, [EMAIL PROTECTED] said: > > There is an Apache worm out there, and it uses port 2001/udp to > > operate. You may wanna scan your own boxes for this open port. > > Announced last week on BUGTRAQ and elsewhere. > http://online.securityfocus.com/archive/1/279529 > > (and was it _really_ necessary to post a hex dump of the entire thing? > The actual source is available linked from the BUGTRAQ post above ...) >
RE: [OT] Re: Readiness for IPV6
You should be using cmd.exe under xp: C:\Documents and Settings\winter>cmd /? Starts a new instance of the Windows XP command interpreter --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthew S. Hallacy Sent: Tuesday, July 09, 2002 8:28 PM To: [EMAIL PROTECTED] Subject: [OT] Re: Readiness for IPV6 On Wed, Jul 10, 2002 at 02:01:35AM +0200, Jeroen Massar wrote: > > Ah.. so everywhere you see 'text' and have to input 'text' is DOS? > Cool bash == DOS, shells are DOS. > > A thing like this: > 8<- > Microsoft Windows 2000 [Version 5.00.2195] > (C) Copyright 1985-2000 Microsoft Corp. > > C:\> > ->8 > is called a "Command Prompt" and has nothing to do with DOS. Why > doesn't anybody complain when it's on *ix boxes ? It's shell > everywhere then :) > Pardon me: Microsoft Windows XP [Version 5.1.2600] C:\>command /? Starts a new instance of the MS-DOS command interpreter. COMMAND [[drive:]path] [device] [/E:n] [/P] [/C string] [/MSG] [snip rest of output] Looks like it still claims to be the MS-DOS command interpreter to me, using the 'user friendly' name of 'Command Prompt' doesn't change what it is. [snip] > They didn't 'exploit' me yet in the last 3 years I am using the > development versions of the stack :) And everything has bugs As soon as it's in use enough for an exploit to be useful, it will be. > [snip links] Don't forget http://www.microsoft.com/windowsxp/pro/techinfo/administration/ipv6/defa ult.asp Which instructs you to go to a command prompt, like I said =) > > And as for your "it's difficult': > http://www.ipng.nl/index.php3?page=setup.html&forcepage=windows.html > Or the single line: "ipv6 adu 3/fec0::1" > > Interface 3 (site 1): Local Area Connection > uses Neighbor Discovery > link-level address: 00-d0-b7-8f-5d-42 > preferred address fec0::1, infinite/infinite > preferred address 3ffe:8114:2000:240:2d0:b7ff:fe8f:5d42, > 2591593s/604393s (addrconf) > > Tada ;) > Yes, this is too difficult for 'joe blow user', as I said. > I think the problem is reading the docs is difficult. > IPv6 will be/is autoconfig all the way fortunatly so those 'native > config' tools isn't going to be used by a lot of people. Users do not read documentation. > > Maybe also a nice tool for people saying "but IPv4 has a GUI on > windows" you might like to type 'netsh' ones in your "DOS" prompt ;) If a user can't point, click, and go, they're unlikely to do something, I've dealt with people that went over a month without their internet access simply because they were afraid they would have to troubleshoot their internet connection over the phone. > btw.. DOS == command.com, NT = cmd.exe, there *is* a difference. Yes, one is named command.com, one is named cmd.exe, it was easier than typing start from the DOS command prompt. > Greets, > Jeroen -- Matthew S. HallacyFUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203
RE: Readiness for IPV6
-Original Message- From: Alif The Terrible [mailto:[EMAIL PROTECTED]] On Mon, 8 Jul 2002, Phil Rosenthal wrote: > As far as I can tell, neither Foundry Bigiron, nor Cisco 65xx support > IPV6 (I could be wrong). > > While they probably aren't the most popular routers, they are very > popular, and im sure plenty of cisco's smaller routers don't support > it either. I am on the 6bone using a combination of 2600 and Zebras. The 2600 doesn't do BGP6 yet, although it does RIP6 just fine. It's getting there... > How ready is the 'net to transit to IPV6 in the future? Define "future". It's coming, although slowly. But then, why hurry? The "emergency" was just another skyfall... --- Yes, I don't think we need it 'right now'. My concern is that at this point many companies are still buying routers that as of today have no support for IPv6. Given that a BigIron/65xx is mostly hardware forwarding, I speculate that they wont be able to support IPv6 with a trivial software upgrade (at least not at the same performance level). So, is someone buying such equipment today 'wasting money' since it will be completely obsolete with the onset of mass IPv6 roll-out likely in 2004 or 2005? --Phil
Readiness for IPV6
As far as I can tell, neither Foundry Bigiron, nor Cisco 65xx support IPV6 (I could be wrong). While they probably aren't the most popular routers, they are very popular, and im sure plenty of cisco's smaller routers don't support it either. How ready is the 'net to transit to IPV6 in the future? Should everyone be factoring in replacing big routers with IPV6 being the only reason? Just curious on others' opinions on this. --Phil
RE: Internet vulnerabilities
Except what if in my scenario, while flooding, it executed dd if=/dev/zero of=(hd) on all of the system drives. If someone wanted to do it, it could be done. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of David Ulevitch Sent: Thursday, July 04, 2002 2:23 PM To: [EMAIL PROTECTED] Subject: Re: Internet vulnerabilities > What if someone actually had the skills to disrupt BGP on a widescale? I think the media talk about "taking down the Internet" are kind of bogus. Nobody has ever died because they couldn't check their email. If the net went down for an hour, a day, or even a week I think that my mom and the rest of the non "glued-to-their-terminal" world would somehow struggle through and sustain a normal daily routine. -davidu [who probably would not survive a week long net outage ;) ] -- "Never doubt that a small group of thoughtful citizens can change the world. Indeed, it is the only thing that ever has." --Margaret Mead
RE: Internet vulnerabilities
Thinking about a physical threat... If you go to 111 8th ave, NYC. They have added security since 9-11-01 which now requires either building ID, or showing a driver's license before entering building (because terrorists don't have driver's licenses). On some floors (eg the 7th). The building risers and conduits are completely exposed. I can't help but wonder how much damage a terrorist attack to that would do. Also, say someone from a moderately fast internet connection (OC-3) ran nmap across the entire internet on ports like 21,22,53,80,443,3306. In one day, they can probably have a list of every server answering those ports, and the versions of the daemons on them. Next, just wait for an wide enough exploit to come out, and then write a Trojan that has a list of every other server vulnerable, and on every hack, it splits the list in 2, and roots another box and gives it the 2nd half of the list. I estimate that with a wide enough exploit (eg apache or openssh), you could probably compromise 20% of the servers on the net within 1 hour, and then have them all begin a ping flood of something "far away" network wise (meaning a box in NYC would flood a box in SJC, a box in SJC would flood a box in Japan, etc... Trying to have as much bit distance as possible). Damn scary, but I believe if someone was determined enough, they could take down the whole 'net within one hour of pressing "enter". I suppose there really isn't anything that can be done at this point to make that scenario impossible. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Lewis Sent: Thursday, July 04, 2002 1:57 PM To: [EMAIL PROTECTED] Subject: Internet vulnerabilities There is a lot of news lately about terrorist groups doing recon on potential targets. The stories got me thinking. What are the real threats to the global Internet? I am looking for anything that might be a potential attack point. I don't want to start a flame war, but any interesting or even way out there idea is welcome. Is it feasible that a coordinated attack could shutdown the entire net? I am not talking DDoS. What if someone actually had the skills to disrupt BGP on a widescale? jas
RE: Sprint peering policy
My math shows ~500bps per US citizen: Assuming 150,000,000,000 bits and 280,000,000 citizens. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of E.B. Dreger Sent: Monday, July 01, 2002 9:21 PM To: [EMAIL PROTECTED] Subject: Re: Sprint peering policy RAS> Date: Mon, 1 Jul 2002 21:07:06 -0400 RAS> From: Richard A Steenbergen RAS> If there is more than ~150Gbps of traffic total (counting the RAS> traffic only once through the system) going through the US RAS> backbones I'd be very surprised. Oversimplifying the model, this works out to ~500 kbps per US citizen. Allowing for burstiness, I offer 50 GB/mo transfer as conservative for said bandwidth level. (I need to start pumping more traffic to catch up to my personal fair share!) Interesting point. 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 peering policy
I switch traffic measured in gbits, and everything is kept on private peering at the moment (although that is likely to change in the not-too-distant future). I doubt I will push more than 200 on the public exchange I am thinking of joining... Many public exchanges either feature few large carriers, or large carriers that would not be interested in peering with you, unless you are a Fortune 500. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Stephen J. Wilcox Sent: Monday, July 01, 2002 7:48 PM To: Deepak Jain Cc: Miquel van Smoorenburg; [EMAIL PROTECTED] Subject: RE: Sprint peering policy 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.. Steve On Mon, 1 Jul 2002, Deepak Jain wrote: > > > WCOM (or anyone) has a certain amount of cost (people, management, > etc) to deal with a peer. If they are a respectable network, they > notify their peers of maintenance, and field their calls when sessions > disappear. A large ISPs fees generally tend to be higher than a Joe > Six Pack ISP. > > Regional routes for a Joe Six Pack ISP are not going to represent a > significant enough level of traffic (1-2,5,10mb/s?) for a large > network to waste management time on. Heck, DNS servers use more than > 2mb/s of bandwidth nowadays (for medium sized networks and above). A > few megabits a second is nothing. > > Deepak Jain > AiNET > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Miquel van Smoorenburg > Sent: Monday, July 01, 2002 3:42 PM > To: [EMAIL PROTECTED] > Subject: Re: Sprint peering policy > > > > In article > v5DgN/ > [EMAIL PROTECTED]>, > Phil Rosenthal <[EMAIL PROTECTED]> wrote: > >Apples and oranges. Wcom isn't talking about dropping AT&T as a > >peer, they just don't want to peer with "Joe Six Pack ISP". Wcom > >would likely not peer with most ISPs, and I wouldn't expect them to. > >They gain absolutely nothing from it, and the small ISPs gain plenty. > >Wcom's costs only increase since they need "more ports". > > Wcom could peer with "Joe Six Pack ISP" at an exchange if > > - connection cost is very low (shared ethernet) > - they don't peer with Joe's upstream at the same location > - they only announce regional routes to Joe > - they use hot potato routing everywhere > > in that case, the peering would just be local/regional, probably all > that Joe is after anyway > > Mike. > > >
RE: Sprint peering policy
--- > > I would venture to say that to WorldCom, all traffic is destined to a > peer, or a customer, and they NEVER pay for traffic. Peering with them > is entirely a courtesy from them to you, as they can always see you > through their current peers. I think you missed the definition of "tier 1"... Oh wait, we're all using made-up definitions anyways. Nevermind. --- That's my definition of "Tier 1", in case you hadn't guessed. --- > The fact that they failed, having had such extensive peering, proves > that peering has no relation to financial difficulties (in my mind, at > least) You are one very confused individual. --- You are saying that Wcom doesn't peer enough to remain financially viable? I was never a Wcom subscriber, but I would venture to guess that they never go more than 30ms extra (and almost never more than 20ms extra) than any other carrier starting at the same physical location, and ending at the same network location. eg, verio has "a lot" of peering in NYC, Virginia, and Chicago. 50% of my traffic to them gets dumped off in NYC or Newark (close), 25% in virginia, 25% in chicago. I avoid the chicago and virginia peers as much as possible. I would assume that Wcom would have probably closer to 75% staying in NYC, but, this is completely an assumption. If I'm correct, then I think that is more than enough peering to keep their customers happy, no? --Phil
RE: Sprint peering policy
In your example, it could work, but they would probably still prefer you paid 'someone' for it, even if it isn't them. (The mere fact that you are paying keeps you unable to compete directly with them) --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Miquel van Smoorenburg Sent: Monday, July 01, 2002 3:42 PM To: [EMAIL PROTECTED] Subject: Re: Sprint peering policy In article , Phil Rosenthal <[EMAIL PROTECTED]> wrote: >Apples and oranges. Wcom isn't talking about dropping AT&T as a peer, >they just don't want to peer with "Joe Six Pack ISP". Wcom would >likely not peer with most ISPs, and I wouldn't expect them to. They >gain absolutely nothing from it, and the small ISPs gain plenty. >Wcom's costs only increase since they need "more ports". Wcom could peer with "Joe Six Pack ISP" at an exchange if - connection cost is very low (shared ethernet) - they don't peer with Joe's upstream at the same location - they only announce regional routes to Joe - they use hot potato routing everywhere in that case, the peering would just be local/regional, probably all that Joe is after anyway Mike.
RE: Sprint peering policy (fwd)
--- If they peer, the traffic ratio will _NOT_ be 1:1, more like 10:1 or 1:10 [depending on which way you are looking]. --- It will not be a 1:1 push pull ratio, BUT it will be 1:1 in a "expensive part of ISP1:expensive part of ISP2" ratio... --Phil
RE: Sprint peering policy
---
>
> I would venture to say that to WorldCom, all traffic is destined to a
> peer, or a customer, and they NEVER pay for traffic. Peering with them
> is entirely a courtesy from them to you, as they can always see you
> through their current peers.
Reduced latency? Shorter hop counts? ("Hello, this is customer xxx, why
does it take 27 hops for me to get to xyz.com?") Do these not benefit
them in any way?
---
Right, but Wcom peers with verio, bbn, sprint, att in just about every
major city, so they are going to have low latency anyway, "most of the
time".
---
> The fact that they failed, having had such extensive peering, proves
> that peering has no relation to financial difficulties (in my mind, at
> least)
I don't think "peering could not overcome corrupt financial officers and
$3B in debt" equates to "peering has no relation to financial
difficulties" exactly.
Here's a fun exercise: Drop your 5 busiest peers, and see if your
operating costs a) increase, b) decrease, or c) remain the same.
---
Apples and oranges. Wcom isn't talking about dropping AT&T as a peer,
they just don't want to peer with "Joe Six Pack ISP". Wcom would likely
not peer with most ISPs, and I wouldn't expect them to. They gain
absolutely nothing from it, and the small ISPs gain plenty. Wcom's
costs only increase since they need "more ports".
--Phil
RE: Sprint peering policy
Paul Vixie wrote: --- i completely understand that acquisition is a common and valid means to grow a business. however, with closed peering as a way of life for our industry, a lot of deals are done which only make money for the investment bankers and don't actually "grow business". closed peering is all about greed and not about service levels, competitive pricing, or overall sector health. closed peering is a bad business model. it shirks fiduciary duty to long-term equity holders in order to give periodic "quick hits" to short-term holders. closed peering proceeds from a Highlander-like premise "there can be only one" when in fact there could be many, and if there were many then the industry overall would be healthier. --- Agreed completely. BUT, your logic is very much "perfect world". There are a quite few reasons why this doesn't work "in the real world", same as communism works great in theory, but not in the real world. Eg: #1 Do you honestly believe that you wont run into any customers who will say "why should I buy from abovenet if I can peer with them? They will take a big percentage of my traffic and do it for free." *IF* you could have a setup where you could peer AND buy at the same time, then your model works better. #2 When something is being done for free, it is often not being done as well as if it were paid for, case in point: AboveNet's link to NY-IIX is 100mbit, right? The MRTG graphs seem to indicate that it is, AND that it was doing 90 megabit for several months straight. Shouldn't this have been upgraded to gig-e? Not cost effective? That being said, I like what above net does, and what they stand for, I just don't see how it can possibly make money. --Phil
RE: Sprint peering policy
I would venture to say that to WorldCom, all traffic is destined to a peer, or a customer, and they NEVER pay for traffic. Peering with them is entirely a courtesy from them to you, as they can always see you through their current peers. The fact that they failed, having had such extensive peering, proves that peering has no relation to financial difficulties (in my mind, at least) --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Daniel Golding Sent: Monday, July 01, 2002 1:27 PM To: Richard Irving Cc: Paul Vixie; [EMAIL PROTECTED] Subject: RE: Sprint peering policy 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. - Daniel Golding > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Richard Irving > Sent: Monday, July 01, 2002 1:15 PM > To: Daniel Golding > Cc: Paul Vixie; [EMAIL PROTECTED] > Subject: Re: Sprint peering policy > > > > Daniel Golding wrote: > > > > A vague sense of unfairness or unhappyness is the worst of reasons > > to regulate an industry. > > > > - Daniel Golding > > How about an industry being the origin of the 3 largest recorded > fraud/bankruptcies in American History ? >
RE: Sprint peering policy
But if you were hungrier, and they were the only place that had food, they *COULD* charge whatever they want, and you'd be willing to pay it, no? --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of David Schwartz Sent: Monday, July 01, 2002 12:45 PM To: [EMAIL PROTECTED]; Mike Leber Cc: [EMAIL PROTECTED] Subject: Re: Sprint peering policy On 29 Jun 2002 02:32:03 +, Vijay Gill wrote: > >Mike Leber <[EMAIL PROTECTED]> writes: > >>Sprint's peers aren't equal to Sprint or each other when considered by >>revenue, profitability, number of customers, or geographical coverage. > >A good proxy for the above is to ask the question: > >Do X and Y feel they derive equal value (for some value of equal) by >interconnecting with each other? > >If they think they do, then an interconnection is set up between X and >Y. However, if one party feels that they do NOT derive equal value by >interconnecting with the other, than that party usually balks. This doesn't make any sense at all. Why should X care how much value Y gets out of the deal at all?! This is like saying that Burger King should charge hungrier people more for a Whopper. DS
Paix-NY and NYIIX -- link stil going to happen?
Anyone know if the link-up is still going to happen? I've heard from a few people that given the financial issues at MFN, this is highly unlikely to still happen. Anyone know any different? Paul? --Phil
