[c-nsp] Under which conditions does port-security consider MAC flap as a security violation?

Martin T m4rtntns at gmail.com
Mon Nov 10 04:17:35 EST 2014


Lukas,

my point was that port-security feature seems to behave differently
with different IOS releases. On some software duplicate MAC address
will be ignored, i.e. MAC address-table entry is not created and
address is not learned by port-security if it was already learned by
port-security on another port. On others, duplicate MAC address will
cause a security violation, port will be "err-disabled" and "Security
Violation Count" counter in "sh port-security interface" output will
increase. For example a "debug port-security" log on
WS-C3750G-24TS(c3750-ipservicesk9-mz.122-55.SE5.bin):

*Mar  1 00:07:43.638: PSECURE: Read:1, Write:2
*Mar  1 00:07:43.638: PSECURE: swidb = GigabitEthernet1/0/1 mac_addr =
0000.0000.0011 vlanid = 881
*Mar  1 00:07:43.638: PSECURE: Adding 0000.0000.0011 as dynamic on
port Gi1/0/1 for vlan 881
*Mar  1 00:07:43.638: PSECURE: Violation/duplicate detected upon
receiving 0000.0000.0011 on vlan 881: port_num_addrs 0 port_max_addrs
100 vlan_addr_
*Mar  1 00:07:43.638: PSECURE: psecure_add_addr_check: Found duplicate
mac-address 0000.0000.0011, It is already secured on Gi1/0/2
*Mar  1 00:07:43.638: PSECURE: psecure_add_addr_check: Security
violation occurred, bring down the interface
*Mar  1 00:07:43.638: %PM-4-ERR_DISABLE: psecure-violation error
detected on Gi1/0/1, putting Gi1/0/1 in err-disable state
*Mar  1 00:07:43.638: PSECURE: psecure_vp_fwdchange invoked
*Mar  1 00:07:43.646: PSECURE: psecure_vp_linkdown port Gi1/0/1, vlan
881, oper mode access, sb mode access
*Mar  1 00:07:43.646: PSECURE: Clearing HA table for 881
*Mar  1 00:07:43.646: PSECURE: psecure_clear_ha_table: called
*Mar  1 00:07:43.646: PSECURE: psecure_linkchange: Gi1/0/1  hwidb=0x48E8410
*Mar  1 00:07:43.646: PSECURE: Link is going down
*Mar  1 00:07:43.646: PSECURE: psecure_linkdown_init: Gi1/0/1 hwidb = 0x48E8410
*Mar  1 00:07:43.646: PSECURE: psecure_deactivate_port_security:
Deactivating port-security feature
*Mar  1 00:07:43.646: PSECURE: port_deactivate: port status is 0
*Mar  1 00:07:43.646: PSECURE: psecure_clear_ha_table: called
*Mar  1 00:07:43.646: %PORT_SECURITY-2-PSECURE_VIOLATION: Security
violation occurred, caused by MAC address 0000.0000.0011 on port
GigabitEthernet1/.
*Mar  1 00:07:43.646: PSECURE: Security violation, TrapCount:1
*Mar  1 00:07:44.644: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet1/0/1, changed state to down
*Mar  1 00:07:45.651: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1,
changed state to down


Under which conditions does port-security consider MAC flap as a
security violation or does it really just depend on IOS release?


thanks,
Martin

On 10/31/14, Lukas Tribus <luky-37 at hotmail.com> wrote:
>> Oct 30 11:33:06.458 UTC: PSECURE: Violation/duplicate detected upon
>> receiving 0000.5e00.0103 on vlan 123: port_num_addrs 0 port_max_addrs
>> 100 vlan_addr_ct 0: vlan_addr_max 100 total_addrs 853: max_total_addrs
>> 3072
>> Oct 30 11:33:06.458 UTC: PSECURE: psecure_add_addr_check: Found
>> duplicate mac-address 0000.5e00.0103, It is already secured on Gi4/7
>> Oct 30 11:33:06.458 UTC: PSECURE: psecure_add_addr_check: Security
>> violation occurred, bring down the interface
>> Oct 30 11:33:06.458 UTC: %PM-4-ERR_DISABLE: psecure-violation error
>> detected on Fa5/2, putting Fa5/2 in err-disable state
>>
>> As I understand this "debug port-security" log, port-security on Gi4/7
>> learned the MAC address 0000.5e00.0103 and then the same MAC address
>> appeared in port Fa5/2 and port-security on Fa5/2 put the port Fa5/2
>> into error-disabled state.
>>
>> Under which conditions does port-security consider MAC flap as a
>> security violation? I wasn't able to replicate this behavior in lab..
>
> Once a mac address is "secured" (within the thresholds of a port with
> port-security enabled), it must not appear on another port-security
> enabled switchport).
>
> It doesn't necessarily have todo with "mac flapping". You should be able
> to trigger this even by moving the mac from on port to another.
>
>
>
> Lukas
>
>


More information about the cisco-nsp mailing list