This is probably an easy question but I don't see how this is happening and we don't have any outages or problems that I know of.
In one of our buildings (out of several) when we do a trace route from a switch (C3560-IPSERVICESK9-M) to any address, the internal devices that appear in the traceroute resolve to the same name:
Type escape sequence to abort.
Tracing the route to 22.214.171.124
1 www.quartics.com (10.37.24.2) 0 msec 0 msec 8 msec (ours)
2 www.quartics.com (10.37.23.4) 0 msec 0 msec 0 msec(ours)
3 www.quartics.com (10.37.123.1) 0 msec 0 msec 0 msec (ours)
4 126.96.36.199 8 msec 0 msec 0 msec
5 * * *
6 188.8.131.52 34 msec 8 msec 9 msec
7 * * *
8 * *
We do not have any entries in our DNS servers with www.quartics.com.
How do I debug this issue?
Your assistance would be greatly appreciated
I would agree that this output is strange. You ask how to debug this issue and I will offer these suggestions:
- what is configured on that switch for name server?
- is the name server configured for that switch the same or different from the name server for other network devices?
- what are the devices at 10.37.24.2) 10.37.23.4 and at 10.37.123.1?
- perhaps if you post the configuration of the switch we might find something?
Thank you for the additional information. I have looked through the config that you posted and do not see any configured name server on the switch. With no name server I am puzzled that there is any name resolution in the traceroute output. So this is one more strange thing in this situation. If you do traceroute to other external addresses does it do the same thing? If you do traceroute to internal addresses does it do the same kind of thing?
Yes it looks the same way for both internal and other extenal IP addresses.
Could this be caused by an unknown (to me) device?
It is interesting that it does it for both internal and external destinations. Perhaps the next step that I would suggest would be to do a packet capture on traffic sent by the switch. In the capture look especially for any request for DNS sent by the switch and if you see requests then look for who is sending responses.
Since I do not see how the switch could do this on its own then I would think that there must be some (currently unknown) device involved.
I will try that next, I won't be able to do this until Monday the 27th of November but I sure do appreciate your input on the issue.
I will post my pcaps on Monday.
Thanks again Richard
Hi Richard / Coco ,
I have some different opinion than you shared . Original poster has attached only the source switch which he has used in trace .... See below from the attachment . However if you see then first hop address will be the gateway which is being resolved always
ip default-gateway 10.37.24.2
I would suggest to have the device 10.37.24.2's configuration to be attached too for further diagnose .
It might be interesting to see the configuration from the gateway. But I have difficulty in understanding how anything on the gateway would influence the output of traceroute on the switch. As I understand the original post it is not a problem with what path is chosen (and for that the gateway is certainly a crucial part). The problem is that a name is in the output of traceroute and how does that name get there?
The traceroute packet goes out with a numerical IP address. The traceroute response comes back with a numerical IP address. There is no field in the traceroute for the gateway to insert a name. So I do not see any way for the name to get into the output except for something being done on the switch. If you can suggest some way that the gateway is affecting the format of output on the switch I would certainly be interested in hearing it.
Thanks, we are getting closer - Traceroute followed by a show hosts. Done from a different switch than the one at the beginning of the string. That particular switch has stopped showing the "www.quartics.com". Note, we
Type escape sequence to abort.
Tracing the route to www.quartics.com (184.108.40.206)
1 10.37.24.2 0 msec 0 msec 9 msec
2 www.quartics.com (10.37.24.4) 0 msec 0 msec 0 msec
3 www.quartics.com (10.37.123.1) 0 msec 8 msec 0 msec
4 www.quartics.com (220.127.116.11) 0 msec 9 msec 0 msec
5 * * *
6 www.quartics.com (18.104.22.168) 8 msec 9 msec 8 msec
7 * * *
Default domain is not set
Name/address lookup uses static mappings
Codes: u - unknown, e - expired, * - OK, ? - revalidate
t - temporary, p - permanent
Host Port Flags Age Type Address(es)
hadar.avaz.com None (temp, OK) 0 IP 10.119.23.1
www.quartics.com None (temp, OK) 0 IP 10.119.23.1
believe there could be some strange (misconfigured) device in your LAN sending rogue DNS requests/replies.
As one of your switches stopped showing the strange DNS names while another started?!
I'm not sure what is the DNS cache timer on the switches.
So it would be interesting to start capturing DNS traffic by Wireshark, I guess?
And possibly to reboot the switch to see if it gives the same output again?
I have looked at the router config that was posted and do not find anything in it that helps explain the strange DNS behavior. I agree with Milan that capturing traffic with something like Wireshark and looking for DNS traffic would be a good next step.
It is certainly interesting that the behavior stopped on the original switch and started on another switch. Is it possible to determine whether there have been any config changes or any device reboot on either of these switches?
I apologize for not getting back to you earlier
I should have a pcap later tonight. I have been doing a "no ip domain-lookup' on the switches just to remove the hosts from appearing on the traceroutes but I know the problem persists.
I have consulted again with our Facilities department and it appears that the users in this facility installed a couple of networked TVs that they failed to notify the IT department about, I'm trying to locate the IP addresses to see if they are causing any issues. The host www.quartics.com is a video processor company from what I have found out. They must have found active network jacks to connect them to.
Thanks for the update. It certainly sounds like this may be related to something that they installed as part of the networked TVs. The pcap may help to confirm this.