Dynamic ARP Inspection: no binding on interface

Wassim Aouadi · ‎04-12-2011

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:

WACCS01A1#

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])

TNSWACCS01A1#

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])

TNSWACCS01A1#

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])

TNSWACCS01A1#

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.

Antonio Knox · ‎04-12-2011

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

Wassim Aouadi · ‎04-13-2011

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?

cadet alain · ‎04-13-2011

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.

Regards.

Alain.

Don't forget to rate helpful posts.

Wassim Aouadi · ‎04-13-2011

Alain,

I deactivated/activated the NIC many times with no success. I still have to reboot the machine.

Harrie,

The port is neither VMPS nor dot1x. We set DHCP to assign the same IP to the NIC.

cadet alain · ‎04-13-2011

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.

Regards.

Alain.

Don't forget to rate helpful posts.

Harrie Hendriks · ‎04-13-2011

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.

Greetings.

Antonio Knox · ‎04-13-2011

You have to reboot because:

As stated previously by cadetalain, the 169.x.x.x address is self assigned, so there technically isn't a lease
DHCP gives up after 60 seconds

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.

Wassim Aouadi · ‎04-13-2011

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

TNSWACCS01A1#

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.

TNSWACCS01A1#

I got the same behaviour.

Only when I put back the PC on its original port that it received an IP address.

any idea?

Antonio Knox · ‎04-13-2011

Are you running any type of port security maxumum or sticky config?

Wassim Aouadi · ‎04-14-2011

Yes, I do. But there's no port-security violation mentioned by syslog.

Here's the interface configuration:

interface FastEthernet1/0/12

switchport access vlan 11

switchport mode access

switchport voice vlan 2222

switchport port-security maximum 2

switchport port-security

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

priority-queue out

mls qos trust cos

spanning-tree portfast

spanning-tree bpduguard enable

ip dhcp snooping limit rate 50

end

SW#

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

Antonio Knox · ‎04-14-2011

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

cadet alain · ‎04-14-2011

Hi Antonio,

I've always used the shutdown violation mode and so I wanted to get a clarification about what you said above.

taken from http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_20_ea2/configuration/guide/2950SCG.pdf

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)

Regards.

Alain.

Don't forget to rate helpful posts.

Antonio Knox · ‎04-14-2011

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

Wassim Aouadi · ‎04-14-2011

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.