Results 1 to 4 of 4

Thread: ARP broadcast storm

  1. #1

    ARP broadcast storm


    I got something that looks like an ARP broadcast storm and I'm trying to nail down the exact problem. Unfortunately I only have remote access via ssh through eth0 to the box.

    Basically I have a full speed generation of arp queries and occationally replies to sometimes asked and seemingly non asked questions.

    There are two NICs. eth0 and eth1. eth0 is on ext side and eth1 is on int side. All looks OK on eth0 side. Eth1 is a LAN with only access via eth0 WAN connection.

    This is what I get (modified):

    00:00:00:00:00:e7 > 00:00:00:00:00:e7, length 42: arp reply nn.nn.nn.225 is-at 00:00:00:00:00:e7

    Every now and then I get one of these:

    00:00:00:00:00:e7 > ff:ff:ff:ff:ff:ff, length 60: arp who-has nn.nn.nn.225 (ff:ff:ff:ff:ff:ff) tell
    00:00:00:00:00:e7 > 00:00:00:00:00:e7, length 42: arp reply nn.nn.nn.225 is-at 00:00:00:00:00:e7

    The routing table looks like this:
    Destination Gateway Genmask Flags MSS Window irtt Iface
    nn.nn.1.64 U 0 0 0 eth0
    nn.nn.2.224 nn.nn.2.225 UG 0 0 0 eth1
    nn.3.0.0 U 0 0 0 eth0 U 0 0 0 lo nn.nn.1.65 UG 0 0 0 eth0

    On the eth1 side we have a switch and two devices hooked up to it. nn.nn.2.233-233

    There are no arp proxies or duplicate IP addresses. When freshly booted it keeps replying to it's own query where (IP of eth1) is. Where is nn.nn.nn.225 tell nn.nn.nn.225.

    Sometimes a ping reply comes back to .237 (managed switch). Which seems indicative of the flood (there are 1000 FIFO errors).

    ARP has all the valid MACs in its table.

    I suspected bad NIC on eth1 but since I don't have physical access I wanted to somehow verify it before getting someone in a different state to drive 45 miles to look.

    Besides I figured one should be able to narrow down the problem a bit more.

    Any help would be appreciated!


  2. #2

    We got a guy in the NOC who had been helpful and plugged both ends of a patch cable into the same switch... Of course I had to send a guy out to the NOC to discover this.

    Interesting effect though. Hehe.


  3. #3
    Administrator Moderator
    starfish's Avatar
    Join Date
    Apr 2004
    You should try to switch off that port autosensing which flips the port from DCE to DTE and back till it gets link. This helps with not having to worry about what cable type you have "straight through" or " crossover" it figures it out by itself.

    Some of the low end switches can't recognize that they should shut down the port when they see spanning tree BPDUs coming in on a port with the switches own ID. If not they just keep looing the packets around and around which then spikes the CPU on the switch eventually killing it. The switch causes a spanning tree loop with itself.

    I've heard about it on HP switches. What model are you using? I forgot the feature name they call it. Try switching the feature it off, but make sure everyone has the correct cable ahead of time. Knocking the email server off line because of the change will win you no friends.

  4. #4
    It's an old Baystack switch which does it's job just fine. Except when someone puts a loop between two ports. : )

    The thing was I could not even reach it because of the volume of traffic. But eventually I got someone out on location to check it out. Which is when we discovered the patch cable.

Similar Threads

  1. Broadcast Printing
    By kikboxr777 in forum Windows - General Topics
    Replies: 0
    Last Post: 12-12-2005, 06:50 PM
  2. Wicked Storm Brewing
    By Fatal Error in forum General Chat
    Replies: 18
    Last Post: 09-10-2005, 08:26 PM
  3. Mars engulfed by global dust storm
    By JimH in forum General Chat
    Replies: 0
    Last Post: 10-12-2001, 07:17 PM


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts