cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2418
Views
0
Helpful
5
Replies

help with ip dhcp snooping

alvaroarcila
Level 1
Level 1

Hi you all out there

I'm trying to implement ip dhcp snopping in the access switchs on the company I work for, I did the configuration following the guidelines that apperad on cisco docs, but we have noticed that some of the pcs connected to the switchs lost connection after some time.

1-We connect the pc to teh switch

2-It obtains ip from the DHCP server

3-After some time appers the message indicating that the pc has limited o null connection

4-we run the commands ipconfig /release ipconfig /renew

5-the pc starts working again

Some times we have tu apply step 4, several times till it works again.

The port where the dhcp server is connected was configured as:

ip dhcp snooping trust.

The access ports are configured:

switch port access

ip source verify port-security

switchport port-security maximum 1

switchport port-security

ip dhcp snooping vlan 1

ip dhcp snooping

no ip dhcp snooping information option

when the pc lost connection we run the ios commands

show ip verify source : the port where the pc is connected apperas valid -no deny all appears-

show ip dhcp snooping binding : shows a record corresponding to the mac of the pc and the las ip it got

the access switchs are cisco 2960, the core switch is a 4507 no ip dhcp snooping configuration has been run on this last one, trunk ports are configured as trunk.

Thanks for your help guys I have no one else to ask for help.

5 Replies 5

Reza Sharifi
Hall of Fame
Hall of Fame

Hi,


I see you have
no ip dhcp snooping information option

You need to enable
ip dhcp snooping information option

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_35_se/configuration/guide/swdhcp82.html#wp1070843

Can you try this and test again?

HTH

Reza

b.julin
Level 3
Level 3

The information-option stuff can be a confusing source of problems for DHCP snooping.  I think you should be fine with global "no ip dhcp snooping information option" however, the more thorough option is to configure downstream trunks (that the dhcp server sends on and which recieve client requests) with:

ip dhcp-snooping information-option allow-untrusted

...in case an option 82 manages to get onto the network via a client or 3rd-party switch that injects it.  And of course upstream trunks (on the other side) need

ip dhcp-snooping trust

Once you have the trunks configured this way, it is OK to take the "no ip dhcp-snooping option" global command out.  If a switch does not support the "allow-untrusted" command you can use just "ip dhcp-snooping trust" and rely on the client ports being untrusted.  If your core is large, trusting all trunk ports is probably best -- let the access switches deal with it.

Depending on what you want to allow from clients, you may put the "allow-untrusted" on the client ports as well.  If you want to use Option 82 eventually on the DHCP server side for policy reasons, however, you should probably look into the commands for replacing their Option-82s with the switch generated ones.

Try running dhcp debugging commands on the switch.  They can take a little patience to wade through, but they often pinpoint such problems.

Hi you all there

At first sigth I was lookinkg for issues regarding snooping but I think there's someting else going on.

I have found the following issues:

A laptop with both wire and wireless adapters connected to the same vlan, the logs of the switch shows that conflict, so I deactivated all the adapters of the laptop but the wire remains active, ipconfig /release, ipconfig /renew. and it works fine for and two or two and a half  hours, after that period of time the laptop shows null connectivity, ping to gateway or others pcs doesn't respond.

run the following commands

debug ip dhcp snooping 00:1B:24:A1:B0:B2

shows this when i run ipconfig /release ipconfig /renew

May  6 12:58:19.980: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Gi1/0/13, MAC da: ffff.ffff.ffff, MAC sa: 001b.24a1.b0b2, 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: 001b.24a1.b0b2
May  6 12:58:19.980: DHCP_SNOOPING: add relay information option.
May  6 12:58:19.980: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0x1 0x1 0xD 0x2 0x8 0x0 0x6 0x44 0xE4 0xD9 0xBE 0x6F 0x0
May  6 12:58:19.980: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (1)
May  6 12:58:19.980: DHCP_SNOOPING_SW: bridge packet send packet to cpu port: Vlan1.
May  6 12:58:19.980: DHCP_SNOOPING: process new DHCP packet, message type: DHCPOFFER, input interface: Gi1/0/24, MAC da: ffff.ffff.ffff, MAC sa: 0050.56a8.0d92, IP da: 255.255.255.255, IP sa: 172.26.2.68, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 172.26.5.88, DHCP siaddr: 172.26.2.68, DHCP giaddr: 0.0.0.0, DHCP chaddr: 001b.24a1.b0b2
May  6 12:58:19.980: DHCP_SNOOPING: direct forward dhcp replyto output port: GigabitEthernet1/0/13.
May  6 12:58:19.980: DHCP_SNOOPING: process new DHCP packet, message type: DHCPREQUEST, input interface: Gi1/0/13, MAC da: ffff.ffff.ffff, MAC sa: 001b.24a1.b0b2, 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: 001b.24a1.b0b2
May  6 12:58:19.985: DHCP_SNOOPING: add relay information option.
May  6 12:58:19.985: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0x1 0x1 0xD 0x2 0x8 0x0 0x6 0x44 0xE4 0xD9 0xBE 0x6F 0x0
May  6 12:58:19.985: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (1)
May  6 12:58:19.985: DHCP_SNOOPING_SW: bridge packet send packet to cpu port: Vlan1.
May  6 12:58:19.985: DHCP_SNOOPING: process new DHCP packet, message type: DHCPACK, input interface: Gi1/0/24, MAC da: ffff.ffff.ffff, MAC sa: 0050.56a8.0d92, IP da: 255.255.255.255, IP sa: 172.26.2.68, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 172.26.5.88, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 001b.24a1.b0b2
May  6 12:58:19.985: DHCP_SNOOPING: direct forward dhcp replyto output port: GigabitEthernet1/0/13.
May  6 12:58:23.739: DHCP_SNOOPING: process new DHCP packet, message type: DHCPINFORM, input interface: Gi1/0/13, MAC da: ffff.ffff.ffff, MAC sa: 001b.24a1.b0b2, IP da: 255.255.255.255, IP sa: 172.26.5.88, DHCP ciaddr: 172.26.5.88, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 001b.24a1.b0b2
May  6 12:58:23.739: DHCP_SNOOPING: add relay information option.
May  6 12:58:23.739: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0x1 0x1 0xD 0x2 0x8 0x0 0x6 0x44 0xE4 0xD9 0xBE 0x6F 0x0
May  6 12:58:23.739: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (1)
May  6 12:58:23.739: DHCP_SNOOPING_SW: bridge packet send packet to cpu port: Vlan1.
May  6 12:58:23.739: DHCP_SNOOPING: process new DHCP packet, message type: DHCPACK, input interface: Gi1/0/24, MAC da: ffff.ffff.ffff, MAC sa: 0050.56a8.0d92, IP da: 255.255.255.255, IP sa: 172.26.2.68, DHCP ciaddr: 172.26.5.88, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 001b.24a1.b0b2
May  6 12:58:23.744: DHCP_SNOOPING: intercepted DHCPACK with no DHCPOPT_LEASE_TIME option field, packet is still forwarded but no snooping binding update is performed.
May  6 12:58:23.744: DHCP_SNOOPING: direct forward dhcp replyto output port: GigabitEthernet1/0/13.

The laptop obtains its ip address, but cant get ping from others pcs on the lan.

run debug ip verify source packet

ping to other pcs no respond and debug shows nothing.

the conf on the interfaces goes like this

interface GigabitEthernet1/0/13
switchport mode access
switchport port-security

ip verify source

Any clue, should I avoid snooping or ip verify source....the main porpuse is to avoid problems due to a roug dhcp server, we have suffered this type of problems on the past and as I have read this is the way to act in this type of situations.

If you are mainly concerned with rogue DHCP, you do not need "ip verify source" to defend against that.

It would still be good to get "ip verify source" (and arp inspection) working, but try testing without it, then

at least you will know if that is the issue (which it probably is, since dhcp-snooping alone will only

mess with DHCP traffic.)

I note from the logs that last line seems to say that your DHCP server is not adding a lease

time to its DHCPACK packets... that might be normal though since it is the second ACK.

Thanks for your advice, I'm going to test at least for a few days the snooping feature, if nothing goes wrong the I will activate verify source and look if this is teh cause of the problem.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card