HPE 2600 series switches create bogus DHCP snooping bindings

[Proservis]

Hello, we use a few HPE 2600 series switches in our network, with DHCP snooping enabled. The problem is that they randomly create bogus bindings, like this:

MacAddress    IP              VLAN Interface Time Left
------------- --------------- ---- --------- ---------
000001-000600 144.124.186.211 12   3         static

Once there are enough of these, the switch does not have enough memory for the legit entries..

I have traced this to a malformed packet that looks like this:
14:24:26.540083 IP 89.248.168.217.48965 > 10.20.30.1.67: BOOTP/DHCP, Reply, length 1
0x0000: 4500 001d d431 0000 fa11 8bbf 59f8 a8d9 E....1......Y...
0x0010: 0a14 1e01 bf45 0043 0009 0000 0200 0000 .....E.C........
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
(MAC addresses and destination IP were changed, originally it was a public IP of one client device, destination port can also be 68)

Such packets come from the internet once in a while, so I have blocked them on the router, however, something similar probably still comes trough, since the switches are still creating these fake entries.

Is there a way to stop the switch from creating these entries, while still keeping DHCP snooping? Or at least a way to delete then using SNMP?

[jpb2]

The issue infact persists. But you can control it via using authorized-servers in the dhcp-snooping configuration. Atleast on your toplevel/gatewayswitch depending on your design. But be careful with what addresses you set as authorized., you have to plan it carefully to get it right, you mustn't leave a legitimate one out! The switch will drop these packets and the switches "behind" will not be hit by this rubbish. I have only seen that HP Switches is affected this way. Cisco and waystream are for example unaffected. It seems like there is a way for hackers to attack networks using HP procurve switches via poisoning the dhcp-snooping database with rubbish. When the database is full (8192 entries) the switch doesn't allow any new leases. and networking will fail. A slow sort of dos attack.

Two source IP's often used for this  89.248.168.217 and 80.82.77.245

One way to clear out this garbage is to issue no ip source-binding <VLAN> <IP-ADDRESS>
But this doesn't work if the ip-address is in the multicastrange for example. And sometimes the dhcp-snooping database is not visible when issuing sh dhcp-snooping binding.

The only way to clear the dhcp-snooping database then is to reboot the switch.

I have a ongoing case at HP for this issue scince 2019-10-30, but still no definite solution has been presented. I think there has to be some sort of vulnerability on the procurves handling on dhcp-snooping, that has to be patched.

We are using 5400zl, 2600, 2610 and 2530 switches. And all of them are affected.

/Sten-Olov