Frequent ARP request broadcast for Who has x.x.255.255? from S-Series root switch in RSTP VLAN

[Edwin]

We are getting average of 1 pps and peaks of 60 pps of these packets, from Wireshark trace.

Please kindly share information on what is the cause of these broadcasts and how to minimize the frequency.

TIA.

Screenshots of Wireshark decode and IO graph below:

[Edwin]

Hi Erik,

Our RSTP with VLAN-2 Class B network with subnet mask of 255.255.0.0 is normally used offline from the Internet and data or comms links are confined only to the subnets with the all known dual-homed hosts belonging to VLAN-2. Normally, no routing requirements. This was the environment with the N-series root and backup root switches.

With the upgrade, the S-Series were adopted, together with the addition of cyber security measures, such as, PDC/SDC, WSUS, ePO and backup servers. These servers sit inside a DMZ above the RSTP network. These servers connect to the (additional) 3rd NIC of the RSTP hosts. Traffic is isolated from the original 2 (fault tolerant) NICs. I believe the "3rd Ethernet" network has also its own VLAN and subnet assignments.

The SNTP server (with satellite GPS card) remains inside the RSTP network.

The new network is operating ok, and we just want to check if we can get rid of the ARP requests (for x.x.255.255), which as you mentioned, are not getting any response.

Is there anyway to validate the assumption that the S-Series switches are generating the subject ARPs due to the NTP time sync broadcasts to x.x.255.255; besides switching off the SNTP host machine? Why are the ARPs generated after every other set of 2 NTP broadcasts -- there are 2 NTP pkts every 16 seconds, the ARPs only occur for one set (repeating only every 32 seconds). Can there be other sources besides the NTP broadcasts, which our Wireshark traces are not able to capture (without port mirroring, etc.)?

[Erik_Auerswald]

Hi Edwin,

that N-Series configuration pertains to the switch ip address, not a router (SVI) address. That interface does not forward IP packets. The default route pointing to the switch management interface is surprising.

Firmware version 6 was the last version to use different IP stacks for switch management and routing / layer 3 forwarding. The S-Series never had firmware version 6, it started with version 7 using a unified IP stack. This new IP stack might cause the different behaviour.

Did you have a router configuration on the N-Series switches? Do you want the S-Series to forward IP packets?

I understand the situation as follows:

1. Both S-Series receive the directed broadcast packet sent with a broadcast MAC address.
2. Both S-Series want to forward the packet to its destination.
3. Both S-Series have the IP subnet as directly connected in there routing tables, so they try to deliver the packet locally.
4. For local delivery, the S-Series need to know the MAC address for the x.x.255.255 IP address. This address is not found in the ARP table, so ARP requests are generated. Those are repeated, because there is no reply. (Those ARP requests should not be generated.)
5. Neither S-Series forwards the directed broadcast packet.

I suppose your network is OK and you just want to get rid of the ARP requests?

You might want to consider disabling ip forwarding on the S-Series' management interfaces, if you do not want it to act as a router and forward IP packets.

Erik

[Erik_Auerswald]

Hi,

IMHO, the switches should not create ARP requests for the subnet broadcast address.

You might want to enable directed broadcasts on the S-Series, since your SNTP server uses them:
configure
interface vlan.0.XXX
ip directed-broadcastThe output of "show ip interface" tells you if directed broadcasts are enabled on an SVI.

Erik

[Edwin]

The root and backup root switches have 2 interconnecting patch cords.

The root and backup-root switches were recently upgraded from N-series to S-series, and we did not have these ARP broadcasts for x.x.255.255 earlier.

Checking the Wireshark trace, I find that the ARP requests for x.x.255.255 are being generated right after the NTP broadcasts to the same x.x.255.255 address. The SNTP Server has a Satellite GPS timesync card and is on one of the subnets.

Does the label, "all-subnets-directed broadcast" apply to the NTP broadcasts, even though the source is on one of the subnets?

The Wireshark IO graph (using stacked bars) is shown below; with the NTPs in blue at 2 pkts every 16 seconds, ARPs from root switch in yellow, and ARPs from backup root switch in purple:

Why are there 6 sets of ARPs per switch for every other NTP?

Your advice and guidance on this matter is very much appreciated.

[Mel78__CISSP__E]

Hi,

I do not want to speculate any further. You have identify the source of the ARP broadcast which is the SNTP server time sync via broadcast.

So either you have to segregate different vlans to limit the broadcast domain and use the switch as proxy arp or there are countless ways to mitigate the issues. But you cannot eliminate the root cause if you allow NTP server to broadcast.

Just another point to add, the source of the broadcast from NTP server is likely because the NTP server did not configure any gateway. Once theres any NTP request (unicast) to the NTP server, the server will "SHOUT" out to everyone. And your switches will echo everywhere and thus broadcast storm but low traffic.