Hello, we have the following problem, when the IP source Guard and DHCP Snooping enabled, when the host is inactive and the record in the snooping table expires, the host cannot access the network when it is active again, while the record is still working.
Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ----------
* 1 10 WS-C2960C-8TC-L 15.2(7)E5 C2960c405-UNIVERSALK9-M
(config)#int fa0/2
(config-if)#no shut
(config-if)#
009270: Dec 1 09:44:00 BRN: DHCP_SNOOPING: checking expired snoop binding entries^Z
009272: Dec 1 09:44:03 BRN: PSECURE: psecure_linkchange: Fa0/2 hwidb=0x49115A8
009273: Dec 1 09:44:03 BRN: PSECURE: Link is coming up
009274: Dec 1 09:44:03 BRN: PSECURE: psecure_linkup_init: Fa0/2 hwidb = 0x49115A8
009275: Dec 1 09:44:03 BRN: PSECURE: psecure_vp_linkup port Fa0/2, vlan 1, mode access
009276: Dec 1 09:44:03 BRN: PSECURE: psecure_vp_linkup set psec ask handler on interface Fa0/2
009277: Dec 1 09:44:03 BRN: PSECURE: psecure_activate_port_security: Activating port-security feature
009278: Dec 1 09:44:03 BRN: PSECURE: port_activate: status is 1
009279: Dec 1 09:44:03 BRN: PSECURE: psecure_activate_port_security: set psec ask handler on interface Fa0/2
009280: Dec 1 09:44:03 BRN: PSECURE: psecure_clear_ha_table: called
009281: Dec 1 09:44:03 BRN: PSECURE: psecure_activate_port_security: Deleting all dynamic addresses from h/w tables.
009282: Dec 1 09:44:03 BRN: PSECURE: psecure_platform_delete_all_addrs: deleting all addresses on vlan 1
009283: Dec 1 09:44:03 BRN: PSECURE: psecure_vp_list_fwdchange invoked
009285: Dec 1 09:44:03 BRN: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Fa0/2 for pak. Was Vl1
009286: Dec 1 09:44:03 BRN: DHCPSNOOP(hlfm_packet_hat_mat_filtering) port security is enabled on FastEthernet0/2
009287: Dec 1 09:44:03 BRN: PSECURE: psecure_packet_enqueue: psecure receives a packet: addr = 50e5.4942.fe2f, swidb = Fa0/2, vlan = 1, linktype = IP
009288: Dec 1 09:44:03 BRN: PSECURE: mat_cookie=1
009289: Dec 1 09:44:03 BRN: PSECURE: Read:535, Write:536
009290: Dec 1 09:44:03 BRN: PSECURE: swidb = FastEthernet0/2 mac_addr = 50e5.4942.fe2f vlanid = 1
009291: Dec 1 09:44:03 BRN: PSECURE: Packet is handled by some other feature so that address will not be added to port-security sub block
009292: Dec 1 09:44:03 BRN: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/1 for pak. Was Vl1
009293: Dec 1 09:44:03 BRN: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Vl1 for pak. Was Gi0/1
009294: Dec 1 09:44:03 BRN: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/1 for pak. Was Vl1
009295: Dec 1 09:44:03 BRN: PSECURE: psecure_packet_enqueue: psecure receives a packet: addr = 50e5.4942.fe2f, swidb = Fa0/2, vlan = 1, linktype = NullPak
009296: Dec 1 09:44:03 BRN: PSECURE: mat_cookie=1
009297: Dec 1 09:44:03 BRN: PSECURE: Read:536, Write:537
009298: Dec 1 09:44:03 BRN: PSECURE: swidb = FastEthernet0/2 mac_addr = 50e5.4942.fe2f vlanid = 1
009299: Dec 1 09:44:03 BRN: %LINK-3-UPDOWN: Interface FastEthernet0/2, changed state to up
009300: Dec 1 09:44:03 BRN: PSECURE: psecure_packet_enqueue: psecure receives a packet: addr = 50e5.4942.fe2f, swidb = Fa0/2, vlan = 1, linktype = ARP
009301: Dec 1 09:44:03 BRN: PSECURE: mat_cookie=1
009302: Dec 1 09:44:03 BRN: PSECURE: Read:537, Write:538
009303: Dec 1 09:44:03 BRN: PSECURE: swidb = FastEthernet0/2 mac_addr = 50e5.4942.fe2f vlanid = 1
009304: Dec 1 09:44:03 BRN: PSECURE: psecure_packet_enqueue: psecure receives a packet: addr = 50e5.4942.fe2f, swidb = Fa0/2, vlan = 1, linktype = NullPak
009305: Dec 1 09:44:03 BRN: PSECURE: mat_cookie=1
in the debug, you can see that the packet is intercepted by something and most likely this does not work, how to understand what exactly? Or maybe I initially did not set up the mechanisms correctly?
Hi, I found a solution for myself, I did not say that there is a switch from another vendor (Nateks NX-3428) in the topology above, and the problem was that his agent sent all requests on his own behalf when snooping was running, i.e. changed the source address of the sender, so the root switch did not know where to send the response from the DHCP server and dropped them. Thus, without receiving a response from the DHCP server, snooping did not allow access hosts to the network. In total, we can summarize that the matter is not in CISCO.
What arp inspection filters are you applying, also your port sec aging look a bit to aggressive (2 mins)
sh ip arp inspection interfaces sh ip arp inspection vlan 1 sh ip arp inspection statistics sh port-security sh port-security interface x/x sh ip source binding vlan 1 sh ip dhcp snooping binding vlan 1 sh ip dhcp snooping database
Please rate and mark as an accepted solution if you have found any of the information provided useful. This then could assist others on these forums to find a valuable answer and broadens the community’s global network.
sh port-security interface fa0/1
Port Security : Enabled
Port Status : Secure-up
Violation Mode : Restrict
Aging Time : 2 mins
Aging Type : Inactivity
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 2
Total MAC Addresses : 1
Configured MAC Addresses : 0
Sticky MAC Addresses : 0
Last Source Address:Vlan : b827.eb6d.3298:1
Security Violation Count : 0
sh port-security interface fa0/2
Port Security : Enabled
Port Status : Secure-up
Violation Mode : Restrict
Aging Time : 2 mins
Aging Type : Inactivity
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 2
Total MAC Addresses : 1
Configured MAC Addresses : 0
Sticky MAC Addresses : 0
Last Source Address:Vlan : 50e5.4942.fe2f:1
Security Violation Count : 0
sh port-security interface fa0/3
Port Security : Enabled
Port Status : Secure-up
Violation Mode : Restrict
Aging Time : 2 mins
Aging Type : Inactivity
SecureStatic Address Aging : Disabled
Maximum MAC Addresses : 2
Total MAC Addresses : 1
Configured MAC Addresses : 0
Sticky MAC Addresses : 1
Last Source Address:Vlan : 0000.0000.0000:0
Security Violation Count : 0
sh ip dhcp snooping database
Agent URL : scp://SecretLogin:SecretPassword@SecretIP/Secrethostname.snoop
Write delay Timer : 300 seconds
Abort Timer : 300 seconds
Agent Running : No
Delay Timer Expiry : 41 (00:00:41)
Abort Timer Expiry : Not Running
Last Succeded Time : 09:38:40 BRN Mon Dec 6 2021
Last Failed Time : 15:53:51 BRN Thu Dec 2 2021
Last Failed Reason : Error writing to remote database.
Total Attempts : 94 Startup Failures : 0
Successful Transfers : 77 Failed Transfers : 17
Successful Reads : 1 Failed Reads : 0
Successful Writes : 76 Failed Writes : 17
Media Failures : 17
Now IP Source Guard Disabled on interface Fa0/2,
On port Fa0/3 enabled switchport port-security mac-address sticky, and with this configuration, more or less everything works, but we would like to use only dynamics.
The reason why this wasnt working would suggest its due to the static DAI acl applied for the the vlan, this acl would be read before any dhcp snooping D/B
If you remove that dai acl and the port-security sticky then let the hosts otain dhcp again does it work? conf t no ip arp inspection filter SARPInspectFilter vlan 1 no switchport port-security sticky interface x/x
Please rate and mark as an accepted solution if you have found any of the information provided useful. This then could assist others on these forums to find a valuable answer and broadens the community’s global network.
I cannot remove the filter, since in addition to dynamic addresses we have static ones, they also need to be allowed.
Remove the static mac entry and the clear the dhcp snooping table of those entries, then let those hosts obtain dhcp, When they are registered in the snooping table they should be allowed to communicate once more:
Please rate and mark as an accepted solution if you have found any of the information provided useful. This then could assist others on these forums to find a valuable answer and broadens the community’s global network.
Hi, I found a solution for myself, I did not say that there is a switch from another vendor (Nateks NX-3428) in the topology above, and the problem was that his agent sent all requests on his own behalf when snooping was running, i.e. changed the source address of the sender, so the root switch did not know where to send the response from the DHCP server and dropped them. Thus, without receiving a response from the DHCP server, snooping did not allow access hosts to the network. In total, we can summarize that the matter is not in CISCO.
the reason is the IP source guard have two inspection one is the IP only and this can check the DHCP snooping by other is check IP address with MAC address IP from DHCP snooping and MAC from port-security. so in your case the IP to MAC address is not right and hence the packet is drop. solution try use ip verify with dhcp snooping only and see result.
ip verify source [vlan{dhcp-snooping | vlan-list}] [port-security]
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:
