In order for dhcp-snooping
to function correctly, the snooping device needs to be setup as just a layer 2 device (i.e. not performing DHCP functions at all). There are a few gotcha’s from 3Com's documentation, 3Com® Switch 4500G Family Configuration Guide (p. 405), which should still be applicable to your platform.
The DHCP Snooping supports no link aggregation. If an Ethernet port is added into an aggregation group, DHCP Snooping configuration on it
will not take effect. When the port is removed from the group, DHCP
Snooping can take effect.
If you have aggregated uplink ports (802.3ax), the link won’t be snooped on.
The DHCP snooping enabled device does not work if it is between the DHCP relay agent and DHCP server, and it can work when it is between
the DHCP client and relay agent or between the DHCP client and
server.
In your test bed scenario, you basically had a client and a server connected into 2 different access ports; one a trusted DHCP port. This is the simplest way to setup DHCP-snooping. Had this of gone wrong, I would suspect there is another, underlying issue/configuration mistake.
The DHCP Snooping enabled device cannot be a DHCP server, DHCP relay agent, DHCP client, or BOOTP client. Therefore, DHCP Snooping must be
disabled on a DHCP server, relay agent, DHCP relay agent, DHCP
client, and BOOTP client.
What this final bit means is that you really can’t have your switch performing any DHCP functions, aside from DHCP-snooping.
In the comments, you stated ”it is just L2 device”. I would check over your configurations more thoroughly, because you are attempting to implement that absolute basic configurations needed for DHCP snooping to function. You tested it on your test network, and it worked fine. Now your production network, with seemingly identical configurations, isn't working.
Below are basic configuration procedures from the 3Com documentation; if these don't work, I would certainly be looking elsewhere.
1 Enable DHCP snooping.
<Sysname> system-view
[Sysname] dhcp-snooping
2 Specify GigabitEthernet1/0/1 as trusted.
[Sysname] interface GigabitEthernet1/0/1
[Sysname-GigabitEthernet1/0/1] dhcp-snooping trust
You do not need DHCP snooping or DAI running on the 3750 core switch in order use those features on the 2960 access switches.
On the 2960s just enable DHCP snooping and DAI globally for the needed VLANs and then trust the trunk ports for both snooping and DAI. The commands will probably look something like this:
! Global commands on the 2960s
ip dhcp snooping
ip dhcp snooping vlan 1-4094
ip arp inspection vlan 1-4094
! Trunk Port on the 2960
int Gi0/1
ip dhcp snooping trust
ip arp inspection trust
Note that if you have VLANs with statically instead of DHCP assigned IPs, you will need to exclude them from the VLAN lists, trust the ports with static assigned IPs (not preferred if they really aren't trusted ports), or exclude the vlan from DHCP snooping and use ARP ACLs for that VLAN for DAI.
Also, if this is a network already in production make sure the DHCP snooping database has any existing leases already collected, before implementing the DAI commands otherwise some legitimate ARP requests will be blocked (or configure everything during a service window that allows re-triggering DHCP lease requests for all effected clients).
Cisco documentation for DAI is here
Best Answer
If no DHCP clients are connected directly to your distribution or core then you wouldn't need to configure DHCP snooping there. You would just configure your access layer switches to untrust every port except for your uplinks to the distribution switches.