- Test - lists.nanog.org

SUMMARY - 95th percentile calculation
by Jo Rhett 28 Feb '06

28 Feb '06

My thesis that I wanted to prove or disprove was that the market seems to have standardized how they calculate 95th percentile. Years ago if you asked all your uplinks you'd get wildly different answers. Averages or max values over days, weeks or months. Rarely would two answers jive. But it appeared that most providers are now using 5 minute averages as the value input over a billing month for 95th% calculation. Was this truly standard now? The answer is yes. All of our paid transit links use 5 minute averages, and all but one of the replies to my query here did too. 8 providers use 5 minute averages of 30 second counter checks as the base value calculated over the billing month. 2 providers use 5 minute averages of 1 minute counter checks as the base value calculated over the billing month. 8 providers use 5 minute implicit averages (a single counter check) as the base value calculated over the billing month.* 1 provider uses the maximum value found in 5 minutes of 1 minute counter checks for the 5 minute value, and calculates that over the billing month. 1 provider uses 5 minute implicit averages (a single counter check) but calculates that over a fixed 30 day month. (I didn't ask what they did with the extra days) At first glance my tendancy would be to say that 20 answers is hardly authoritative, but the 30 second counters (first listed) comprise 6 of the top US bit movers, and 2 of the largest bit pushers so I'm satisfied with the results for my purposes. * One very large bit mover that I know uses 32 bit counters claimed to only be checking every 5 minutes. We're pushing enough to them to rotate that counter in that interval, so I actually disbelieve this answer but I'm reporting it as they said it. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation

3 2

Re: AOL Megaproxies?
by Nathan March 28 Feb '06

28 Feb '06

Did that and it seemed like they weren't proxying unknown traffic but one test isn't really a good indication of how their entire system works. Hoping to get a response from someone who actually knows their network. :) - Nathan Bill Nash wrote: > > Nothing digging an AOL cd out of the trash wouldn't fix. =) I have a > friend that works there, but he's unresponsive at the moment. > > - billn > > On Mon, 27 Feb 2006, Nathan March wrote: > >> Is anyone on this list familiar with the AOL "megaproxies"? >> >> I'm trying to find out if they only proxy HTTP/HTTPS traffic or if >> it's all TCP connections. I'm working on setting up load balancers >> for a client application and need to know if I can expect users to >> keep coming from the same IP for the most part. >> >> Normally I'd think that they only proxy web connections, but some >> links say otherwise: >> >> http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_qanda_item09… >> - Refers to TCP connections as a general topic, not just http/s. >> >> http://technet2.microsoft.com/WindowsServer/en/Library/bf3a1c95-f960-4ed3-b… >> >> - Refers to the AOL proxies with "all TCP connections" >> >> Anyone have any experience with AOL in this regard? >> >> Thanks, >> Nathan >> >

1 0

AOL Megaproxies?
by Nathan March 27 Feb '06

27 Feb '06

Is anyone on this list familiar with the AOL "megaproxies"? I'm trying to find out if they only proxy HTTP/HTTPS traffic or if it's all TCP connections. I'm working on setting up load balancers for a client application and need to know if I can expect users to keep coming from the same IP for the most part. Normally I'd think that they only proxy web connections, but some links say otherwise: http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_qanda_item09… - Refers to TCP connections as a general topic, not just http/s. http://technet2.microsoft.com/WindowsServer/en/Library/bf3a1c95-f960-4ed3-b… - Refers to the AOL proxies with "all TCP connections" Anyone have any experience with AOL in this regard? Thanks, Nathan

1 0

95th percentile - the sociology study.
by Jo Rhett 27 Feb '06

27 Feb '06

I didn't realize when I asked for how people handled a mathematical function for billing purposes, that the results would be more interesting to a socialogist than a network provider. I figured How do you (not how do I)... would be pretty specific, but apparently I underestimated the interesting ways that would be misread. 7 people wrote me with exactly the answers to the questions I asked. Nice. 7 people wrote to tell me how to calculate 95th percentile, but didn't include answers to any of the questions I asked. * On reply/request 5 of them did eventually answer the questions 4 people wrote to tell me how to calculate 95th percentile, but did remember to answer the questions I asked. 2 people wrote to tell me I was doing it wrong, and that I didn't understand what 95th percentile was. * Both of them eventually admitted that they don't work in a place which calculates 95th percentile for their customers. The remainder of my 20 samples were offlist queries/conversations with other providers. Some rough statistics from an admittedly small sample: 1/3 of the nanog repliers understood the question and knew how to answer it. Hmmm. Nanog clue level is definitely improving. All but three of the people who tried to teach me how to calculate 95th percentile were polite and clueful when I reminded them that I wanted the math, not a tutorial. A couple of misunderstanding actually wandered off into statistical analysis ramblings which was an amusing offset to the next set. Only three of the people insisted on telling me I was doing it wrong (never posted how we were doing it in the first place, so this was amusing) and tried to clue by four me into their approach. 2 did the math wrong in their long rants sent back to me ;-) 1 tried to convince me that modern equipment can't handle being sampled more often than every 5 minutes. And all three that tried to argue with me showed in their analysis that they don't deal with anything approaching 100Mb peering, nevermind 1g or 10g. And for those of you who can count, yes, one of the people who tried to teach me how to calculate 95th percentile didn't respond back either positively or negatively when I tried to remind him of the questions asked, and one was rude. (I don't blame him, after the 10th or so reply I was too) For statistical analysis: 2 women responded. Unfortunately one of them disagreed with a male counterpart from the same company and when I asked them to clarify it turns out the guy was right. (the girl's math was excellent, but based on an incorrect assumption. stereotype reversal in action) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation

2 2

Transit LAN vs. Individual LANs
by Scott Weeks 27 Feb '06

27 Feb '06

I have 2 core routers (CR) and 3 access routers (AR) currently connected point-to-point where each AR connects to each CR for a total of 6 ckts. Now someone has decided to connect them with Gig-E. I was wondering about the benefits or disadvantages of keeping the ckts each in their own individual LANs or tying them all into one VLAN for a "Transit LAN" as those folks that decided on going to Gig-E aren't doing any logical network architecting (is that a real word?). Anyone got any suggestions, comments or helpful hints? Thanks, scott

12 15

Re: Transit LAN vs. Individual LANs
by Scott Weeks 27 Feb '06

27 Feb '06

----- Original Message Follows ----- From: "Stephen Sprunk" <stephen(a)sprunk.org> To: "Patrick W. Gilmore" <patrick(a)ianai.net> Cc: "North American Noise and Off-topic Gripes" <nanog(a)merit.edu> Subject: Re: Transit LAN vs. Individual LANs Date: Sat, 25 Feb 2006 13:56:37 -0600 > Thus spake "Patrick W. Gilmore" <patrick(a)ianai.net> > > On Feb 24, 2006, at 9:03 PM, Scott Weeks wrote: > >> I have 2 core routers (CR) and 3 access routers (AR) > >> currently connected point-to-point where each AR > connects to >> each CR for a total of 6 ckts. Now someone > has decided to >> connect them with Gig-E. I was > wondering about the benefits >> or disadvantages of > keeping the ckts each in their own >> individual LANs or > tying them all into one VLAN for a >> "Transit LAN" as > those folks that decided on going to Gig-E >> aren't doing > any logical network architecting (is that a >> real > word?). > > > Personally, I like the to KISS, so one big 'transit > LAN'. > > ITYM two big transit LANs -- one must be prepared for a > switch to fail. These're going to be router-to-router connections (each AR is connected to both CRs) and I had thought about tying them all into one VLAN vs. PTP Gig-E. I was just trying to find out the operational benefits of either design. scott

2 1

Re: Transit LAN vs. Individual LANs
by Scott Weeks 27 Feb '06

27 Feb '06

> --On February 25, 2006 11:04:12 AM -0500 "Patrick W. > Gilmore" <patrick(a)ianai.net> wrote: > > On Feb 24, 2006, at 9:03 PM, Scott Weeks wrote: > > > >> I have 2 core routers (CR) and 3 access routers (AR) > >> currently connected point-to-point where each AR > connects to >> each CR for a total of 6 ckts. Now someone > has decided to >> connect them with Gig-E. I was > wondering about the benefits >> or disadvantages of > keeping the ckts each in their own >> individual LANs or > tying them all into one VLAN for a >> "Transit LAN" as > those folks that decided on going to Gig-E >> aren't doing > any logical network architecting (is that a >> real > word?). > > In my experience either solution has tradeoffs and the > correct one depends greatly on your traffic patterns. > Having said that, what I find causes most of the problems > in either solution is when the Layer 3 topology starts to > diverge from the Layer 2 topology. Hi Guys, Apologies for the late response, I had to do an unexpected outer island trip and got back late last night. I am just using OSPF area zero between the CRs and ARs. So, it's full mesh over a LAN if I do the "transit LAN". Is that what you're referring to? Could you elaborate? Thanks, scott

1 0

Re: DNS deluge for x.p.ctrc.cc
by Barrett Lyon 27 Feb '06

27 Feb '06

I thought I would chime in quickly, one of my customers has been one of the targets of this attack. The x.p.ctrc.cc DNS server was shut down on the 15th, the response itself had a 360000 TTL so that should be expired by now. On this end of it, the largest traffic spike we received was around 8 Gbps. The last time we saw this traffic was on the 21st around 2 GMT with traffic at about 2 Gbps, it has lost a lot of steam. If you see unusual DNS traffic to AS32787 or 72.52.0.0/18, chances are it is part of this attack or the attacker setup a new RR to query against. I've yet to see a copy of the malware that is doing the spoofed queries itself. If anyone has it, I would like to take a look. Thanks and I am really impressed with everyone's reaction to this attack. Especially Rob Thomas, he really has a grip on it. Cheers, -Barrett

2 1

Re: DNS deluge for x.p.ctrc.cc
by Rob Thomas 27 Feb '06

27 Feb '06

Hi, NANOGers. ] other cctld servers have seen what are effectively ddos. rob thomas ] seems to have the most clue on this, so i hope this troll will entice ] him to speak. Did someone say "troll?" :) Yes, this is a real problem. These attacks have exceeded several gigabits per second in size, and during one attack 122K DNS name servers were abused as amplifiers. Ouch! This abuse can be mitigated. Here are a few tips. Limit recursion to trusted netblocks and customers. Do not permit your name servers to provide recursion for the world. If you do, you will contribute to one of these attacks. Watch for queries to your name servers that ask for "ANY" related to a DNS RR outside of the zones for which you are authoritative. This DNS RR will be LARGE. Limit UDP queries to 512 bytes. This greatly decreases the amplification affect, though it doesn't stop it. Scan your IP space for name servers that permit recursive queries. It's amazing just how many of these name servers exist. Refer to the following guides for some excellent insight and suggestions. <http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf> <http://cc.uoregon.edu/cnews/winter2006/recursive.htm> <http://dns.measurement-factory.com/surveys/sum1.html> Note we have our own Secure BIND Template which will help on the BIND side of life. <http://www.cymru.com/Documents/secure-bind-template.html> If you need assistance with any of this, have endured one of these attacks, or have any other questions, please don't hesitate to ping on us at team-cymru(a)cymru.com. We're here to assist! Thanks! Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);

13 17

Re: DNS deluge for x.p.ctrc.cc
by Paul Vixie 27 Feb '06

27 Feb '06

i'd writ: # > speaking of which, f-root has about 35 nodes world wide, and about a third # > to a half of them aren't reachable by udp/161, and the blockage is not in # > our immediate neighbors but rather on transit paths. this is due to the # > cisco snmp vulnerability five years or so ago. filtering in the core to # > protect vulnerable edges has to be done a LOT more carefully than that. # > (BCP38 is an example of how to do it well, but apparently impractically?) someone followed up anonymously: # Filtering UDP/161 and TCP/161 directed towards -one's own infrastructure- is # a BCP, irrespective of SNMP vulns, etc. It should of course be allowed to # transit for folks who insist on doing SNMP across 'the Internet', but in # reality, one ought not to be allowing this at all. A lot of folks didn't # understand or didn't take the time to incorporate this into organized iACL, # and so ended up blocking it for transit traffic, as well, unfortunately. "yum." (folks who control backbone router meshes without fully understanding the impact of changes they make or time to fully digest and incorporate BCPs.) # Yes, filtering ports is a losing proposition (how long until all 64K of TCP # and UDP are filtered, heh?), but in this case, there's a practical reason to # do so, at least for traffic ingressing towards one's own devices. i just don't agree that filtering ports on internal infrastructure access buys anything. the boyz who run ISC's network filter by source-IP. that means if somebody needs to SSH to one of our routers they have to be coming from some fairly nearby/trusted place. i believe this is also what UUNET does, and it's what we were doing at MFN as of the time i left. i thought THAT was a BCP? after all, the combination of not letting outsiders spoof your internal IP range, and not letting your customers spoof IP ranges not assigned to them, ought to make IP ACL's containing internal source addresses fairly dependable?

1 0