networklop.blogg.se

Mar 20 15:08:47: PSECURE: psecure_get_next_mac_from_hat: returning NULL on Gi2/0/18 Mar 20 15:08:47: PSECURE: psecure_get_next_mac_from_hat: returning NULL on Gi2/0/17 Mar 20 15:08:47: PSECURE: psecure_get_next_mac_from_hat: returning NULL on Gi2/0/16 Mar 20 15:08:47: PSECURE: psecure_get_next_mac_from_hat: returning NULL on Gi2/0/15

In case in stimulates anyone's memory, I have more snippets of logging output from "debug port-security": That looked really promising, but unfortunately, it didn't work for me.

Removing the "switchport port-security" command on the individual interfaces and then re-applying it, solved the problem for me. The only data points I have to add are (a) that it happens only on stack members greater than 1, and (b) that the affected ports are all configured with "spanning-tree portfast", and bpduguard is on, so I don't think BPDUs should be an issue. I haven't been able to find any reference to this debug message anywhere. Po48 is the port-channel uplink, configured as a dot1q trunk, to a distribution switch. Mar 20 10:05:25.830: PSECURE: psecure_delete_address_not_ok: no port security subblock for Po48 Mar 20 10:05:24.824: PSECURE: psecure_delete_address_not_ok: no port security subblock for Po48 Mar 20 10:05:23.817: PSECURE: psecure_delete_address_not_ok: no port security subblock for Po48 Mar 20 10:05:22.794: PSECURE: psecure_delete_address_not_ok: no port security subblock for Po48 Something that may or may not be relevant: With " debug port-security", logging shows many lines like this: There doesn't appear to be anything at all wrong with the computer's network connectivity. These commands were run while the attached computer was happily answering "ping". Switchport port-security violation restrict In all cases the affected ports are "secured" to a single computer, and are configured with "spanning-tree portfast". It appears to affect only ports on stack members 2 or higher we've configured stack member 1 as master in all cases, but I don't know if this is relevant. You may check NIC config, if you are using any sort of redundancy let us know.Įrik, we see exactly the same problem on stacks of 3750X switches running IOS 15.0 (1) SE2 (ipbase image). So, the first question to ask is why the host is not sending any packets through this interface? I´m curious on why it is not receiving any packets, I´ve seen this in a load-balancing configuration on the NICs(on servers for example, one NIC receives packets and the other NIC sends) but since this is a workstation I really doubt this is the cause. A switch will not learn a MAC address if it doesn´t receive any packet from the host. Input queue: 0/75/0/0 (size/max/drops/flushes) Total output drops: 5454502ĥ minute input rate 0 bits/sec, 0 packets/secĥ minute output rate 63000 bits/sec, 51 packets/secĠ input errors, 0 CRC, 0 frame, 0 overrun, 0 ignoredĠ input packets with dribble condition detectedĥ6272056 packets output, 9223565276 bytes, 0 underrunsĠ output errors, 0 collisions, 2 interface resetsĠ lost carrier, 0 no carrier, 0 pause outputĠ output buffer failures, 0 output buffers swapped outįrom that output I can see that there are no packets coming in to the interface, and many packets out of it. Last clearing of "show interface" counters never Last input never, output 00:00:00, output hang never Input flow-control is off, output flow-control is unsupported

Hardware is Gigabit Ethernet, address is 70ca.9bca.760b (bia 70ca.9bca.760b) GigabitEthernet2/0/11 is up, line protocol is up (connected) SWIITCH(config)#do show mac address-t int g2/0/11

Switchport port-security mac-address sticky I noticed that we have several interfaces (on different switches) that are up but have not captured the MAC address from the workstation. We have port security mac address sticky configured on all our switch ports. In my environment we have 3750x switches running ios 15.0 (1) SE2.