On Mon, 2011-02-07 at 18:19 +0100, Gert Doering wrote: > On Mon, Feb 07, 2011 at 03:16:30PM +0100, Peter Rathlev wrote: > > But we're also getting tired of people not able to > > interpret traceroutes, so we've thought about disabling it anyway. > > Part of our next bid for upstream connectivity will be "working > traceroute". > > We're getting tired of people blaiming our upstream link for > transatlantic delays (hidden by traceroute hiding in upstream > network), packet loss in upstream network, problems with the next-hop > ISP border routers, etc. > > Yes, we have our share of "customer not able to read traceroute", but > the pain of "being a customer, and not being able to *do* traceroute" > is much worse.
I would tend to agree if "the customer" is someone versed in networking. But for us (an enterprise-ish installation) the users are everything but experts in networking. We receive countless requests from e.g. medical equipments vendors, telling us that somethings's "wrong" with the network. We simply use too much time trying explaining how traceroute works. One might wish for selective TTL propagation, maybe using an access list of some kind. But since it has to be symmetric (AFAICT) it might not be easy at all. (I'm aware of the "local" exception when disable TTL propagation but it's not easy to script traceroutes through a PE. And scripted traceroutes is something we use heavily.) One of our last-mile providers recently disabled TTL propagation, and that has somewhat limited us when trouble shooting, so I do understand you point. -- Peter _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
