IP DHCP snooping and Dynamic ARP Inspection are correctly configured on switch for vlan11. One host was unplugged from the network, then plugged back. I receive a syslog DAI message indicating that ip address 169.254.97.238 is denied access:
Apr 11 11:03:39.692 UTC: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa1/0/12, vlan 11.([0024.8154.2aca/169.254.97.238/0000.0000.0000/169.254.97.238/11:03:39 UTC Mon Apr 11 2011])
Apr 11 11:03:40.699 UTC: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa1/0/12, vlan 11.([0024.8154.2aca/169.254.97.238/0000.0000.0000/169.254.97.238/11:03:40 UTC Mon Apr 11 2011])
Apr 11 11:03:41.714 UTC: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa1/0/12, vlan 11.([0024.8154.2aca/169.254.97.238/0000.0000.0000/169.254.97.238/11:03:41 UTC Mon Apr 11 2011])
I cleared the DHCP snooping binding table with no success. No binding could be created on interface fa1/0/12 unless we reboot the PC.
Your machine is attempting to arp using a Microsoft self assigned ip address and the original MAC address. DAI sees this as an attack because your machine already had an arp entry as a different ip address associated with that MAC address, so DAI blocks the arp request and logs the messages you see. Your machine seems to require to be rebooted (or ipconfig /release /renew) for your machine to attempt to retrieve the dhcp lease.
Please rate if helpful.
Message was edited by: antonioknox
Correct, I suspected that. What I do not understand is why Microsoft assigned ip address is still there, even after I did "ipconfig /release" and "ipconfig /renew" multiple time. Why the IP address is released only after a reboot?
Why the IP address is released only after a reboot?
It can't be released as it is not a DHCP assigned address but your host should try to contact DHCP server every 30 second if I remember well so you shouldn't need to reboot and if you're in a hurry then deactivate/reactivate or repair your interface.
I deactivated/activated the NIC many times with no success. I still have to reboot the machine.
The port is neither VMPS nor dot1x. We set DHCP to assign the same IP to the NIC.
Can you sniff traffic on host to verify it is trying to contact a DHCP server every x interval after getting this APIPA address and at same time monitor traffic on the switch to try to understand why you have to reboot and if there is a fix.
Dynamic Arp Inspection and DHCP Snooping are good working. The Apipa is
comming with a DHCP and must be blocked.
Do you have static ports, Dynamic (vmps) or 802.1x ports?
Most times disconnect and connect the network cable from the NIC will result to a DHCP request.
You have to reboot because:
Try finding the mac address of the machine in the arp cache. You already have the mac-address handy, so you can try the following
!---Find out what ip is in the arp cache that casuses DAI to block your arp requests
Switch#sh ip arp 0024.8154.2aca
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.5 - 0024.8154.2aca ARPA Vlan15
!---Clear out that arp entry, this should prevent DAI from giving you fits
Switch#clear ip arp 192.168.1.5
Unplug the cable from the NIC then reconnect it. This should get your DHCP lease back.
I consulted a Microsoft collegue and he told me that after a host gets its IP through APIPA, it waits 5mn before contacting DHCP server again; a reboot lets it get an IP address dynamically.
AntonioKnox, I did as you mentioned with no success. DAI still blocks the APIPA address.
I changed the port on which sits the PC. I erased the entry in "show ip dhcp snooping binding ..."
TNSWACCS01A1#show ip dhcp snooping bindi
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:24:81:54:2A:CA 10.100.0.9 579174 dhcp-snooping 11 FastEthernet1/0/12
70:71:BC:6F:54:97 10.100.0.42 425950 dhcp-snooping 11 FastEthernet1/0/13
F4:CE:46:02:FA:74 10.100.0.110 591049 dhcp-snooping 11 FastEthernet1/0/28
F4:CE:46:02:FA:9B 10.100.0.45 591049 dhcp-snooping 11 FastEthernet1/0/28
70:71:BC:6F:4B:8C 10.100.0.4 425582 dhcp-snooping 11 FastEthernet1/0/13
00:26:55:37:76:04 10.100.0.32 584872 dhcp-snooping 11 FastEthernet1/0/35
00:22:64:C0:28:9F 10.100.0.101 491128 dhcp-snooping 11 FastEthernet1/0/27
00:26:55:37:73:C6 10.100.0.72 577059 dhcp-snooping 11 FastEthernet1/0/13
00:03:FF:34:77:63 10.100.0.17 584567 dhcp-snooping 11 FastEthernet1/0/37
00:03:FF:35:77:63 10.100.0.104 516547 dhcp-snooping 11 FastEthernet1/0/37
00:03:FF:36:77:63 10.100.0.16 492659 dhcp-snooping 11 FastEthernet1/0/37
TNSWACCS01A1#clear ip dhcp snooping binding 10.100.0.9
Apr 13 14:38:53.123 UTC: DHCP_SNOOPING: delete binding from port FastEthernet1/0/12.
Apr 13 14:38:53.123 UTC: DHCP_SNOOPING: dump binding entry: Mac=00:24:81:54:2A:CA Ip=10.100.0.9 Lease=579148 Type=dhcp-snooping Vlan=11 If=FastEthernet1/0/12
Apr 13 14:38:53.123 UTC: DHCP_SNOOPING_SW no entry found for 0024.8154.2aca 0.0.0.11 FastEthernet1/0/12
Apr 13 14:38:53.123 UTC: DHCP_SNOOPING_SW host tracking not found for update remove dynamic (10.100.0.9, 0.0.0.0, 0024.8154.2aca) vlan 11
Apr 13 14:38:53.123 UTC: Restarting write delay timer.
I got the same behaviour.
Only when I put back the PC on its original port that it received an IP address.
Yes, I do. But there's no port-security violation mentioned by syslog.
Here's the interface configuration:
switchport access vlan 11
switchport mode access
switchport voice vlan 2222
switchport port-security maximum 2
switchport port-security violation restrict
switchport port-security mac-address sticky
switchport port-security mac-address sticky 0024.8154.2aca
switchport port-security mac-address sticky 9caf.caff.5a8c vlan voice
ip access-group ACL_VLAN11 in
mls qos trust cos
spanning-tree bpduguard enable
ip dhcp snooping limit rate 50
SW#sh port-sec int fa1/0/12
Port Security : Enabled
Port Status : Secure-up
Violation Mode : Restrict
Aging Time : 0 mins
Aging Type : Absolute
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 2
Total MAC Addresses : 2
Configured MAC Addresses : 0
Sticky MAC Addresses : 2
Last Source Address:Vlan : 0001.0203.0405:11
Security Violation Count : 0
The security violation would be seen on the port to which you moved the machine. I'd check the port security output there.
Running sticky mac address configs could explain why you are unable to move the machine to another port. The sticky mac address config violates if the secured mac address learned on one secure port is seen on another secured port in the same vlan. Sticky also would not allow the mac address to be learned on the second interface if a violation is encountered. I see that you have "Restrict' your violation mode. When a violation is encountered in this mode, the violation counter increments by 1 and a SNMP trap is sent (not a syslog). For proof of violation, you can change the port security violation mode on both ports from 'restrict' to 'shutdown' (switchport port-security violation shutdown) and attempt to move the machine from fa1/0/12 to that same port you couldn't get to work and you can see the violation in action this time as the seond port should go into errdisable.
As far as I can see, besides the inconvenience of rebooting, DAI and DHCP snooping seem to be doing their job, as well as your port security config.
Message was edited by: antonioknox
I've always used the shutdown violation mode and so I wanted to get a clarification about what you said above.
Specifically, an SNMP trap is sent, a syslog message is
logged, and the violation counter increments
Can you confirm this is not the case and there is an error in the configuration guide, as you stated before:
SNMP trap is sent (not a syslog)
Good catch, cadetalain. I may have gotten my wires crossed with that one. Only protect mode doesn't send a syslog. In fact, it sends nothing at all. Perhaps I should have referenced the docs instead of going from memory.
In any case, wass, traffic will not be forwarded in the case of a violation of sticky since the mac address will not be learned on the second port, and this is probaly why you could not get any action when you moved the machine to a new port.
Message was edited by: Antonio Knox
A little clarification: the fast1/0/12 interface is the original port on which is connected our host. Tomorrow morning I'll check if the new port (fa2/0/27) does not have port-security.