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
Basics
When you tag a VLAN on a port, it will send out the traffic on that port with the VLAN tag, when the port receives traffic it looks for the tag and places the traffic into that VLAN. You can have multiple tagged VLANs on one port (sometimes called trunk).
When you send out a VLAN untagged on a port it will not add the VLAN tag to the packet and when receiving packets without a VLAN tag it will be placed into that VLAN (on Netgear and others you have to set PVID (Primary VLAN ID))
To your problem
I think you are not far away...
- Router port connected to Switch1 should have IP within VLAN 2220.
- DHCP Server should have different IP from different Subnet!
- Router port Connected to Switch2 should have IP in Subnet of DHCP Server
- You should define a DHCP Helper on Router port connected to Switch1 so DHCP Request get forwarded to DHCP Server. Hot to do that is described here: http://kb.netgear.com/app/answers/detail/a_id/21990/~/how-do-i-configure-a-dhcp-l3-relay-using-the-web-interface-on-my-managed-switch%3F
Hope this helps you a little bit further. If not, please post a more detailed network diagram with VLAN IDs and IPs.
Best Answer
It appears the answer is that it is unnecessary configuration. If DHCP snooping is not running on that VLAN, then this configuration has no effect.
I still couldn't find documentation that clearly states this, so I decided to test this myself.
Started off with DHCP snooping enabled for all VLANs and a rate limit of one (1) DHCP packet per second (assuming that the client will send the DISCOVER and REQUEST in one second if the DHCP server responds quickly enough):
Time for the control test, which should err-disable the port, which is exactly what occurs in about a second after the port transitions to up/up:
Since the control worked as expected, I now remove VLAN 841 from the DHCP snooping configuration and enable the port again. One minute later, I shut the port (to show the timestamp):
Repeated multiple times with the same results using the following:
Would still love for someone to find documentation for this though.