Alternatively, you could expect that the carrier might notice themself that there is a problem. Nah.... Forget I mentioned that. It'll never happen. --- John Fraizer EnterZone, Inc On Mon, 11 Dec 2000, Christopher L. Morrow wrote:

Alternately you could call the UUNET NOC at the number listed on this public page: http://www.us.uu.net/support/noc/

--Chris

####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-289-8479 (C)703-283-3734 ## #######################################################

On Mon, 11 Dec 2000, Randy Bush wrote:

...

...

Heya, I'm getting a huge jump in ping times from alter.net to Verio in what appears to be Sacramento:

horrifying that neither of these providers don't have nocs, eh? sheesh!

randy

nanog@EnterZone.Net said:

Alternatively, you could expect that the carrier might notice themself that there is a problem.

May be their NOCs did, (unless they were too busy reading NANOG of course). Without calling them it would be difficult to tell. Meanwhile the few of us on this list in neither NOC can pontificate about it which will no doubt be of great assistance to them in resolving the issue at hand. Sarcasm aside: If people posted 'Verio<->Sprint peering problems, Verio Ticket number nnnnn, Sprint ticket number nnnnn, apparent latency problems between west coast customers caused by peering congestion in Seattle' or whatever (not that I'm saying this is what the problem is here), this would no doubt be treated as an informative post (just like when Sean tells us about fiber cuts). If, on the other hand, nanog is used as an alternative to noc@ or your regular support channel, the s/n ratio here will get even worse. -- Alex Bligh VP Core Network, XO Communications - http://www.xo.com/ (formerly Nextlink Inc, Concentric Network Corporation GX Networks, Xara Networks)

We at SAVVIS run continous pings to every backbone router that we own. (John - this does not include our ATM switches, we have no way to monitor latency between them). But if, say, our connection to Sprint or UUNET let's say, is latent, we would get UUNet on the phone immediateley. (ph is 800-900-0241, for those that don't wanna look it up, choose the appropiate options. Unfortuantely the multi-meg option (read: no hold time and clueful people) is password protected and I am obviously not at liberty to give that out). At any rate, we do notice latency, and if it's persistent enough, we do something about it.... Obviously *not* speaking as a SAVVIS represenative..... Jon On Mon, 11 Dec 2000, John Fraizer wrote:

Alternatively, you could expect that the carrier might notice themself that there is a problem.

Nah.... Forget I mentioned that. It'll never happen.

--- John Fraizer EnterZone, Inc

On Mon, 11 Dec 2000, Christopher L. Morrow wrote:

...

Alternately you could call the UUNET NOC at the number listed on this public page: http://www.us.uu.net/support/noc/

--Chris

####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-289-8479 (C)703-283-3734 ## #######################################################

On Mon, 11 Dec 2000, Randy Bush wrote:

...

...

Heya, I'm getting a huge jump in ping times from alter.net to Verio in what appears to be Sacramento:

horrifying that neither of these providers don't have nocs, eh? sheesh!

randy

On Sat, 16 Dec 2000 nanog@rmrf.net wrote:

We at SAVVIS run continous pings to every backbone router that we own. (John - this does not include our ATM switches, we have no way to monitor latency between them). But if, say, our connection to Sprint or

Um, sure you do. You know your atm mesh and (hopefully) you have an IP address bound up on the switch itself so you can gather snmp statistics from the box. I realize that this might have been too obvious to have come up in discussions when proactive monitoring was being implemented on your net. If you know that from your monitoring station it's normally 6ms to switch X and switch Y lives (normally) 6ms behind switch X, it's simple to set up alarm profiles. if X > 6 alarm if Y > 12 alarm You get the general idea. We do this exact same thing in our nework and have dependencies set up as well. For example, switch monitoring is dependent on switch X not being in alarm so, if X is in alarm, don't alarm for Y also because our path to Y is through X. blah blah. Don't worry about the CBX-500 in CMH. You know we'll call if it has problems. <grin> --- John Fraizer EnterZone, Inc