February 2006 - Test - lists.nanog.org

Re: shim6 @ NANOG (forwarded note from John Payne)
by Iljitsch van Beijnum 08 Mar '06

08 Mar '06

[Crossposted to shim6 and NANOG lists, please don't make me regret this... Replies are probably best sent to just one list for people who don't subscribe to both.] On 27-feb-2006, at 22:13, Jason Schiller (schiller(a)uu.net) wrote: > Is it the consensus of the shim6 working group that the full suite > of TE > capabilities should not be a requirement? Or is this just the > opinion of > a few vocal people? I don't think I'm going out on a limb when I say that there is consensus that we need good enough traffic engineering from the start. (Where "start" means deployment, not necessarily the publication of the first RFC.) I think basic balancing of both incoming and outgoing traffic over the available links is both assumed to be part of what we need to have and implementable without too much trouble. Push back by transit ASes is harder. This is what I mean by that: A --- B / \ X Y \ / C --- D C's link to D may be low capacity or expensive, so D would prefer it if X would send traffic to Y over another route if possible. C can make this happen in BGP by prepending its AS one or more times so X will see the following AS paths: A B Y C C C D Y All else being equal, X will choose the path over A to reach Y. The simple answer here is that if the multihomed site receives a BGP feed just like today (except that it's a read only feed) and thus makes outgoing path selection decisions just like today, transit ASes have exactly the same tools as they have today. But presumably, if shim6 takes off many smaller sites that aren't comfortable with BGP will multihome also, so this push back won't work as well anymore. Creating a new way to accomplish this result is probably possible, but not entirely non-trivial, and probably something we wouldn't want to deliver on day one. Thoughts? Another capability that would be hard to replicate with shim6 is selective announcement. Today, many transit ASes allow multihomed sites to influence the way their prefix is propagated to neighbors of the transit AS. For instance, in the picture above X may decide that the link between C and D is of low quality, and set a community on the prefix it sends to C that tells C either that it should perform AS path prepending on X's prefix ONLY towards D and not towards other neighbors of C, or even not announce the prefix at all. We would need considerable extra mechanisms to replicate this capability, and maybe it can't even be fully replicated at all. So how critical is this capability?

46 200

Quarantine your infected users spreading malware
by Gadi Evron 02 Mar '06

02 Mar '06

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. It is becoming more and more obvious that the answer may not be at the ISP's doorstep, but the ISP's are indeed a critical part of the solution. What their eventual role in user safety will be I can only guess, but it is clear (to me) that this subject is going to become a lot "hotter" in coming years. Aunty Jane (like Dr. Alan Solomon (drsolly) likes to call your average user) is your biggest risk to the Internet today, and how to fix the user non of us have a good idea quite yet. Especially since it's not quite one as I put in an Heinlein quote below. 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? One of them has been around for a while, but just now begins to mature: Quarantining your users. Infected users quarantine may sound a bit harsh, but consider; if a user is indeed infected and does "spread the joy" on your network as well as others', and you could simply firewall him (or her) out of the world (VLAN, other solutions which may be far better) letting him (or her) go only to a web page explaining the problem to them, it's pretty nifty. As many of us know, handling such users on tech support is not very cost-effective to ISP's, as if a user makes a call the ISP already losses money on that user. Than again, paying abuse desk personnel just so that they can disconnect your users is losing money too. Which one would you prefer? Jose (Nazario) points to many interesting papers on the subject on his blog: http://www.wormblog.com/papers/ Is it the ISP's place to do this? Should the ISP do this? Does the ISP have a right to do this? If the ISP is nice enough to do it, and users know the ISP might. Why not? This (as well as port blocking) is more true for organizations other than ISP's, but if they are indeed user/broadband ISP's, I see this as both the effective and the ethical thing to do if the users are notified this might happen when they sign their contracts. Then all the "don't be the Internet's firewall" debate goes away. I respect the "don't be the Internet's firewall issue", not only for the sake of the cause but also because friends such as Steven Bellovin and other believe in them a lot more strongly than I do. Bigger issues such as the safety of the Internet exist now. That doesn't mean user rights are to be ignored, but certainly so shouldn't ours, especially if these are mostly unaffected? I believe both are good and necessary solutions, but every organization needs to choose what is best for it, rather than follow some pre-determined blueprint. What's good for one may be horrible for another. "You don't approve? Well too bad, we're in this for the species boys and girls. It's simple numbers, they have more and every day I have to make decisions that send hundreds of people, like you, to their deaths." -- Carl Jenkins, Starship Trooper, the movie. I don't think the second part of the quote is quite right (to say the least), but I felt bad leaving it out, it's Heinlein after all... anyone who claims he is a fascist though will have to deal with me. :) This isn't only about users, it's about the bad guys and how they out-number us, too. They have far better cooperation to boot. There are several such products around and they have been discussed here on NANOG before, but I haven't tried them myself as of yet, so I can't really recommend any of them. Can you? I'll update on these as I find out more on: http://blogs.securiteam.com This write-up can be found here: http://blogs.securiteam.com/index.php/archives/312 Gadi. -- http://blogs.securiteam.com/ "Out of the box is where I live". -- Cara "Starbuck" Thrace, Battlestar Galactica.

23 56

FYI - China To Launch Alternate Country Code Domains
by william(at)elan.net 01 Mar '06

01 Mar '06

---- From: Michael Geist <mgeist(a)pobox.com> Date: February 28, 2006 9:24:09 AM EST To: dave(a)farber.net Subject: China To Launch Alternate Country Code Domains Dave, China is preparing to launch what appears to be an alternate root. Starting tomorrow, they will establish four country-code domains. In addition to the current dot-cn, they will offer Chinese character versions of dot-China, dot-net, and dot-com. As one article puts it, this "means Internet users don't have to surf the Web via the servers under the management of the Internet Corporation for Assigned Names and Numbers (ICANN) of the United States." Coverage from China is at http://english.people.com.cn/200602/28/eng20060228_246712.html I've got some quick commentary at <http://michaelgeist.ca/component/option,com_content/task,view/id,1130/Itemi d,85/nsub,/> which includes: "The alternate root has always lurked in the background as a possibility that would force everyone to rethink their positions since it would enable a single country (or group of countries) to effectively pack up their bags and start a new game. The U.S. control would accordingly prove illusory since a new domain name system situated elsewhere would be subject to its own rules. While the two could theoretically co-exist by having ISPs simply recognize both roots, the system could "break" if both roots contained identical extensions. In other words, one root can have dot-com and other other can have dot-corp, but they can't both have dot-com. It is with that background in mind that people need to think about a press release issued yesterday in China announcing a revamping of its Internet domain name system. Starting tomorrow, China's Ministry of Information Industry plans to begin offering four country-code domains. In addition to the dot-cn country code domain, three new Chinese character domains are on the way: dot-China, dot-net, and dot-com. As the People's Daily Online notes this "means Internet users don't have to surf the Web via the servers under the management of the Internet Corporation for Assigned Names and Numbers (ICANN) of the United States." In other words, the Chinese Internet becomes a reality tomorrow. With it, the rules of the game may change as 110 million Internet users will suddenly have access to a competing dot-com (albeit in a different character set) and will no longer rely exclusively on ICANN for the resolution of Internet domain name queries. This change was probably inevitable regardless of the status of ICANN, however, the U.S. position can't possibly have helped matters. Indeed, some might note that while Congress has been criticizing U.S. companies for cooperating with Chinese law enforcement and thereby harming Internet freedoms, those same Congressional leaders may have done the same by refusing to even consider surrendering some control over the Internet root to the international community and thereby opening the door to an alternate root that could prove even worse from a freedom perspective. This week's announcement certainly doesn't mark the end of a global interoperable Internet. It does move one step further toward that path since in Internet governance terms, the credible threat is now real." MG --********************************************************************** Professor Michael A. Geist Canada Research Chair in Internet and E-commerce Law University of Ottawa, Faculty of Law 57 Louis Pasteur St., Ottawa, Ontario, K1N 6N5 Tel: 613-562-5800, x3319 Fax: 613-562-5124 mgeist(a)pobox.com http://www.michaelgeist.ca

7 6

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