|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Network for Sale
I believe the "NAP Detection" algorithms are proprietary (I'll have to check with our VP of Software Devel to be sure). I do know for sure, however, that we do not just use a static table. Regardless of the architecture of a NAP (or any of the connections therein), the act of traffic simply going through a NAP does not always mean that's a bad route. Many (most) of the NAPs are overloaded, sure, but what really matters is latency, packet loss, etc... If a NAP route has the highest performance (hey, it's possible :) then it's a good route. Many times this may not be the case, but it's possible. ~Jay On Tue, 20 Feb 2001, Daniel L. Golding wrote: > > Hmmm. > > How do you figure out when you have crossed a NAP? Hard-coded table of > exchange point IP blocks? That will work for the larger NAPs, but wouldn't > necesarily detect passing over a peering switch in a PAIX or Equinix > facility (unless they are all in your table...) Munging reverse DNS? :) > > Of course, treating all NAPs the same is tricky business. FDDI, ATM, Gig > Ethernet, etc, are far different animals. Most of the conventional wisdom > surrounding public peering came to light during the heyday of the FDDI > NAPs. > > Daniel Golding NetRail,Inc. > "Better to light a candle than to curse the darkness" > > On Mon, 19 Feb 2001, Jay wrote: > > > > > On Mon, 19 Feb 2001, Troy Corbin wrote: > > > > > late-nite call to the Opnix NOClet on duty to find out why a certain > > > netblock was unable to connect to the Opnix webserver(s) received the > > > response "Are you a customer? I dont recognize your voice..." How does > > > > > > I've never heard of that one. Likewise, that's a crappy response. I'll > > forward this to our NOC Manager and CTO. Nobody's perfect, but the reply > > you got is totally unacceptable. I can assure you we don't handle calls > > based on voice recognition. :) > > > > > > > On a semi-technical front, what are you using to monitor RTT and how do > > > > > > All of our tools/systems/protocols/etc... are proprietary, but just from > > the RTT perspective, traceroute or ping can give you a very basic RTT > > measurement. > > > > Speaking of tools, we're releasing an open source utility called "OpRoute" > > at the end of this month. The tool works something like traceroute, but it > > also reports # of NAPs, AS hops, layer 3 hops, latency, packet loss, > > etc... It also gives you the option to show a side-by-side compariason of > > those statistics (from "a" to "z") on your network versus another outside > > network. > > > > Anyway, this is coming out (with source code) at the end of the month -- > > if interested, I'll post a notice to this list when its released. > > > > > > > you switch to new paths when you see that a current path is > > > congested/latent/etc? How do you adapt to changes without thrashing, and > > > how do you handle multi-homed customers, particularily those that are > > > > > > "Thrashing" routes is a concern. We have to throttle-back our > > optimizations and have put in some algorithms for dealing with this. The > > actual process of changing the route we do with proprietary protocols > > in-house. > > > > As for multihomed customers, that gets me into a whole new area... I don't > > know if this list would care to hear the entire bit, so I'll just hit the > > basics. If anyone wants more information, just email me off-list. Anyway, > > our current product (bandwidth) is being augmented by a new product > > (called IRIS) that goes into beta in April. IRIS is basically a > > client-side version of the routing intelligence technologies which > > interoperates with our core. IRIS is specifically for diverse networks > > (multihomed or otherwise) -- no matter if they're using the Opnix > > bandwidth product or not. > > > > > > > multihomed to multiple Opnix PNAPS^H^H^H^(oops, wrong marketing hype > > > engine enabled)POPS? > > > > > > Heh, you can never keep the marketing department under control. :) > > > > ~Jay > > > > > > > > > > > -troy > > > > > > On Mon, 19 Feb 2001, Jay wrote: > > > > > > > > > > > On Mon, 19 Feb 2001, Majdi S. Abbas wrote: > > > > > > > > > Particularly amusing is: > > > > > > > > > > http://www.opnix.net/whatwedo/performance.shtml > > > > > > > > > > > > If you have any questions about our route intelligence technologies (the > > > > above link talks about that a bit) or how it relates-to / > > > > interoperates-with BGP4, please feel free to ask me. I'd be happy to > > > > answer any questions. :) > > > > > > > > > > > > > > > > > > --msa > > > > > > > > > > > > > -- > > > > ~Jay > > > > > > > > .. .. > > > > .. Jay Jacobson Chief Executive Officer .. > > > > .. Opnix, Inc. http://opnix.com .. > > > > .. .. > > > > .. Innovating Internet Intelligence .. > > > > .. .. > > > > > > > > > > > > > > > > > > > > > > > > > -- > > ~Jay > > > > .. .. > > .. Jay Jacobson Chief Executive Officer .. > > .. Opnix, Inc. http://opnix.com .. > > .. .. > > .. Innovating Internet Intelligence .. > > .. .. > > > > > > > > -- ~Jay .. .. .. Jay Jacobson Chief Executive Officer .. .. Opnix, Inc. http://opnix.com .. .. .. .. Innovating Internet Intelligence .. .. ..
|