05-04-2011 06:56 PM - edited 03-06-2019 04:54 PM
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.
05-04-2011 07:34 PM
Hi,
I see you have
no ip dhcp snooping information option
You need to enableip 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
05-05-2011 09:27 AM
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.
05-06-2011 06:48 AM
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.
05-06-2011 06:59 AM
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.
05-06-2011 02:36 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide