dhcp snooping problems

abdus_salam_ictp · ‎06-22-2007

I have a LAN using 3750's (IOS12.2(37)SE) as edge and 6500's as core. In a number of cases, I have linksys swr224G4 or other simpler switches attached to 3750's, which act as concentrators. In such cases, the 3750 ports connecting the linksys are declared as 'untrusted' for dhcp snooping.

I'm using multiple VLANs, VTP, arp inspection; and I apply snooping only to one vlan (by now).

dhcp snooping blocks operation of the laptops attached to linksys in a fairly strange way:

basically, broadcast dhcp packets (DISCOVER etc.) are discarded if they arrive from another switch; they are forwarded when they arrive from a host; to make things more complex, if and while a host directly attached to the 3750 is active, also the broadcast packets from the other switches are forwarded.

When a broadcast dhcp packet arrives to a 'host' fast ethernet port, the debug messages are as follows :

Jun 22 15:16:08.257: DHCP_SNOOPING: received new DHCP packet from input interface (FastEthernet4/0/45)

Jun 22 15:16:08.257: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Fa4/0/45, MAC da: ffff.ffff.ffff, MAC sa: 0016.36a0.54c7, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0016.36a0.54c7

Jun 22 15:16:08.257: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (104)

The packet arrives to the server, the answer comes back and everything is OK.

On the other hand, if the packet is coming from another switch, the debug shows what follows:

Jun 22 15:12:01.939: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet1/0/3)

Jun 22 15:12:01.939: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Gi1/0/3, MAC da: ffff.ffff.ffff, MAC sa: 0011.25d6.8360, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0011.25d6.8360

Jun 22 15:12:01.939: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (104)

Jun 22 15:12:01.939: DHCP_SNOOPING_SW: bridge packet output port set is null, packet is dropped.

The difference is in the last line:

and in fact the dhcp server (somehwere upstream) never gets that packet.

As I said above, if I connect directly a laptop to the 3750 (as in the first example above), also the requests from port gi1/0/3 and from the other ports are forwarded: the messages about packets being dropped disappear entirely.

Note that this process of discarding DHCP broadcasts happens on all interfaces of the 3750: DISCOVER or INFORM coming from the uplink, DISCOVER coming from switches attached to a trunk interface, DISCOVER coming from stupid switches attached to an access port. And all of these start working when a host is active on an access port in that vlan.

Anyone has an idea? heard of something I can use?

Alvise Nobile

umedryk · ‎06-28-2007

By default, if the gateway address is set to all zeros in the DHCP packet and the relay information option is already present in the packet, the Cisco IOS DHCP relay agent will discard the packet. If the ip dhcp relay information trusted command is configured on an interface, the Cisco IOS DHCP relay agent will not discard the packet even if the gateway address is set to all zeros. Instead, the received DHCPDISCOVER or DHCPREQUEST messages will be forwarded to the addresses configured by the ip helper-address command as in normal DHCP relay operation.