Bindings Created by DHCP Snooping

DHCP snooping watches DHCP exchanges to create a MAC to IP binding for a client. A basic DHCP client/server exchange is as follows:

1. client -> server: DISCOVER
2. server -> client: OFFER
3. client -> server: REQUEST
4. server ->client: ACKNOWLEDGE

It is the acknowledgement from the server that creates the binding, and the server message is considered authoritative. (No other security measures other than those described here are used to ensure that the server is legitimately responding to a client request.) The ACK message includes the client hardware address and the client's confirmed IP address. It is the client hardware address (not the MAC destination address) that is used in determining if there is already an entry in the multiauth session table for the user, to which the IP address will be bound. If there is no entry in the session table for the client, a message will be logged.

Only DHCP server ACK messages received on trusted ports will populate MAC-IP address bindings. On untrusted ports, any DHCP server packets are recorded (that is, the counter is incremented), but they are allowed to be further processed. If policy is properly configured, the packets will be dropped or the port will be shut down, as configured. These server messages are not used to populate MAC to IP bindings. Bypass ports ignore all DHCP server packets for purposes of populating the binding database.

DHCP server messages are are limited to trusted ports, so the bindings that are created by them are not intended to be recorded as violations. In the case that a server sends a client a new binding (with a different IP) before the current binding's lease has expired, the event will trigger a SYSLOG message, but will not increment the violation counter.

If neither DAI nor IP source guard are configured to populate the bindings table (disabled or inspection-only), DHCP server ACK message are required to create the IP binding for a user. In this configuration, the switch will drop any DHCP server messages that cannot be processed by the soft path. The expected result of this would be for the DHCP client to re-initiate a request to the server and thus give the switch another opportunity to add the entry to the binding table. When either DAI or IP source guard is configured to populate the bindings table this is not necessary (the switch can forward the ACK), as the user's binding is able to be populated by other traffic sourced from the user, so the packet would not be discarded.