Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

DHCP Snooping not working


Dear All

We are facing a weird issue while trying to configure DHCP snooping.
Users are unable to get/renew IP Addresses after enabling DHCP snooping.
The DHCP Snooping binding table is always empty.

The configuration is pretty simple

ip dhcp snooping vlan 101,104
no ip dhcp snooping information option
ip dhcp snooping

All ports connected to DHCP servers and uplinks set as trusted.

Switch Version: c3560-ipservices-mz.122-35.SE5

I tried the same configuration with another 3560 Switch running an older version with no issues at all.

This is the error we see on all the trusted ports, any ideas why this is happenning:

Dec 27 08:56:43 KSA: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/49 fo
r pak.  Was not set
Dec 27 08:56:43 KSA: DHCPSNOOP(hlfm_set_if_input): Clearing if_input for pak.  W
as Gi0/49

Dec 27 08:56:43 KSA: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/49 fo
r pak.  Was not set

Some more details about the setup:

Users are connected to 6 3560 access-layer switches. Even tough they are L3-capable switches, they are running in L2 mode. The switches uplink to a 6500 Series Core Switch.

There is an FWSM Module on the core switch which acts as the DHCP relay agent for all the user requests. The DHCP servers (Microsoft) are in a dedicated servers VLAN connected to the core switch.

Regards

Farrukh

Message was edited by: Farrukh Haroon

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: DHCP Snooping not working

Hello Farrukh,

Depending on the setup / network topo it could normal.Does it actually causing any issues?

Both messages are related to vlan 2.

Do you actualy have DHCP server in this VLAN? Do you have ip helper-address set on int vlan2 for this switch?

What message means is that the dest mac ffff.ffff.ffff is not 
in the MAT table as it is the broadcast address.
The packet is flooded into the Vlan2, which is what you expect for a broadcast packet.



The first packets is DHCPRequest from client connected to vlan2, Gi0/49:
-----
DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (2)
DHCP_SNOOPING: process new DHCP packet, message type: DHCPREQUEST,
input interface: Gi0/49, MAC da: ffff.ffff.ffff, MAC sa:
0018.de0e.ee28, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr:
-----

So if you do not have DHCP relay setup on this switch in vlan2 this is normal -
This indicates that the switch just flooded
the DHCP discover packet in vlan 2.



For the second one, which comes on Gi0/25:
This is DHCPINFORM comes as l2/l3 broadcast
from some client w alreay assigned IP (mac=000f.fe95.7115, IP=10.1.1.60) in vlan2.
---

4.3.5 DHCPINFORM message

The server responds to a DHCPINFORM message by sending a DHCPACK    message directly to the address given in the 'ciaddr' field of the    DHCPINFORM message.  The server MUST NOT send a lease expiration time    to the client and SHOULD NOT fill in 'yiaddr'.  The server includes    other parameters in the DHCPACK message as defined in section 4.3.1.

---

Again it just gets flooded in vlan 2.
But the message from the client was come on DHCP trusted snooping port,
which suppose to lead to the DHCP server (which should not lead to any client normally).

So it will not be added in binding table.
-----
DHCP_SNOOPING: process new DHCP packet, message type: DHCPINFORM, input
interface: Gi0/25, MAC da: ffff.ffff.ffff, MAC sa: 000f.fe95.7115, IP
da: 255.255.255.255, IP sa: 10.1.1.60, DHCP ciaddr: 10.1.1.60, DHCP
yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP
chaddr: 000f.fe95.7115
DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (2)
----

Thanks,
Sergey
3 REPLIES
Cisco Employee

Re: DHCP Snooping not working

Hello Farrukh,

It could be a hit of bugs like:

CSCsi94450 DHCP snooping : broadcast requests are not sent over the trusted port

and/or

CSCsd65833 CAT4500: dhcp snooping bindings out of sync:IP_SOURCE_GUARD_DENY_PACK

If possible you migth try to consider an upgrade to releases above 12.2(44)SE.

Regards,

Sergey

Re: DHCP Snooping not working

Hello

Thank you for your reply. We actually upgraded to 12.2(50)SE3 already. The DHCP snooping binding table is populated now. But we still see the following errors on some switches:


DHCP_SNOOPING: bridge a BOOTP packet or an unknown msg type dhcp packet, op code = 1
DHCP_SNOOPING: intercepted DHCPACK with no DHCPOPT_LEASE_TIME option field, packet is still forwarded but no snooping binding update is performed.
DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (2)
DHCP_SNOOPING: process new DHCP packet, message type: DHCPREQUEST, input interface: Gi0/49, MAC da: ffff.ffff.ffff, MAC sa: 0018.de0e.ee28, 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

----------------

DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/25 for pak. Was not set
DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/25)
DHCP_SNOOPING: process new DHCP packet, message type: DHCPINFORM, input interface: Gi0/25, MAC da: ffff.ffff.ffff, MAC sa: 000f.fe95.7115, IP da: 255.255.255.255, IP sa: 10.1.1.60, DHCP ciaddr: 10.1.1.60, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 000f.fe95.7115
  DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (2)
  DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/25 for pak. Was not set
  DHCPSNOOP(hlfm_set_if_input): Clearing if_input for pak. Was Gi0/25

! Gig 0/25 is a 'trusted' uplink port

-------

Regards

Farrukh

Cisco Employee

Re: DHCP Snooping not working

Hello Farrukh,

Depending on the setup / network topo it could normal.Does it actually causing any issues?

Both messages are related to vlan 2.

Do you actualy have DHCP server in this VLAN? Do you have ip helper-address set on int vlan2 for this switch?

What message means is that the dest mac ffff.ffff.ffff is not 
in the MAT table as it is the broadcast address.
The packet is flooded into the Vlan2, which is what you expect for a broadcast packet.



The first packets is DHCPRequest from client connected to vlan2, Gi0/49:
-----
DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (2)
DHCP_SNOOPING: process new DHCP packet, message type: DHCPREQUEST,
input interface: Gi0/49, MAC da: ffff.ffff.ffff, MAC sa:
0018.de0e.ee28, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr:
-----

So if you do not have DHCP relay setup on this switch in vlan2 this is normal -
This indicates that the switch just flooded
the DHCP discover packet in vlan 2.



For the second one, which comes on Gi0/25:
This is DHCPINFORM comes as l2/l3 broadcast
from some client w alreay assigned IP (mac=000f.fe95.7115, IP=10.1.1.60) in vlan2.
---

4.3.5 DHCPINFORM message

The server responds to a DHCPINFORM message by sending a DHCPACK    message directly to the address given in the 'ciaddr' field of the    DHCPINFORM message.  The server MUST NOT send a lease expiration time    to the client and SHOULD NOT fill in 'yiaddr'.  The server includes    other parameters in the DHCPACK message as defined in section 4.3.1.

---

Again it just gets flooded in vlan 2.
But the message from the client was come on DHCP trusted snooping port,
which suppose to lead to the DHCP server (which should not lead to any client normally).

So it will not be added in binding table.
-----
DHCP_SNOOPING: process new DHCP packet, message type: DHCPINFORM, input
interface: Gi0/25, MAC da: ffff.ffff.ffff, MAC sa: 000f.fe95.7115, IP
da: 255.255.255.255, IP sa: 10.1.1.60, DHCP ciaddr: 10.1.1.60, DHCP
yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP
chaddr: 000f.fe95.7115
DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (2)
----

Thanks,
Sergey
6686
Views
5
Helpful
3
Replies