- NANOG - lists.nanog.org

RE: How do you (not how do I) calculate 95th percentile?
by Greenhagen, Robin 23 Feb '06

23 Feb '06

Database triggers are a marvelous thing. Is this wrong? ((InOctetsCurrent-InOctetsLastTime)*8) --------------------------------- (TimeCurrent-TimeLastTime) = Inbound bits/sec We chose this because it doesn't matter if it is 30 seconds or 8 minutes between sample points, it is all normalized in that period. I do realize that it is an average within that window, but all we need to do is tune the cron job (how often we poll) to increase resolution. ________________________________________ Robin

1 0

How do you (not how do I) calculate 95th percentile?
by Jo Rhett 22 Feb '06

22 Feb '06

I am wondering what other people are doing for 95th percentile calculations these days. Not how you gather the data, but how often you check the counter? Do you use averages or maximums over time periods to create the buckets used for the 95th percentile calculation? A lot of smaller folks check the counter every 5 min and use that same value for the 95th percentile. Most of us larger folks need to check more often to prevent 32bit counters from rolling over too often. Are you larger folks averaging the retrieved values over a larger period? Using the maximum within a larger period? Or just using your saved values? This is curiosity only. A few years ago we compared the same data and the answers varied wildly. It would appear from my latest check that it is becoming more standardized on 5-minute averages, so I'm asking here on Nanog as a reality check. Note: I have AboveNet, Savvis, Verio, etc calculations. I'm wondering if there are any other odd combinations out there. Reply to me offlist. If there is interest I'll summarize the results without identifying the source. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation

5 6

anybody here from verizon's e-mail department?
by Paul Vixie 22 Feb '06

22 Feb '06

last week i became unable to send mail to verizon users: Diagnostic-Code: X-Postfix; host relay.verizon.net[206.46.232.11] said: 550 You are not allowed to send mail:sv18pub.verizon.net (in reply to MAIL FROM command) (the above was from me trying to ask postmaster(a)verizon.net about it) i'd hate to think that i've simply sent too many why-are-you-spamming-me complaints and have been blacklisted.

9 12

MLPPP over MPLS
by Jon R. Kibler 22 Feb '06

22 Feb '06

Greetings all, Would anyone who has every done MLPPP over MPLS care to share their experiences with this type of network? We have a customer that is implementing an MPLS network that will have 2 to 6 T1 feeds at some locations that will be using MLPPP for channel bonding. This is a telco provided network that will be customer managed. The routers will be customer managed because the same equipment will have interfaces to another telco's network as a backup to the MPLS network. Needless to say, no telco will support equipment that interfaces competitors networks. The customer is being told by their router vendor that an MLPPP/MPLS network is 'too complex' to be managed by anyone except for the router vendor's VARs or the telco. They indicated that it would be impossible for the customer's router vendor certified network person to come up to speed on MLPPP/MPLS configurations and manage such a network -- that it takes years to adequately learn how to manage that type of network configuration. This doesn't sound like rocket science to me -- it should be simple and rather straight forward, I would think: The telco specifies its requirements for the router configuration, the customer implements that configuration on the required router interfaces, the telco monitors line quality, and the customer does basic router monitoring. Am I missing something here, or is the router vendor just blowing a lot of smoke to try to provide business for some of his clients that provide managed services? Thanks in advance for your feedback! Jon Kibler -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.

7 10

Re: a radical proposal (Re: protocols that don't meet the need...)
by Michael.Dillon＠btradianz.com 21 Feb '06

21 Feb '06

[[pushed the wrong button last time. This is the complete reply]] > - join a local IXP, which may be a physical switch or > virtualized by a set of bilateral agreements. Why should they join an IXP if they already have private peering arrangements? > - outside the region, they advertise the prefix of the > regional authority Mixing government with operations? If you favor doing that then why not just give IPv6 addresses to the various national governments and let the UN sort it out? Personally I disagree with any scheme which calls for national or municipal governments to assign IPv6 addresses to end users. Dressing it up as a "regional authority" does not make it any nicer. Forcing people to join an unecessary IX is not the way to solve the problem of regional aggregation of routes. This is a purely technical problem which can be solved by the RIR practices in allocating IPv6 addresses. If they would allocate addresses in a geo-topological manner then end users and ISPs would be free to aggregate routes outside of their region without any involvement of governments or any requirement to join consortia or IXes. It does require the users of such geo-topological addresses to ensure that in THEIR region, there is sufficient interconnectivity (physical and policy) between ISPs for the addressing to work. But that does not need to be determined or managed centrally. Geo-topological addressing refers to RIRs reserving large blocks of designated addresses for areas served my large cities (over 100,000) population. When end users are located in fringe areas roughly equidistant between two or more such centers, the RIR simply asks the end user (or ISP) which is the center to which they want to connect (communicate). This addressing scheme operates in parallel with the existing provider-oriented IPv6 addressing scheme but uses a different block of IPv6 addresses out of the 7/8ths that are currently reserved. No hardware or software changes are required for this to work, merely some geographical/economical research to determine the relative sizes of the address pool to be reserved for each of the world's 5000 largest cities. > Whenever I have talked about the model with an ISP, I have gotten > blasted. Basically, I have been told that > > (1) any idea on operations proposed in the IETF is a bad idea because > the IETF doesn't listen to operators This is true. Top-down does not work in Internet operations. We need bottom-up, i.e. customer demand. The IETF needs to view their role as enablers of customer demand. If the IETF can create something that will work for ISP customers, then ISPs will be happy to go along, once the customers demand the service. > (2) the ISPs aren't going to be willing to make settlement payments > among themselves in accordance with the plan Wait until this starts appearing as a requirement in custome RFPs. > I'm not sure how to proceed, given the level of invective I get in > any discussion with anyone on the topic. Perhaps the IETF needs to seek input, not just from ISPs, but also from ISP customers, the end users of the network. > Note 2: Provider-provisioned addresses continue to make sense for > folks that don't plan to multihome. Indeed they do. But the current IPv6 addressing model is completely slanted towards provider-provisioned addresses for single-homed entities. Calling a small block of these provider-provisioned addresses PI (provider independent) does not really make the addresses provider independent and does not help small enterprises to implement meaningful multihoming. The IETF has imposed this provider-provisioned model on IPv4 and is thus directly responsible for the ISP cartel which now exists. --Michael Dillon

4 4

Re: Quarantine your infected users spreading malware
by Scott Weeks 21 Feb '06

21 Feb '06

----- Original Message Follows ----- From: Michael.Dillon(a)btradianz.com > > Oh geez, here we go again... Search the archives and > > read until you're content. It's a non-thread. This > > horse isn't only dead, it's not even a grease spot on > the road any more. > > Are you saying that the problem of spreading worms > and botnets is fading? Where do you get your data on > this? > > I mean, it's all well and good to express an opinion > but if you want to be believed you have to be prepared > to back it up with data from another source. I'm not saying that at all and that'd be the silliest position to support anyway. We all know better than that. All I was saying is *every* position on the subject was expressed about two months ago in the thread that wouldn't die even in the clear evidence of an exponential decrease in quality of responses on the subject and I don't things have changed significantly since then. No biggie, I can delete when the quality of respones degrades below my threshold of ability to carry on reading... :-) scott

1 0

Maximun effective range of an excuse is... [Was: Re: Quarantine your i nfected users spreading malware]
by Fergie 21 Feb '06

21 Feb '06

QED: AT&T/SBC also does this for their DSL subscribers... - ferg -- Larry Smith <lesmith(a)ecsis.net> wrote: The problem with discussing AOL and "large provider" in the same sentence is that the complete AOL (connection, desktop, tools, etc) function are AOL controlled (walled garden) so they have the capability of doing much more in that arena that other providers. [snip] -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: Quarantine your infected users spreading malware
by Scott Weeks 21 Feb '06

21 Feb '06

----- Original Message Follows ----- From: Gadi Evron <ge(a)linuxbox.org> > Many ISP's who do care about issues such as worms, > infected users "spreading the love", etc. simply do not > have the man-power to handle all their infected users' > population. > Some who are user/broadband ISP's (not say, tier-1 and > tier-2's who would be against it: "don't be the > Internet's Firewall") are blocking ports such as 139 and > 445 for a long time now, successfully preventing many of > their users from becoming infected. This is also an > excellent first step for responding to relevant outbreaks > and halting their progress. > > Philosophy aside, it works. It stops infections. Period. > > Back to the philosophy, there are some other solutions as > well. Plus, should this even be done? Oh geez, here we go again... Search the archives and read until you're content. It's a non-thread. This horse isn't only dead, it's not even a grease spot on the road any more. :-( scott

15 28

Subject: drone armies C&C report - February/2006
by c2report＠isotf.org 21 Feb '06

21 Feb '06

Below is an automatically generated periodic public report from the ISOTF's affiliated group "DA" ("Drone Armies (botnets) research and mitigation mailing list" / TISF DA) with the ISOTF affiliated ASreport project (TISF / RatOut). For this report it should be noted that we base our analysis on the data we have accumulated from various sources, which may be incomplete. Any responsible party that wishes to receive reports of botnet command and control servers on their network(s) regularly and directly, feel free to contact us. In the past few months we did not publish this report, allowing for responsible parties to ask for regular reports from us on suspected botnet C&C activity on their networks. As you can see below, the Internet drastically changed its face positively because these reports (compared to when we started), and now a lot more so due to direct reporting. For purposes of this report we use the following terms: open the host completed the TCP handshake closed No activity detected reset issued a RST This month's survey is of 4271 unique domain with port or IP with port suspect C&Cs. This list is extracted from the BBL which currently has a historical base of 7780 reported C&Cs. Of the suspect C&Cs surveyed, 685 reported as Open, 3353 reported as closed and 572 issued resets to the survey instrument. Of the C&Cs listed by domain name, 1847 are mitigated via remapping. Top 20 ASNes by Total suspect domains mapping to a host in the ASN. These numbers are determined by counting the number of domains which resolve to a host in the ASN. We do not remove duplicates and some of the ASNs reported have many domains mapping to a single IP. Note the Percent_resolved figure is calculated using only the Total and Open counts and does not represent a mitigation effectiveness metric. ASN Responsible Party Total Open Percent_Resolved 14744 PNAP Internap Network Services 91 0 100% 10913 PNAP Internap Network Services 67 0 100% 30058 FDCSE FDCservers.net LLC 65 18 72% 25761 STAMIN-2 Staminus Communications 58 6 90% 3356 Level 3 Communications, LLC 53 0 100% 13301 UNITEDCOLO-AS Autonomous System of 52 35 33% 14779 INKT Inktomi Corporation 42 0 100% 21844 THE PLANET 41 2 95% 19318 AIC-81 Albany International Corp. 40 11 73% 13749 EVRY Everyones Internet 37 5 86% 4766 KIXS-AS-KR 35 2 94% 30315 Everyones Internet 31 12 61% 12182 PNAP Internap Network Services 31 0 100% 9318 HANARO-AS 30 9 70% 21840 SAGONE Sago Networks 30 5 83% 13790 PNAP Internap Network Services 30 0 100% 22822 LLNW Limelight Networks 29 10 66% 27595 ATRIV Atrivo 27 5 81% 12832 Lycos Europe 26 3 88% 3561 Savvis 24 1 96% Top 20 ASNes by number of active suspect C&Cs. These counts are determined by the number of suspect domains or IPs located within the ASN completed a connection request. ASN Responsible Party Total Open Percent_Resolved 13301 UNITEDCOLO-AS Autonomous System of 52 35 33% 32748 NOZON NoZone 21 20 5% 30058 FDCSE FDCservers.net LLC 65 18 72% 174 Cogent Communications 20 16 20% 25700 SWIFTDESK VENTURE 19 13 32% 30315 Everyones Internet 31 12 61% 4134 CHINANET-BACKBONE 17 12 29% 19318 AIC-81 Albany International Corp. 40 11 73% 9121 TTNet 15 11 27% 22822 LLNW Limelight Networks 29 10 66% 8972 INTERGENIA-ASN intergenia autonomou 21 10 52% 15083 IIS-129 Infolink Information Servic 24 9 63% 30407 Velcom.com 12 9 25% 9318 HANARO-AS 30 9 70% 20115 Charter Communications 20 9 55% 23522 CIT-FOONET 14 9 36% 16265 LEASEWEB AS 15 9 40% 3269 TELECOM ITALIA 16 8 50% 8560 SCHLUND-AS 19 7 63% 19166 Alpha Red, INC 14 7 50% 33569 ALLHOSTSHOP.COM 16 6 63%

1 0

Re: Quarantine your infected users spreading malware
by Scott Weeks 20 Feb '06

20 Feb '06

> > Oh geez, here we go again... Search the archives and > > read until you're content. It's a non-thread. This > > horse isn't only dead, it's not even a grease spot on > > the road any more. :-( > > I quite agree, which is why I trived to cover the > philosophical part from both sides. Now, how about some > solutions that came about since our last discussion that > was nothing BUT philosophy? You can't get there from here. scott

2 1