What is the "mystery" router between dllstxt3 and dllstx5 that doesn't respond to icmp when doing a trace?

6 120 ms 119 ms 110 ms te9-1.dsr01.dllstx3.theplanet.com [70.87.253.6]
7 * * * Request timed out.
8 129 ms 122 ms 132 ms po1.car06.dllstx5.theplanet.com [70.87.254.42]

That would likely be dsr01.dllstx5 or dsr02.dllstx5 depending on which way the Internet-wind blows.

Is there an advantage to or reason for it not responding / giving the "result timed out" line in a traceroute?

I'd have to ask around some of the senior network people to see if it was by design or not. The DSRs seems to be passing traffic on all interfaces without any issues.

I'm sure you're all normally busy with much more important things, but if there's ever an hour when someone is stilling around wishing for something extra to do, I would be curious to know why it's "non responsive" in the traceroute.

If it's by design, what is the advantage or reason.

If not by design, does it suggest a near capacity router or something?

Not a big deal since it doesn't seem to affect function, but just the same if a customer does a traceroute to their site I think it looks slightly "un-pretty" to have a *** router within the datacenter network unless there's a reason for it.

I guess you know you have a solid network when customers start to nitpick the aesthetics of a traceroute

Similar scenero from outside the network to DLLSTX6.

12 58 ms 61 ms 59 ms te7-2.dsr01.dllstx3.theplanet.com [70.87.253.10
13 * * * Request timed out.
14 61 ms 61 ms 61 ms po1.car03.dllstx6.theplanet.com [70.87.254.154]

It can only make them better...lol.