IS it too much ARP?

Hi all,
This is my first post, so if I am asking something too simple/stupid , bear with me.
I have a always on Internet connection, where my ISP provides it by putting a NIC and giving a class B (private) IP. so basically he makes u a part of the LAN which he routes to internet through couple of public IPs.
1. Just for learning, When a do a capture using ethereal, I see lots of ARP broadcast, almost 90% of the traffic is arp broadcast.Is this normal ? how can i tell how much brodcast is normal on a network?
why would my PC keep refreshin its ARP table even when i am not talking to any other IP/comp. on the network?

2. since I can not browse my network( says u dont have permision), is there a way to see what/how many IPs/comp. are there, on the HUB i am directly connected to? MY ISP has also blocked ping and tracert.(I guess he has blocked ICMP protocol.)

thanks in advance!
------------------------------------------

Quote:

---

Originally posted here by doiexist
[B]
1. Just for learning, When a do a capture using ethereal, I see lots of ARP broadcast, almost 90% of the traffic is arp broadcast.Is this normal ?

---

It depends on how much traffic there is anyway. On a quiet network, yes, 90% might be arp broadcast.

But more likely, they use switches, and you only see the broadcast, so in fact 90% of the broadcasts are ARPs, but there is a lot of other traffic out there you don't see because the switches don't route it to you.

Quote:

---

how can i tell how much brodcast is normal on a network?

---

I have no idea :)

There are normally quite a lot of ARPs knocking around

Quote:

---

why would my PC keep refreshin its ARP table even when i am not talking to any other IP/comp. on the network?

---

I don't know that either. It wouldn't normally send any ARPs if it was genuinely talking to nobody. However, Ethereal may be generating DNS requests which are causing ARPS.

Try turning off every application (including all servers (which seems to be impossible in Windows)), and running ethereal without DNS lookups. Leave it that way for an hour and then see how many ARPs your box sends.

Quote:

---

2. since I can not browse my network( says u dont have permision),

---

"Browse the network" is a vague term. I assume you refer to Windows For Workgroups workgroup browsing. That doesn't work too often normally anyway on perfectly well configured networks :)

Quote:

---

is there a way to see what/how many IPs/comp. are there, on the HUB i am directly connected to?

---

Look at all the ARPs and count the distinct source addresses?

Quote:

---

MY ISP has also blocked ping and tracert.(I guess he has blocked ICMP protocol.)

---

That I find highly unlikely. It is a mistake to block all ICMP messages, as it prevents useful unreachables getting through. If you are 100% sure of this, then complain. Try connecting to a host you know responds with an ICMP port unreachable or something and check it gets through. Or try a UDP packet to a closed port and watch the port unreachable.

Of course it seems more reasonable to block pings through a NAT router. But not unreachables. They should still arrive, hence traceroute should still work, as it doesn't rely on pings.

Slarty

ARP caches will start to propigate as you hit boxes on your local segment. For fun, if you have several boxes behind a switch, go ahead and ping each one. You'll see the table record each machine's IP along with its MAC address.

To reduce the number of address resolution requests, a client normally caches resolved addresses for a short period of time. The arp cache is of a finite size, and would become full of incomplete and obsolete entries for computers that are not in use if it was allowed to grow without check. The arp cache is therefore periodically flushed of all entries. This deletes unused entries and frees space in the cache. It also removes any unsuccessful attempts to contact computers which are not currently running.

There is a way to see how many devices are attached to a given switch but you wont be able to do so without knowing the admin account. There is something called a CAM table which maps MAC/IPs to a physical port on the switch. This would be about the only way that I can think of that is reliable.

Broadcast traffic is unique to each and every network. It all depends on what protocols are in use. You can have Spanning tree protocol requests bouncing around along with IPX, TCP/IP, OSPF, GRE, BGP, SNMP, RIP, WINS, NetBIOS and so on and so forth.

Make sense?

:)

Alrighty I'm gonna bring back a thread that's a couple days old. Since it's the same topic idea, let's just post together to avoid clutter.
I'm in a laptop program at the college, use a laptop in every class. Well just sitting here with my browser, msn, and icq open, I've got anywhere between 60-110KB/s coming into my system. I'm kinda curious here, because I know I get a bunch of blaster attempts but I'd like to know what else is going on. I fire up the old sniffer. The joys of the school distributing sniffing programs for us to use (ethereal of course, they refuse to pay for anything, but since it's good I don't complain). Anyways in 1 minute I captured 77,700 packets, and I'm on a switched network. 97% of these were ARP packets. That means roughtly 75,300 ARP packets were seen in a minute. That seems rather high to me. Any thoughts on it?

One possibly nefarious thing it could be is the product of a 'dsniff' style attack that uses gratituous ARP broadcasts to fool a switch (or other IP's) into routing traffic through the attacker. When you look at the sniffs, do you see the same MAC advertising for several IP's? Then that could be a source.

Another possibility is that if you see alot of ARP's coming from one IP, you could have a malfunctioning NIC.

Another possibility is that your network has an overly large broadcast domain (for example if you all share 192.168.0.0/16 in a flat topology). In this instance, it would be perfectly normal to see that kind of broadcast traffic (which is why in a heavily populated network, you wouldn't want it to be flat).

Just some food for thought...

/nebulus

HTRegz: nebulus is right, it could be from an overly large ethernet segment.

There are switches available these days which are capable of doing their own ARP caching and sending fake ARP responses to hosts, thus vastly reducing ARP traffic (ARPs are no longer broadcast unless the switch doesn't have it in its cache).

On a heavily populated network (Say >100 hosts), it would be advisable to use such a switch.

However there are other types of broadcast which are sent by default on many OSs which will also flood a LAN with messages if it gets big enough - the primary candidate will be Windows name resolution (NMB) broadcasts - assuming most of the machines are Windows (although obviously Samba will send them too on Linux for example)

Try counting the number of distinct IP addresses from the logs (you might have to make a script to do this) to see how many hosts there are

Slarty