Ask Your Question

netbios query in tracert capture

asked 2018-04-04 17:20:25 +0000

big-bite gravatar image

I have a 200 ms response to a tracert (Windows) query, which I need to understand. I ran a capture, and find multiple name queries (NBSTAT) before each group of pings.

I know the following:

NetBIOS over TCP is enabled

The source machine is on one domain, and the destination is on another

The source machine is on one subnet, and the destination is on another

I am using port mirroring on an HP enterprise switch, which is doing the routing

How do I figure out what is happening ?

edit retag flag offensive close merge delete


Hello big-bite

Don't know if this is still an issue.

To answer this question we need some information:

  • What operating system is the source system?
  • Do you specify the remote system by name or by IP address?

Assuming that you run tracert on a Windows system:

  • Do you use a WINS server? (probably not, check with ipconfig /all)
  • What NetBIOS node type is configured (probably H-node, check with ipconfig /all)
  • What is the name resolution policy?

Of course the most important question is: When do you migrate your legacy Windows hosts to a more recent operating system, that runs SMB2 (or better: SMB3).

Good luck

Eddi gravatar imageEddi ( 2018-04-19 18:55:16 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2018-04-22 11:48:13 +0000

Jim Young gravatar image

updated 2018-04-22 11:50:22 +0000

Without having your packet trace to look at, the presence of the NBSTAT queries may or may not be related to your use of the Window tracert command. You might see DNS name queries as well.

When using Window's tracert command try adding the /d option ("Do not resolve addresses to hostnames") to your tracert command and see if your "NBSTAT" queries go away.

The default behavior for Window's tracert is to try to resolve the source IP address of any ICMP packet received. Starting with an ip.ttl==1, three outbound ICMP echo packets will be sent. Assuming that the target machine is not on the same IPv4 network segment, the first hop router will typically reply with ICMP TTL exceeded in transmit responses. Windows will then to determine the hostname of the device that sent these responses. Then the next set of three ICMP echo packets are sent with the ip.ttl increased by one and again by default Windows will try to determine the hostname(s) of these second set of responses and so on.

On many *nix-like systems the traceroute command typically uses the -n option for the same purpose as Window's tracert /d option. The man page for the traceroute on one of my Redhat system defines the -n option as "Do not try to map IP addresses to host names when displaying them.". Similarly on one of my macOS systems the -n option is defined as "Print hop addresses numerically rather than symbolically and numerically (saves a nameserver address-to-name lookup for each gateway found on the path).".

Interestingly on one my Ubuntu systems with GNU's inetutils based traceroute installed does not do name lookups by default. Instead one has to supply the long option --resolve-hostnames to actually force GNU traceroute to attempt the ip address to hostname lookups.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2018-04-04 17:20:25 +0000

Seen: 917 times

Last updated: Apr 22 '18