Forum Discussion

rmavro's avatar
rmavro
Visitor
11 years ago

ARP Floods

Have a customer that wants to use 10's, even 100's of Roku 3 boxes in an enterprise network.

The problem is that the boxes send tons of ARPs, flooding the network and making the LAN fully saturated, useless. Seems to be related to the remote control, where the boxes are finding each other and getting confused?

These are Ethernet wired Roku 3 devices. Each is in a different room, but the rooms are in the same building.
Plan is to deploy about 150 units, but that seems impossible due to the ARP flooding.

How do stop the ARP flooding problem?

6 Replies

  • What exactly are they ARP-ing, do you have a capture?
    I know Rokus announce themselves periodically with UDP cast but it's not that often to be a problem...
  • Here is a Wireshark trace:

    https://dl.dropboxusercontent.com/u/330 ... nds.pcapng

    This is a smaller capture file that was taken in 46 seconds showing broadcast traffic. The Roku ports were enabled at the beginning of the capture and then disabled around 45 seconds. Which also shows that the Roku ARP requests stops at that point.

    Roku 3 boxes have the current firmware.
  • 94% of these 531453 packets came from 9 Rokus ("Roku_81:d8:40", "Roku_d8:42:84", "Roku_d8:43:8c", "Roku_81:c4:f0", "Roku_81:f6:5c", "Roku_d8:33:7c", "Roku_81:d0:b0", "Roku_81:ad:c8", "Roku_d8:47:d0").
    From what i can see, most of the traffic is from the Roku boxes hARPing from 10.105.1.* for IP=10.105.1.1 (presumably the gateway):
    77%     arp.src.proto_ipv4 == 10.105.1.0/24
    18% arp.src.proto_ipv4 == 10.5.5.0/24
    3% arp.src.proto_ipv4 != 10.5.5.0/24 && arp.src.proto_ipv4 != 10.105.0.0/16

    0 arp.src.proto_ipv4 == 10.105.1.0/24 && arp.dst.proto_ipv4 != 10.105.1.1
    0 arp.src.proto_ipv4 != 10.105.1.0/24 && arp.dst.proto_ipv4 == 10.105.1.1

    Where most of the network sounds being in 10.1.*.* and 10.5.*.*. My guess is wrong DHCP configuration, where Rokus were fed bad host/network info and are getting crazy looking for the gateway.

    Still, one of the Rokus (Roku_81:d8:40) blurting 96428 frames in 38 secs = 2500 per second, seems a little excessive - no?
  • Have you tried disabling network pings via the secret screen?

    Home (x5)
    Fast Forward
    Play
    Rewind
    Play
    Fast Forward
  • Will try disable Ping via Secret Screen next and post the result.
    Will also ask the customer to set fixed IP, that would eliminate the DHCP error theory.

    But, yeah, so many ARP's is certainly excessive!
  • Roku does not support fixed-IP, only DHCP. But network admin can mend DHCP to fit - for example if they are sending 10.105.1.1 as gateway for 10.105.1.* and such host does not exist, better not to send GW at all instead of a fake IP.

    My feeling is this is a double-trouble case: a) something is misconfigured on the LAN/VLAN and b) that makes Rokus berserk/abusive (so yes, there'd be something for RokuCo to fix too)

    The capture you took was missing the host responses (because they are unicasts back to the host). To see more detail, try to insert you listener in front of a Roku - say through a hub (not switch) or wiFi - and interface in promiscuity