> Here is a question.
> What is a normal amount of "noise" on a network?
> Let me give you the situation.
> I have just co-located a server at an ISP, I noticed a constant inbound
> traffic on my MRTG graph after it had been running on his network for a
> When I asked about it he said it was normal for there to be "noise" on
> an internet connected network.
> So I have done some testing.
> I ran "time tcpdump -c 100 -p broadcast" to see how long it would take
> for 100 noise packets to be recieved ( in the sample none of the packets
> were for my server ). This took 14.644 seconds.
> This means that there are broadcasts on the network coming in at a rate
> of 6.83 packets per second.
> The majority of them are arp requests and if I am correct an arp request
> is 28 Bytes plus the ethernet header of 14 Bytes. A total of 42 Bytes
> per packet.
> This means that at a rate of 6.83pps and a size of 42 Bytes over 30 days
> it will consume about 743MB of bandwidth.. Since I pay for bandwidth
> this is relevant.
> So does this seem normal?
> Has my ISP got a problem on their network?
A.C. has some good points/suggestions. To get a good eyeball of
what's going on you can run ethereal -- or on your server run tcpdump
and fetch the output to view in ethereal -- and capture _all_ the
traffic for, say 10 mins. More time, bigger capture file but a
"better" snapshot. Also do your capture during different parts of the
day/night to get a better "monthly avg" figure.
As is, however, your rate of _broadcasts_ -- which are limited to a
single net segment -- seems pretty high to me. If the route
tables/cache are working as they should and the arp cache is doing
it's job you should not be seeing this much host generated broadcast
traffic or MAC resolutions, IMHO. Is the ISP using broadcasts to
maintain/monitor link connectivity? Capturing all traffic for several
time periods should tell you this. And be sure to note what protocols
are running on the wire.
Also, how you are tied into the network could be an issue. Are you
connected by a router that you control? If its the ISP's router they
may have cache size/timeout issues that are requiring excessive arp
requests/resolutions. The same applies to you, of course, with your
router. Capture all the traffic to make sure the ISP is not
generating "excessive" routing protocol traffic that is passing on
your uplink segment -- these can get out of line with a
misconfiguration somewhere and generate broadcasts.
If we're talking switches and VLANS, another beastie could be loose on
the segment that's creating bridging loops or some similar problem
when a particular MAC-IP tickles a stale or misconfigured entry.
These tend to be very spiky or overwhelming though -- doesn't seem to
be your case.
Main thing to do now is to do several captures of all traffic on the
effected interface and get a good eyeball impression of what's going
email above disabled