I wonder by how much the problem could be reduced as such, if service providers (including campus service providers) would have accessible servers about network status information, being kept current by some local NOC. Such as outages, marginal operation, even planned outages (such as maintenange updates). May be I could send a query to a server at NOC.NERSC.GOV that may answer the question I have, without my having to pester humans. I for one would prefer that also compared to spontaneous email being sent around in case of outages. May be as an extension to the previously mentioned client/server model? Of course there are details of a query language (how to ask questions) and so...

In message <9503301600.AA01532@stick.NERSC.gov>, "Chris Dorsey (510)422-4474" w rites:

I agree with Matt, if a network turns off LSRR, then I try to hand them the ticket. However, it seems that lots of sites either yield no human response at all, or get back to you a few days later. Not very helpful in the face of intermittent problems. So you're the one holding the trouble ticket with no tools and no help.

I've thought a little about this over the past few months as more sites shut off LSRR, and it seems like a "ping" or "traceroute" server-client would really come in handy. No human interaction needed, I just request a ping/trace from site A going from A to B.

Has anyone explored this or is it a silly idea and I'm being dense.

/chris

Chris Dorsey ESnet dorsey@es.net

If LSRR is turned off somewhere, what I ussually do is the following Start in the middle of your network (anywhere in 140.222 in our case) and traceroute to both sites in question. For each direction: Try a traceroute -g from end site A to end site B (traceroute -g A B). If this never reaches end site A, presumably because LSRR is blocked, then back up to the last router that responded (call it R1). Then traceroute from R1 to B (traceroute -g R1 B). This will often end slightly before B (call this R2). What this usually yields is: /-->- hop hop hop -->-\ A ... R1 -<-- hop hop hop -<-- R2 ... B \ / \ / --- you are here -- This is OK as long as R1 and R2 are very close to the site. They are usually the provider router one hop from the firewall. There may be an assymetric route, with one side going off into the black hole (this is then the problem). There may be a symmetric or assymetric route with a loss problem. Since you now know the route, you can now try source routed ping and try to isolate the loss enough to know which NOC to notify. If the problem is loss between A and R1 or B and R2, then a regular ping should show the problem. The only case where this doesn't work is where the route from A to B or B to A doesn't go through R1 and/or R2. There is no way to know this for sure. I don't know of any IP providers that have turned off LSRR on their backbone routers, just site routers. Curtis