ARP_RARP Broadcasts

[rknapp]

I have been monitoring our ethernetwork the last couple of days using MS Netmon.exe. We are running Win2K servers in an AD forest/single domain, DNS (of course), using Cisco switches. We run 5 VLANs. I see a LOT of ARP_RARP broadcasts with source/target IP addresses for machines that do exist on our network and which ARE accurately registered in DNS, forward and backward, if you know what I mean.

I am not a certified network technician, but I would expect that DNS should provide name resolution and preclude the need for our machines to broadcast to resolve names. Reducing broadcasts is an honorable goal, right? So why doesn't DNS reduce the need for ARP_RARP broadcasts? Perhaps a primer on DNS name resolution is in my future...

[irisrios]

You can reduce the broadcasts from a known source using the arp timeout command. But since you say, that the broadcasts are from machines that are not existing, then I feel, these broadcasts are spoofed up ones. This could be also due to old entries in the DNS cache. You can flush all the entries in the DNS cache once and then populate it again automatically.

This should solve the problem.

[rknapp]

Thanks for the reponse...I will flush those entries and try it again. Also, I will look at the ARP timeout command.

[badamson]

Forgive me if I am misunderstanding your question here but it sounds like you are talking about two different things.

1. DNS provides name to IP address resolution and, provided the reverse zones are configured, IP address to DNS name resolution.

2. ARP provides IP address to mac address resolution and RARP the opposite.

Both of these mechanisms are necessary and having one working does not eliminate the need for the other. Based on what I am reading into your post, it sounds like all is working as it should.

Bob

[rknapp]

Well, that is right. You are saying that an ARP_RARP broadcast is not an indication that DNS resolutions are not working. Rather, it is the second step to resolution. First, DNS provides the IP address of the machine, and then an ARP_RARP broadcast is necessary to find the MAC address, if the source machine's ARP cache doesn't already hold it. I do believe, however, that increasing ARP cache life should help reduce ARP_RARP broadcasts? Given that it is a good thing to reduce broadcasts, why would we not increase TTL in the ARP cache to a huge number? Overhead? Thanks for your clarification. You are right. I was confusing ARP_RAPR broadcasts with name resolutions, and that is not what is happening at all. Russ.

[badamson]

Well, reducing broadcasts is a good thing but broadcasts are also necessary so I wouldn't necessarily pursue this unless you are compensating for a poor network design. A broadcast domain should be kept to a reasonable size, I normally use a Class C network as a good rule of thumb. If you get larger than this (254 host addresses in a single broadcast domain) then you start to run the risk of the volume of broadcasts starting to degrade the performance of the devices on the network especially if you are running "chatty" protocols like IPX. This is not an absolute but it is a relatively safe place to start.

As for why you shouldn't increase the arp cache timers, I can give you an example. Take a laptop user, right now they are on network A. Later they move to network B when they go to a meeting. The cached entries are no longer valid because they have moved to a different broadcast domain. So, ideally these entries should be timing out after the resource no longer needs to be contacted.

Bob

[rknapp]

HUA! You're saying that, generally, the defaults for ARP cache timers are OK. I have heard a "no more than 20% of traffic should be broadcasts" rule-of-thumb, too. I was able to track down some devices configured with IPX/SPX using SAP broadcasts...removed the IPX/SPX protocols from those devices, as we are 100% TCP/IP. Right now, I am working on workstations that think they need to be master browsers. I am telling them not even to ask, and those broadcasts should go away. I think indifferent configurations are a sign of bad network design, or at least bad network implementation. I have inherited this network and will clean it up as best I can. Sweat the details and the other stuff often falls into place. Thanks for your input, Bob. R.